Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> 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.

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.

We are presenting discussing whether the EE Registrar cert should get
audited.


-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-