On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <ka...@mit.edu> 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
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to