[lamps] Re: Binding certificates to protocols/applications

[刘鹏辉 <[e-mail]>]

I think it's better to identify certificatate for different protocols with OID, just like DV, EV, OV certificates in WEB PKI.


Penghui liu







At 2026-06-11 14:02:26, "Brockhaus, Hendrik" <hendrik.brockhaus=[e-mail]> wrote:

In an OT environment, the entity that holds keys and certificates is often a device, even if the device holds multiple certificates to be used with different protocols. As Steffen wrote, the point is that the SW on a device must be able to reliably identify the certificate that is to be used for authentication in a certain protocol.

According to RFC 5280, the subject name is the combination of subjectDN and SAN.

I am unsure how the binding of a certificate to a protocol can best be realized. Is it rather that the subject name should denote the protocol on a device, or that the subject name should only denote the device and a purpose OID should denote the protocol.

If I compare the proof-of-identity of the requester of a certificate with the subject name in the CSR during certificate management, e.g. using EST, it is helpful if both certificates contain the same subject name. Here it would be helpful if the protocol is not encoded in the SAN.

 

Hendrik

 

Von: Tomas Gustavsson <Tomas.Gustavsson=[e-mail]>
Gesendet: Mittwoch, 10. Juni 2026 22:00
An: Eliot Lear <[e-mail]>; Michael StJohns <[e-mail]>; [e-mail]
Betreff: [lamps] Re: Binding certificates to protocols/applications

 

| |

Sie erhalten nicht häufig E-Mails von tomas.gustavsson=[e-mail]. Erfahren Sie, warum dies wichtig ist

| |

I recommend against creating a custom SubjectAltName.OtherName. It requires creating a proper ASN.1 definitions and will be hard for most people both to issue and parse so make use of such certificates. If you don't think a standard altName works, there are plenty of OtherNames defined already that might be useful, some examples being Service Name, Hardware Module Name (already mentioned), Permanent Identifier, Registered Identifier, Subject Identifiiation Method, etc etc. OtherName is one of these slush buckets where people creates new names for the same concepts that have already been defined multiple times.

 

Tomas

 

From: Eliot Lear <[e-mail]>
Sent: Wednesday, June 10, 2026 9:50 PM
To: Michael StJohns <[e-mail]>; [e-mail] <[e-mail]>
Subject: [lamps] Re: Binding certificates to protocols/applications

 

I agree with Mike on these points.  You also lose some mnemonic translation in some of the standard tool sets when you run with new EKUs.  Heck, I couldn't get the Golang to check in a new EKU table entry, and it was only a table entry.

Eliot

On 10.06.2026 19:51, Michael StJohns wrote:

Hi Steffen - 

 

Are you looking at this for the client certificates, for the server certificates or both?  E.g. do you expect both ends to check and enforce legitimate purposes?

 

What is your certificate issuing environment?  Something like the classical public CA model - or something with dedicated private CAs and a constrained/limited issuing regime? Something else?

 

What are the policy models for the issuing CAs for both the client and server?  E.g. How deep is the chain?  Are there individual CAs for each protocol or does a single CA issue for all protocols?  If multiple CAs, do you expect to be able to technically (vs policy) enforce the restriction of a CA to [a] specific protocol[s]?

 

Name based enforcement (as suggested elsewhere) is generally going to fail somewhere along the way -(cf PEM and name subordination).  Names mainly provide a handy place to stuff an easily referenced handle for the certificate (e.g. see HardwareName as an OtherName).  KeyUsage, EKUs and CertificatePolicy (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4) extensions tend to be the appropriate approaches for certificate and key usage enforcement.

 

Mike

 

On 6/10/2026 12:50, Fries, Steffen wrote:

Dear all,

 

I have a question stemming from IEC standardization for the power system industry. But I think the question may be generally applicable.

 

The intention is to utilize dedicated certificates in the context of selected protocols.  With that an end device, e.g., a protection device, may use dedicated certificates to secure IEC 61850 by TLS, or RADIUS protected with TLS, or syslog when used over TLS. The device would have to manage these certificates and the question is if and how ideally the certificate indicates it may only be used in a dedicated setup.

 

There are different approaches possible for that certificate – protocol/application binding

ensure engineering realizes the correct association of protocol and certificate, but this would not allow the relying party to verify the certificate was used for the right purpose.
encode the purpose (target protocol to be protected) in the CN or the SAN, but this may lead to errors, if different vendors use different naming.
restrict the usage of the certificate via EKU to a specific protocol in a similar fashion as RFC 9809. This would require that protocols can be identified by an OID. While this approach seems favorable to me, I’m not aware of a protocol registry, which provides OID for protocols or applications. This may be done via private OIDs, but then, there is the danger that for certain protocols private OIDs are defined multiple times, which may lead to problems as the device may operate in different environments and would need to know the possible variations of the OID pointing to the same protocol.

 

Hence the question if there is some best practice regarding the use of dedicated certificates on the same device with different protocols/applications?

 

Best regards

Steffen

 

--
Steffen Fries
Siemens AG

 





_______________________________________________
Spasm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

 





_______________________________________________
Spasm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]