Re: [Ace] draft-moskowitz-ecdsa-pki-10
Michael Richardson wrote: >> * The subjectAltName extension MAY be present in both DevID >> certificates and DevID intermediate certificates. If a DevID >> certificate includes a subjectAltName, that field should include a >> HardwareModuleName. When a TPM is used to provide DevID module >> functionality the IDevID certificate contains a subjectAltName that >> uses a HardwareModuleName to identify the TPM, the hwType identifying >> the TPM Version and the hwSerialNum containing the TPM Serial Number. > This turns out to be a complete distraction. > We had text about this in early BRSKI drafts, but the thing is that this is > about identifying the TPM device itself, which is really not the IDevID. > I'd have to look back in five year old emails to explain what it really was > about, but the short of it is that you should just pretend you never read > this part, as it really does help you. It really does *NOT* help anyone. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-moskowitz-ecdsa-pki-10
Hannes Tschofenig wrote: > Here is what I understand for use of certificates from 802.1AR (with my > wording because RFC 2119 language is often missing in the 1AR spec): I found 1AR very difficult/obtuse. I had some communications with authors at one point that provided some history as to why. It would be nice to revise it within the IETF. > * The DevID certificate subject field is always present, but can be > empty. An IDevID certificate subject field MUST be non-null and SHOULD > include a unique device serial number encoded as the serialNumber > attribute. The subject field can contain information identifying the > supplier or manufacturer of the device. Yes. To clarify for archives, we are talking about the X520SerialNumber attribute. Section 2.3.1 of RFC8995 tried to be definitive hear. > * IDevIDs SHOULD use the GeneralizedTime value 1231235959Z in the notAfter field. Yes, identified as the "does not expire" entry. Of course, the notAfter field of the CA that signed the certificate might expire much sooner, but it could get resigned over time. The real limitation on IDevID longevity is really the cryptographic strength of the algorithms involved. > * The subjectAltName extension MAY be present in both DevID > certificates and DevID intermediate certificates. If a DevID > certificate includes a subjectAltName, that field should include a > HardwareModuleName. When a TPM is used to provide DevID module > functionality the IDevID certificate contains a subjectAltName that > uses a HardwareModuleName to identify the TPM, the hwType identifying > the TPM Version and the hwSerialNum containing the TPM Serial Number. This turns out to be a complete distraction. We had text about this in early BRSKI drafts, but the thing is that this is about identifying the TPM device itself, which is really not the IDevID. I'd have to look back in five year old emails to explain what it really was about, but the short of it is that you should just pretend you never read this part, as it really does help you. > * All certificates contain the authorityKeyIdentifier (as a non-critical extension). Yes, because identifying the CA by the SubjectDN alone is a losing proposition over the time scales involved. > * Intermediate certificates contain the subjectKeyIdentifier, as a > non-critical extension. The subjectKeyIdentifier extension SHOULD NOT > be included in DevID certificates. s/Intermediate/Subordinate/ > * If a critical keyUsage extension is included in the IDevID, it MUST > include digitalSignature. The keyUsage extension MAY include > keyEncipherment. In general, IDevID should be maximally useful, so any KU or EKU should be AVOIDED. > Is my reading of IEEE 802.1AR correct? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] draft-moskowitz-ecdsa-pki-10
Hi Henk, Frank, Michael, Bob, thanks for this document. I have a question regarding the IEEE 802.1AR-based of the description. Here is what I understand for use of certificates from 802.1AR (with my wording because RFC 2119 language is often missing in the 1AR spec): * The DevID certificate subject field is always present, but can be empty. An IDevID certificate subject field MUST be non-null and SHOULD include a unique device serial number encoded as the serialNumber attribute. The subject field can contain information identifying the supplier or manufacturer of the device. * IDevIDs SHOULD use the GeneralizedTime value 1231235959Z in the notAfter field. * The subjectAltName extension MAY be present in both DevID certificates and DevID intermediate certificates. If a DevID certificate includes a subjectAltName, that field should include a HardwareModuleName. When a TPM is used to provide DevID module functionality the IDevID certificate contains a subjectAltName that uses a HardwareModuleName to identify the TPM, the hwType identifying the TPM Version and the hwSerialNum containing the TPM Serial Number. * All certificates contain the authorityKeyIdentifier (as a non-critical extension). * Intermediate certificates contain the subjectKeyIdentifier, as a non-critical extension. The subjectKeyIdentifier extension SHOULD NOT be included in DevID certificates. * If a critical keyUsage extension is included in the IDevID, it MUST include digitalSignature. The keyUsage extension MAY include keyEncipherment. Is my reading of IEEE 802.1AR correct? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
