Add TF-2C for Security Management Appendix

[ToddCooper]

Section Number

TF-2C (new appendix)

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate. for Milestone 1.3

Issue

For SDPi, security operationalization and related specifications has become an increasingly important topic, warranting a new appendix in TF-2 to contain the related specifications

Proposed Change

Add appendix C to the current SDPi build and include a general note about the content that will be added to the section.

[PeterKranich]

I agree this is an important topic. Most of the vendors are unhappy with the security certificate requirements in the Base-PKP. Recently, a new OR.NET working group has been kicked-off regarding the security certificate handling. It will probably still take some time, but we can start in SDPi.

Does this issue relate to #52 ?

[PaulMartinsen]

Edits to expand some points and incorporate ideas from @neuschwander-lmi :

• clarify on-boarding certificate
• example key usage and subject alt-names.
• clarified "manufacturing" should include new devices and software updates to add SDC support products that are already in use.
• added thoughts on granularity.
• added summary of resources & certificates

The diagram below offers very rough outline, and straw man, for a possible approach to operationalize SDC security through the following journey:

1. A new SDC provider is implemented that aspires to join the SDPi community. It is submitted to some compliance agency for testing, or an automated tool tests its compliance to SDPi.
2. Products that comply are issued a "SDPi conformity digital certificate", signed by the compliance agency, verifying claimed support.
   • Extended key usage indicates complying key purposes and device specializations (e.g., 1.2.840.10004.20701.1.1 => SDC provider)
   • Subject alt name identifies the manufacturer, product and version; also a reference to the test authorities certification result could be included e.g.,
     • URL=urn:dev:ops:32473-ProductA-1.2.3.456 => dev urn defining organization product and serial number for the specific SDC stack version
     • URL=https://cert.sdc.org/{86530F00-4246-4010-A9DC-10D32E6328A0} (if present) provides human and machine readable information about conformity (e.g., unknown, register, conforms to all/parts of SDPi).
     • SDPi information isn't mandatory, but might be the preferred method for easy integration.
       • Generation may be trivial (e.g., simply by registering a new SDC implementation) with the url providing up-to-date information as the new product moves through registration and compliance process.
       • Information at the conformity url may be human and machine readable to facilitate responsible organizations selecting the level of compliance required by devices in their system.
       • Level of granularity can adapt over time based on experience. For example, a manufacturer could self-assess and self-declare conformity for minor updates, security fixes etc to ensure reliance on the third-party conformity resource minimizes risk.
   • digital certificate has a maximum chain length of 2 or 3, so manufacturers can issue device specific "SDPi conformity on-boarding" certificates
   • manufacturer holds private key and, receives a signed certificate from the test authority as part of registering a new SDC implementation
     • the signed certificate doesn't indicate compliance with, e.g., SDPi. It indicates the stack is registered and provides a publicly accessible resource (via a URL) from which a responsible organization can retrieve up-to-date conformity information as it becomes available (e.g., the stack passes verification testing).
     • as part of requesting compliance, supplies a certificate signing request to the test authority which includes all the information in the certificate except the conformity link. The conformity link is added to the certificate by the test authority when testing is completed and the certificate issued. Indicating conformity in the certificate could be a problem for devices that are in use; using an external resource makes this easier and could support versioning and a multi-stage conformity process. Downsides: (1) makes it (a little) harder for a responsible organization to validate conformity (2) someone, perhaps an independent consortium of manufacturers or test organizations, needs to maintain this resource.
     • a trivial registration process may encourage providers to register creating a resource that responsible organizations can use during purchasing supporting adoption of SDC.
   • manufacturer's could sign their own certificates, making conformity claims, for a variety of reasons (e.g., development, test deployments). Compliance and operation are separated so the responsible organization can decide which devices are permitted in their environment.
   • adsf
3. During manufacturing, each device generates a private key and sends a certificate signing request to the manufacturer which issues an on-boarding certificate to the device.
   • Onboarding certificate includes:
     • all the information from the compliance certificate
     • device serial product name and serial number urn
     • sdc device on-boarding key usage oid.
     • on-boarding credentials have a certificate that doesn't expire until the product has reached end-of life.
   • Manufacturing includes:
     • assembly of new devices for delivery to customers
     • in-service software updates to add SDC capabilities (e.g., new software creates a private key and certificate signing request; sends (e.g., through a secure channel) signing request to manufacturer who verifies device identity (e.g., by serial number) creates and returns the SDC on-boarding certificate to the device) .
4. In operation, devices use their "SDC on-boarding certificate" as client credentials to request a transport layer security certificate for SDC communications (the on-boarding credentials are not used for normal SDC communications)
   • the on-boarding device generates a private key to secure SDC communications and connects to a TLS certificate authority offering its on-boarding certificate as client credentials.
   • the on-boarding device might discover the TLS authority using a multicast WS-Discovery probe. It might be redirected to a managed discovery proxy using dynamic mode switching from ws-discovery. It might discovery the TLS authority using a Well Known SDPi type.
   • the TLS authority may have a white/black list of devices/products that are permitted; it may have access to a CRL published by the test authority and/or manufacturer. It might choose to trust SDC providers that do not have an on-boarding certificate from a trusted test-authority (after considering their own risk profile). This could also be a path for testing and development until trusted test-authorities exist.
   • vendors may provide proprietary TLS certificate authorities to control certificate distribution/ licensing.
   • the TLS authority may have a chain-of-trust back to a Well Known (generally or to the SDPi world) certificate authority so that SDC devices can trust the communication certificates issued, or the responsible organization may load additional certificate authorities onto SDC devices as part of some initial setup process (if individual SDC device providers choose to allow this).
   • the TLS authority might include organization specific authorizations in the TLS certificate issued.
   • the TLS authority might require the responsible organization to approve issuing individual certificates or take a rules based approach.

Some additional considerations/features:

• The SDC on-boarding certificate may have a long train of trust, without impacting regular SDC communication handshakes. For example, it might be sensible to have additional organization level intermediate certificates to simplify protection and use of critical private keys.
• The TLS certificate, used for regular SDC communications, may have a short trust chain to improve performance on low-resource devices (where the TLS handshake may be the largest performance bottleneck).
• Relative distinguished names appear to be going out of fashion in digital certificates, perhaps due to inconsistent application. Using urns in the subject alternate name, based on established standards may provide a more consistent approach without defining a new standard. Although both approaches could co-exist happily.
• On-boarding and operational certificates provide a separation of secure communications and conformity to SDPi profile, mediated by the TLS certificate authority.
• Renewing communication certificates might be bootstrapped with the previously issued certificate and automatic; (e.g., renew every 30 days; during operational down times). Frequent renewals might be considered:
  • a substitute for managing white lists/CRLs on SDC providers.
  • a mechanism to remove devices from service where a new (e.g. security) risk is identified but unresolved.
  • a (weak) proxy for certificate revocation lists because typically an SDC network would not have access (or perhaps resources) to access public revocation lists.
  • certificate generation could be integrated into ws-discovery hello (e.g., through a discovery proxy) with certificates issued and revoked as devices join and leave the network.

Some questions:

• Can operational on-boarding be handled by existing tools, or is a fully (or partly) customized solution required? On-boarding device certificates are used in Microsoft's IoT platform, for example.

Summary

Actors

• Test authority: responsible for validating SDC stacks and reporting conformity to standards/profiles to the Conformity consortium.
• Conformity consortium: responsible for collecting, maintaining and publishing conformity information.
• TLS certificate authority: responsible organization's server responsible for reviewing evidence (e.g., SDC on-boarding certificate and associated resources) and granting access (by providing a suitable TLS certificate) to the responsible organizations's SDC network(s). A typical implementation may consult an SDC on-boarding certificate and resources published by the Conformity consortium when deciding whether or not to issue a certificate.

Certificates

• SDC on-boarding certificate: evidence a SDC provider/consumer can offer the responsible organization's "TLS certificate authority" to gain access to the responsible organizations's SDC network(s). Signed by manufacturer's SDC manufacturing certificate
• SDC manufacturing certificate: evidence to manufacturer's conformity statement for an SDC stack (through an external link embedded into the certificate). Used by the manufacturer, to sign SDC on-boarding certificates. Signed by Conformity consortium (or by an SDC stack vendor by a certificate signed by Conformity consortium).
• SDC communication certificate: evidence used by SDC providers and consumers to securely communicate with transport-level-security. Issued by the responsible organization's "TLS certificate authority" to individual SDC devices. Typically based on evidence provided by an SDC on-boarding certificate, though responsible organizations may chose their own policies for issuing certificates (e.g., they may only allow specific manufacturers, devices or SDC stacks conforming to SDPi).

[neuschwander-lmi]

In response to @PaulMartinsen :

digital certificate has a maximum chain length of 2 or 3, so manufacturers can issue device specific on-boarding certificates.

I don't understand what kind of on-boarding certificate you refer to in this context. From the rest of the text, I assume you mean something with SDC-specific information?

Onboarding certificate includes: [..] all the information from the compliance certificate

This is not possible if manufacturing occurs before the compliance process is finished. This is the normal case if compliance to a new standard emerges from a software feature update and the product is already in use before compliance testing begins.

We should remove everything specific to SDC-compliance from the "onboarding" certificate.

General remarks:

• We need to identify how granular the compliance statement will be in regards to the software version, especially regarding time-critical security fixes, where reliance on a third-party actor adds risks.
• In a first iteration, manufacturers could state the compliance, until a compliance agency is established. This would create a smooth upgrade path, where we only need to exchange the root of trust.

[PaulMartinsen]

Thanks for your comments @neuschwander-lmi. Sorry, for the tardy reply; a busy couple of weeks with plug-a-thon and SDPi workshops back-to-back.

I don't understand what kind of on-boarding certificate you refer to in this context. From the rest of the text, I assume you mean something with SDC-specific information?

Yes, I'm specifically thinking of an SDC on-boarding certificate, being one mechanism to join an SDC network which also separates verifying/ asserting conformity from communications. I edited my original comment to make this a little clearer and will try to call them SDC on-boarding certificates. A vendor might have other certificates (or certificate features) for other on-boarding tasks, however I was thinking only of SDC on-boarding here.

Onboarding certificate includes: [..] all the information from the compliance certificate

This is not possible if manufacturing occurs before the compliance process is finished. This is the normal case if compliance to a new standard emerges from a software feature update and the product is already in use before compliance testing begins.

Great point. I changed the description (not reflected in diagram yet) to make it trivial to get a conformity URL that can be placed in a certificate. Now I'm imagining they are provided to any who would like one. The certificate then provides a URL to human/machine readable conformity status (with suitable granularity) that could range from "issued" to "passes all tests". Responsible organizations running SDC networks would typically look to the conformity resource when issuing communication certificates but could also work with vendors through the transient period to issue SDC communication certificates using other mechanisms (e.g., white/black lists).

We should remove everything specific to SDC-compliance from the "onboarding" certificate.

I think I've done this now by moving the conformity status into a publicly accessible resource, referenced from the "SDC onboarding certificate". The onboarding and device certificates could still declare their SDC capabilities in the certificates (to facilitate interoperability), but trust of claims would be verified (by the responsible organization's TLS certificate authority) through an external, updatable, conformity resource and/or relationships between responsible organizations and vendors.

General remarks:

• We need to identify how granular the compliance statement will be in regards to the software version, especially regarding time-critical security fixes, where reliance on a third-party actor adds risks.

My idea to resolve this (added to original comment) was to let manufacturer's self-declare parts of conformity in the public conformity resource referenced in the SDC on-boarding certificate (e.g., this new version number still confirms but has some security fixes). Typically responsible organization's TLS certificate authority could/would be configured to accept fixes/new versions.

• In a first iteration, manufacturers could state the compliance, until a compliance agency is established. This would create a smooth upgrade path, where we only need to exchange the root of trust.

Agreed. This is what I was thinking about for the "independent manufacturer" and a benefit that occurred to me if we separate conformity and communications when operationalizing security was discussed in the SDPi workshop. A responsible organization's TLS certificate authority is able to issue communication certificates using any rule it likes, which could be informed by vendor relationships and information from a conformity consortium linked in the SDC on-boarding certificate.

[neuschwander-lmi]

Hi @PaulMartinsen .
In your text, you now have a lot of different names for the certificates, e.g.

• "SDPi conformity digital certificate"
• "a signed certificate"
• "compliance certificate"
• "SDC on-boarding certificate"

Especially cases like the second make it hard to pinpoint which certificate exactly is meant. Could you please add a list of all certificate names at the top and apply consistent naming?

[PaulMartinsen]

Version 0.2, reworked for clarity.

Use cases

Use cases considered by the scheme described here include:

• Separate conformity & communications credentials
• Manufacturers may source SDC stacks from independent software vendors
• Support for SDC may be added to devices already in-service (e.g., software update)
• Manufacturers and responsible organizations may wish to use SDC outside the SDPi conformity framework (e.g., development and trial systems)
• Some responsible organizations are mobile (e.g., ambulance)
• Manufacturers may have custom extended key-usage
• Responsible organizations may wish to use their own chain of trust for communications certificates.

Actors

Actors involved in operationalization of security for SDC described here are:

• Manufacturer: designs, manufactures and provides products for SDC networks using own or 3rd party SDC stack

• Stack vendor: independent software vendor; supplies conforming SDC stacks to manufacturers

• Conformity consortium: maintains conformity records, assigns conformity ids, signs SDC manufacturer certificate

• Auditor: responsible for independent testing & validation of products for conformity to SDPi

• SDC participant: an instance of an SDC device that will participate in an SDC network

• Mediator: a server that issues TLS certificates enabling communication on an SDC network. The mediator bridges conformity and operational communications.

Additional actors are described in SDC standards and profiles.

Certificates

Certificates involved in operationalization of security for SDC described here include:

• cert.sdc.org: root certificate for SDPi conformity trust-chain.
• tls.sdc.org: root certificate for SDC communications trust chain.
• responsible organization authority: trust root for communications on a responsible organization's SDC network(s).
• stack-vendor: a pre-validation certificate signed to provide conformant SDC stack-providers with a mechanism to convey conformity to their end users, which their end-users could employ to verify/ support/ accelerate conformity.
• manufacturing certificate: used by a manufacturer of SDC solutions to sign on-boarding certificates which will assert conformity to SDC profiles/ standards. Signed by a stack-vendor or cert.sdc.org root.
• on-boarding certificate: stored on an SDC participant, which uses it to provide evidence to a mediator when joining an SDC network. Signed by a manufacturing certificate.
• communications certificate: issued to an SDC participant (by a mediator) to enable the participant to communicate, using transport layer security, on an SDC network. The communication certificate's chain of trust may rely on a root authority created by the responsible organization, or a public, trusted root-authority identified in the SDC profile.

It is common for chains of trust to have various intermediate certificates, not shown here, to facilitate protection of private keys and updating of certificates. The chain of trust for conformity and communications certificates is shown below.

Other terms

• Conformity record: a publicly accessible, human and machine readable document, that certifies (at an appropriate level of granularity) conformity to one or more SDC related requirements, standards and/ or profiles of an SDC solution. The conformity record is updatable by various actors through the development and lifetime of the SDC solution.
• Conformity id: a, globally unique, identifier of a conformity record.

Relationships

Operation

Responsible organization

Typically, in the responsible organization (e.g., hospital, ward, ambulance) an SDC participant joins an SDC network by:

1. generating a private key for communications on the SDC network,
2. providing to the mediator its:
   1. on-boarding certificate (typically) as evidence of permission to join the network
   2. a certificate signing-request, complete with the extended key-usage, subject and subject alternate name for the communications certificate that the participant will use on the SDC network.

The mediator examines the evidence offered by the SDC participant (typically an on-boarding certificate) and, if the participant meets the responsible organizations policies, signs the certificate signing request and returns the certificate to the participant. The participant uses the communications certificate to participate in the SDC network.

Note

Using a mediator separates conformity from communications placing the decision on which SDC devices may participate in a particular network in the hands of the responsible organization (typically) informed by a conformity record supplied by the conformity consortium.

The lifetime of the communications credentials may depend on the operating environment of the responsible organization. For example:

• credentials for an SDC network in an ambulance may be issued for a single shift to guard against theft (or for six months to ensure there are not communication issues when equipment is in-use)
• communication certificates may have a short life-time (e.g., days) requiring devices to periodically "re-authenticate" as access policies change.

Conformity record

Typically, an SDC participant would provide an on-boarding certificate with a URN to the product's conformity record to join the responsible organizations SDC network. The mediator examines the conformity record (possibly along with other information in the certificate) to decide if the SDC participant should be allowed onto the network. The conformity record could be obtained, through the Internet, from the conformity consortium directly or the mediator could maintain a regularly updated, local cache, to facilitate isolation from public networks.

Note

Because the conformity information is held at the conformity consortium it can be updated through the products life-cycle.

The conformity record could contain information such as:

• status of the SDC participant's conformity to relevant standards; the status could be a narrow set of options that might include "issued", "self-assessed", "fully conformity"
• granular information (e.g., versions supported, features supported) on the SDC participant's conformity to particular aspects of relevant standards
• SDC participant white/ black lists (e.g., to support product recall, minimum version)

A mediator implementation may accept other evidence (e.g., endpoint-reference, subject relative distinguished names) as permission to join the responsible organizations network (e.g., through relationships between individual vendors and the responsible organization). These mechanisms may be out of scope of the standard/ profile.

Conformity

Conformity to one or more SDC standards/ profiles is recorded in the conformity record, maintained by the conformity consortium and communicated by a SDC participant using a conformity reference in the participant's on-boarding certificate.

Getting started

A manufacturer obtains a conformity reference by submitting a certificate signing request to the conformity consortium. The certificate signing request would contain:

• subject: a distinguished name identifying the manufacturer,
• subject alternate name: an organization serial number identifying the SDC stack (e.g., url=urn.dev.os:32473-SDC-001);.
• extended key-usage: client authentication, SDC provider, SDC consumer, participant key purposes, device specializations, manufacturer uses,
• basic constraints: certificate authority.

The conformity consortium would verify the manufacturer's identity (subject), generates a conformity id (e.g. 487B0E31-0150-4AAA-8B96-FC26798AA712), publishes a conformity report and signs the manufacturer's certificate signing request adding the conformity reference to the subject alternate name (e.g., https://cert.sdc.org/487B0E31-0150-4AAA-8B96-FC26798AA712). The signed request is returned to the manufacture as a manufacturing certificate. The conformity consortium is a record keeper, so processes certificate signing requests without prejudice.

Manufacturers typically obtain the manufacturing certificate before an SDC participant is available so the conformity report would have a status of "issued", signalling the participant's conformity is unknown. A manufacturer may be building a participant using an SDC-stack provided by an independent software vendor, so manufacturing certificate could be issued in partnership with the stack-vendor with a reference, to the stack-vendor's conformity (e.g., the manufacturer might apply for the conformity id through the stack-vendor and be issued a manufacturing certificate signed by the stack-vendors manufacturing certificate).

Becoming conformant

An "issued" conformity status offers little information to responsible organisations to assess interoperability. So, at some stage the manufacture could:

1. self-declare conformity, updating the conformity record held by the conformity consortium to reflect this,
2. work with an auditor to obtain independent testing of the SDC participant; the auditor updates the conformity record.

Neither the manufacturing certificate, nor any issued on-boarding certificates require modification when conformity changes because both certificates include a reference to the conformity record and do not contain this information directly.

Conformity records may be linked to a major SDC participant version (that is, major changes to the SDC participant require a new manufacturing certificate and auditing). Minor, incremental, hot-fixes and security updates may not change conformity status, or provide additional information for mediators to consider. This information is typically updated by the manufacturer (e.g., to avoid additional risk where security updates are required).

Conformity records may provide revocation information to mediators. For example, where a manufacturer recalls specific versions from service (e.g., private key breach, fault or security issue identified by unresolve in particular released versions, manufacturing issues discovered in specific batches). This mechanism could replace certificate revocation list URLs and black/white listing at the product, version or batch level for SDC networks (which typically do not have network access to retrieve the certificate revocation list).

Note

Nothing is intended to prevent a responsible organization from allowing SDC participants with "issued" conformity status from joining their SDC network (e.g., for testing, through relationships with vendors, etc). Similarly for "self-assessed" conformity.

SDC participant credentials

An individual SDC participant gets an on-boarding certificate during manufacturing. Typically the new device will generate its private key (which normally doesn't leave the device), and create a certificate signing request, which is signed by the manufacturing certificate, to create the participant's on-boarding certificate, which is stored on the device. The on-boarding certificate would contain:

• the participant's end-point reference in the subject alternate name as a URL. The end-point reference may be a guid URN or an organization product and serial number and must match the end-point reference advertised by the participant (e.g., during ws-discovery),
• the participant's key purposes, device specializations, custom extended key-usages etc, which must be a subset of those permitted by the manufacturing certificate,
• SDC participant and/or SDC consumer extended key-usages,
• client authentication extended key-usage so the certificate may be offered to a mediator when the participant wishes to join an SDC network.

As conformity records may include revocation information, the valid period for the on-boarding certificate may be the product lifetime. Manufacturers may provide mechanisms to update the on-boarding certificate over the product lifetime (out of scope of this description).

Note

"Manufacturing" here includes updating deployed devices to add support for SDC. As part of the update, the deployed device could generate a private key, generate a certificate signing request which is sent to the device's manufacturer for signing with the manufacturing certificate. The device manufacturer should verify the identity of the device through some independent method before generating and returning the on-boarding certificate.

Other details

Custom extended key usage

Manufacturers might wish to include their own extend key usage object ids in on-boarding certificates. This is supported through the certificate signing request supplied to the conformity consortium. Custom extended key-usages could be critical or non-critical. None critical extensions are ignored by SDC participants that don't understand them. Credentials containing critical extensions are generally not accepted by anything that doesn't understand them. This presents a problem for the mediator. The mediator should pass-through critical extensions to the communication certificate.

Discovery

An SDC participant new to a responsible organization needs to find the mediator. This could be accomplished in several ways including:

• manual configuration: connection details are installed using a mechanism prescribed by the manufacturer,
• ws-discovery: the mediator is found using using a probe request that includes suitable filters to find the mediator using a well-known interface type.
• discovery-proxy: the mediator is found in the same way as the discovery proxy.

Some things to figure out

• Are there use cases to contemplate in the profile that don’t use on-boarding certificates as evidence to the mediator?
• Does the participant key-purpose, device specialization information belong in the manufacturing certificate, or should it be only in the conformity record? 10700, R0028 requires it in the certificate
• How are conformity records versioned for major, minor, hot and security fixes?
• How is revocation represented in the conformity record?
• Are there use cases for the on-boarding certificate to be used for server authentication, or should this not be allowed?
• How to create and maintain the conformity consortium infrastructure?
• How to distribute local trust roots to SDC participants?
• What is the mediator interface? web server, soap?

[neuschwander-lmi]

I think I have a very important question which needs addressing before we can continue to talk about technical implementations:

Does the conformity assessment only apply to the SDC interface provided by the SDC participant, or does it apply to the whole device? Example: Does conformity assessment check whether the alarm presented on the UI interface corresponds to the alert information conveyed via SDC?

If conformity only assesses the interface, the task is "easy". However, I think this assessment would be kind of worthless.

If not, we run into a problem especially for aggregators where the aggregated MDS can change after the onboarding process. Conformity will then depend on the devices connected and can therefore not be evaluated at onboarding time.

[PaulMartinsen]

I have assumed conformity assessment here is referring to the implementation conformance statements (ICSs) at the end of each standard (e.g., section 11 in 11073-10207). Or at least an analogue of these, perhaps adapted by SDPi. The tables there identify various mandatory, optional, prohibited etc requirements. Then

• regulatory agencies would assess the standard/ profile and decide that participants meeting these requirements are okay,
• an independent body would assess manufacturers implementations to see the implementations meet the requirements,
• manufacturers would present the conformity statements to the regulator agencies to support approval of their devices.

This is just a (somewhat) educated guess though. It might be at the "worthless" end of your scale, if I understood correctly, but I believe I've seen requirements that the SDC implementation shouldn't deviate from the participants purpose. i"m not sure how that turns into an ICS that an could be tested for SDC conformity as it sounds quite device specific.

Considered alone, evaluation of implementations may not need conformity information in the certificates. However,

• there are requirements in, for example, P11073-10700 for certificates to contain various SDC related claims,
• somehow transport level security certificates need to be issued and, in the absence of DNS, an on-boarding certificate with SDC level conformity information may provide an appropriate level of trust to do that.

[neuschwander-lmi]

I'm not sure if it was clear what I meant. An example:
There are two kinds of Mds available, X and Y. Both can be connected to an aggregator A. Both are on the market with software versions X1, X2, Y1, Y2. A is the SDC participant and is able to represent both X and Y on the network. Will the conformity statement for A now

1. not make any assumptions about X or Y at all
2. only apply to a specific version of X and Y, e.g. only X1 and Y2
3. only apply to a specific aggregated device, e.g. only X (requires at least 2 conformity statements for A)
4. only apply to a specific device with a specific software version, e.g. X1 (requires at least 2 conformity statements for A)
5. apply to all supported combinations (as defined and enforced by the manufacturer)

option 1

If we choose 1, that means that conformity evaluation cannot test anything except the device. It would be possible to get a positive statement e.g. for a ventilator which generates alarms but does not forward them to the network. Then the utility of the conformity statement is limited to interoperability alone, and does not add any value from a safety perspective.
It's still some value, but it will be impossible to meaningfully cover the ICS tables that way.

options 2, 3, 4

If we choose 2, 3 or 4, whether A may use a specific EKU depends on which devices will be aggregated. At the time of onboarding, a decision must be made which Mds are allowed to be aggregated by A. This also means that

1. the allowed devices to be aggregated must be configured on A before onboarding
2. the configured allowed devices must be communicated from A to the mediator
3. A must block all devices which are not allowed
4. A must ensure the certificates are invalidated and onboarding is repeated under various circumstances (e.g. update of X1->X2, reconfiguration of the "allowed devices" list of A, ...)

option 5

This would be the easiest to handle (both testing and onboarding). It will create instances of A which state conformity to a set which may never be used by this specific instance, e.g. if the hospital only has devices of type X, not Y.

However, options 2-4 can also create this scenario if devices are configured as allowed even though they are not planned to be used. This might be the case e.g. if two separate aggregators are used for devices X and Y, but the hospital might want the option to switch the placement of X and Y while the aggregators they are connected to remain at the same location (without repeating onboarding).

[neuschwander-lmi]

A completely different approach: We could place a conformity certificate into a custom field of the communication certificate. Then each participant can get access to a verifiable conformance statement of all peers.

Advantages:

• no separate communication channel necessary
• seamless upgrade path for multiple trust anchors
• test for OID can be replaced 1:1 with a test of the certificate
• no additional processes to be defined
  • manufacturers could roll out default communication certificates
  • a local CA could just make a verbatim copy of the conformity certs from the TLS CSR it gets from the participant - no SDC specific logic needed at the local CA
• each manufacturer can decide if they want to hardcode trust anchors or want to make them configurable based on their risk analysis

Disadvantages:

• library support needs to be evaluated
• creates bigger certificates

[ToddCooper]

SDPi Friday 2024.07.26 Discussion -

Attached is a presentation given today by Oracle | Java Card team exploring the relevance to Gemini SDC/SDPi+FHIR cybersecurity. Enjoy ...
Project Gemini - Java Card Intro - Oracle - 2024.07.26A.pdf

[ToddCooper]

SDPi Workshop #4 -

Push to 2.1; content will include results of OR.NET Security WG discussions.