On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote: > > Benjamin Kaduk <[email protected]> wrote: > >> domainID: The domain IDentity is a unique hash based upon a > >> Registrar's certificate. If the certificate includes the > >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > >> used as the domainID. If not, then the 160-bit SHA-1 hash as > >> described in that section is to be used. This value needs to be > >> calculated by both MASA (to populate the audit log), and by the > >> Registrar (to recognize itself). > >> > >> Does this work? We are only using SHA-1 (for identification, btw, not > >> for resistence to pre-image attacks) as a last resort. > > > Sorry, I'm still not seeing the justification for using SHA-1 as the > > fallback instead of (e.g.) SHA-256. If the SKI is present, then > > definitely use that. But if it's not present, we can define whatever > > we want, can't we? It's not like "The keyIdentifier is composed of the > > 256-bit SHA-256 > > hash of the value of the BIT STRING subjectPublicKey (excluding the tag, > > length, and number of unused bits)" is an unreasonable amount of text ot > > include in the document. Now, if there's some backwards compatibility > > need > > or implementation challenge, we can talk about that, but all I'm seeing > so > > far is blind adherence to an 11-year-old document for consistency's > sake, > > and in this case I don't think consistency outweighs cryptographic > > modernization. > > Hi, we have revised the text, making use of section 2.4 from rfc7469, which > has a similar need. > > We added a new section 5.8.2, calculation of domainID: > > 5.8.2. Calculation of domainID > > The domainID is a binary value (a BIT STRING) that uniquely > identifies a Registrar by the "pinned-domain-cert" > > If the "pinned-domain-cert" certificate includes the > SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > used as the domainID. If not, then it is the SPKI Fingerprint as > described in [RFC7469] section 2.4 is to be used. This value needs > to be calculated by both MASA (to populate the audit-log), and by the > Registrar (to recognize itself). > > [RFC5280] section 4.2.1.2 does not mandate that the > SubjectKeyIdentifier extension be present in non-CA certificates. It > is RECOMMENDED that Registrar certificates (even if self-signed), > always include the SubjectKeyIdentifier to be used as a domainID. > > The domainID is determined from the certificate chain associated with > the pinned-domain-cert and is used to update the audit-log. > > and referenced this section in the terminology. This eliminates all > references to SHA-1. RFC7469 section 2.4 uses SHA-256.
Thank you! > We also strengthened our statement that the SubjectKeyIdentifier SHOULD > exist. In the process, we recognized that we had some mismatch in > (MY) thinking about pinned-domain-cert, thinking it was always the > Registrar End-Entity Certificate, when in fact it is the Registrar's > CA certificate. As a CA certificate, it SHOULD always have the > SubjectKeyIdentifier. My recollection was that it was expected to be a certificate in the Registrar's chain, probably a CA certificate but possibly an intermediate one (i.e., not self-signed). (And I see in 5280 "this extension MUST appear in all conforming CA certificates".) > We are presenting discussing whether the EE Registrar cert should get > audited. Okay, sounds good. -Ben _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
