I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.
This documents creates a certificate extension that allows the issuer of
a certificate to assert that the subject of the certificate is the same
as that of a set of other certificates (i.e., that the same entity holds
all the corresponding private keys). This extension clearly creates
some impersonation risks, but the document provides sufficient advice to
CAs to mitigate these risks.
Overall, I think the document is basically ready for publication. Some
comments, mostly editorial, follow below.
--Richard
-----
Section 1, Paragraph 2
s/assoicate/associate/
Section 1, Paragraph 3
To be clear here and decouple this paragraph from the last, I would
replace the phrase "... supports such linkage" to something like "...
allows a certificate issuer to attest that the end entity that holds the
private key for the certificate in question also holds other private
keys corresponding to other certificates." This change also clarifies
why you refer to "end entities" below instead of just "subjects".
Section 2, Paragraph 3
Change "... change CA when renewing its certificate" to "... change CA
when replacing its certificate". Renewal only happens with the same CA.
Section 3, ASN.1 fragment
Change "::==" to "::=".
Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para)
The first sentence in this paragraph seems very vague -- what does it
mean for a use of this extension to be "safe"? Suggest replacing with a
requirement that is notably absent from this paragraph, namely that "CAs
MUST issue a certificate containing this extension only after they have
validated that the holder of the private key for the certificate also
holds the private keys for linked certificates."
Section 3, Paragraph 6 (same as above)
Do you mean to have both requirements in the final sentence as "SHOULD
NOT"? It might be helpful here to note how the "purpose" a certificate
might be determined, e.g., via CP or EKU OIDs.
Setion 3, Paragraph 10
The validation procedure in RFC 5280 requires an RP to verify that a
certificate has not been revoked (Section 6.1.3, step (a)(3)), so the
initial conditional can be omitted. This requirement is really
important for this extension, since one reason that certificates get
revoked is private key compromise, in which case a party other than the
intended subject has possession of the private key (by definition).
This situation would allow the attacker to obtain linked certificates
even from a CA that complies with this document.
Section 3, Paragraph 12
It would be helpful to clarify why this restriction is in place, e.g.,
"Since CA certificates are only used for certificate validation, and
this extension has no effect on the validation procedure, this extension
is meaningless for CA certificates."
Section 5
It's not clear that this section belongs in this document. It would not
reduce the clarity of the document to remove it.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf