Re: [secdir] SECDIR review of draft-ietf-pkix-other-certs-04

[Stephen Farrell <[e-mail]>]

Thanks Richard,

I'll roll changes for those comments into a rev of the document whenever
the AD says to do so.

Cheers,
S.

Richard Barnes wrote:
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir