https://tinyurl.com/y2skc9xz
Michael Richardson <[email protected]> wrote: >> o The subject-alt field's encoding MAY include a non-critical >> version of the RFC4108 defined HardwareModuleName. (from [IDevID] >> section 7.2.9) If the IDevID is stored in a Trusted Platform >> Module (TPM), then this field MAY contain the TPM identification >> rather than the device's serial number. If both fields are >> present, then the subject field takes precedence. >> "if both fields are present", but the subject field MUST be present, so >> this field can never take precedence. > I'm willing to drop, because I never got proper clarification. > We were told by implementors that if the IDevID is contained in a TPM that > the resulting IDevID often has the serialNumber of the TPM,not the device > itself. > *** MAX *** >> 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the >> Distinguished Name "serialNumber" attribute. [RFC4514] indicates >> this is a printable string so no encoding is necessary. >> I don't understand why these references were chosen. Why are LDAP specs >> authoritative about what the encoding format for the serialNumber DN >> attribute is? E.g., one could look at RFC 5280 to see that >> X520SerialNumber is a PrintableString. > *** MAX *** We have simplified the text, removed the TPM and Hardware Module Name, etc. and clarified why we are referencing the LDAP RFC. We have left an out that says that the Registrar may need to dig elsewhere on a per-manufacturer basis. >> o In the language of [RFC6125] this provides for a SERIALNUM-ID >> category of identifier that can be included in a certificate and >> therefore that can also be used for matching purposes. The >> SERIALNUM-ID whitelist is collated according to manufacturer trust >> anchor since serial numbers are not globally unique. >> RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in >> the model of RFC 6125" or "provides a new SERIAL-ID category" or >> similar. > I have an open request to *** MAX *** to clarify this part. We have resolved by this removing the reference to RFC6125. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
