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.
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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
