Document hardware-module encoding #12
Conversation
cpu
left a comment
cpu
left a comment
There was a problem hiding this comment.
Thanks! I think this is a change in the right direction.
Did you want to look at the question of how servers should be matching CSR subjectAltName extensionRequest attributes with ACME order identifiers separately or was that part of my issue not well articulated? I think there's still room to make that aspect of the draft a bit tighter even after this update.
| The hardware module identity can be included in the Subject Alternate Name Extension using the HardwareModuleName form described in [RFC4108]. The HardwareModuleName is encoded as an otherName with the OID id-on-hardwareModuleName (1.3.6.1.5.5.7.8.4) and consists of: | ||
|
|
||
| - hwType: An OBJECT IDENTIFIER that identifies the type of hardware module | ||
| - hwSerialNum: An OCTET STRING containing the hardware module serial number | ||
|
|
||
| Clients MAY include this identifier in the certificate signing request (CSR). When included in a CSR, it MUST appear in an extensionRequest attribute [RFC2985] requesting a subjectAltName extension. |
There was a problem hiding this comment.
This new text looks good, but I think its a little more detailed than the equivalent Permanent Identifier text and it might be nice to aim for more symmetry between them. The things that stick out to me in this one vs the other are the mention of the otherName OID, and the extra clarity on the expected RFC 2985 CSR attribute.
I think the extra detail here is good, so probably backporting some of it to the preceding section might be the best way to go. WDYT?
Fixes #9