Sean, *wg chair hat off* disclaimer
Thanks indeed for this, and my apologies for not responding sooner.
I searched the mail list archives messages that address these topics, if I missed them forgive me. Sec 3.9.2, 3.9.3, 3.9.6, and 4.7.1: Authority Key Identifier, Subject Key Identifier, and Authority Information Access use the SHA-1 160-bit hash of the key. Since you're using SHA-256 in the certificates why not use the SHA-256 160-bit hash in AKI, SKI, and AIA? It just seems odd you're going to get the CA to issue a certificates with SHA-256 why make them implement another hash algorithm to do SHA-1? Note - I am not raising this a security concern these fields are used as "hint" to build certificate chains.
The speficiation of SHA-1 was a direct cut and paste of method (1) of sections 4.2.1.2 and 4.2.1.1 of RFC 3280.
We are trying not to deviate from that spec, and we view this resource certificate construct as an extension profile that does not alter the remainder of the specification of the certificate's fields.
(The AIA field does not reference SHA-1)
Sec 3.9.4: (Key Usage) If the CA is going to reply with a response to a certificate-request then shouldn't the digitalSignature bit also be set? This is not required but the way it is in the draft now means the CA has a certificate to sign certificates and CRLs and another for certificate-request responses.
That was the intent, yes. This was following from the advice of Steve Kent and Russ Housley who were telling us that it made sense to limit the extent that any key would be used.
Sec 3.9.9: (Subject Alternative Name): Seems odd you'd require an X.501 name in this and the subject field (as discussed at the meeting).
Subject Alternative Name has been removed from the latest rev (-08) of the document
For Subject Name, RFC3280 states that: "The subject name field is defined as the X.501 type Name." The res cert draft states that "The value of this field is a valid X.501 name." This would appear to be consistent, ues?
Sec 5: I think you have to specify the proof-of-possession mechanism.
The issue here is that there is no "standard" proof-of-possession mechanism, so we've used the form of approach used in RFC2986, note 3, in Section 3.
Sec 5.2: (CRMF Profile): While PKCS #10 includes a security encapsulating security protocol CRMF does not. You have to specify what the encapsulating security protocol is - may I suggest a CMS SignedData.
RFC4211 explicitly does not define a certificate request protocol (as noted in the Abstract)
The res cert draft is similar in that is not not define a protocol for certificate requests, nor for any other action. The scope of the document is limited to the specification of the profile of resource certificates, the profile of CRLs, the profile of certificate requests and the definition of validtion within the scope of this profile.
We don't believe, given the scope of this draft, that it is necessary to define an encapsulating protocol for the transmission of certificate requests.
Sec 5.2.1: Need to explicitly prohibit issuerUID and subjectUID fields.
Both of these are explicitly prohibited in rfc4211. the res cert draft defines its profile as additional constraints on top of the constraints in rfc4211.
Sec 5.3: (Key Usage) Change CertificateSigning to keyCertSign and CRLSigning to crlSign. May have to add digitalSignature for CA certs (see comment on Sec 3.9.4).
To use the RFC3280 field names for the sake of consistency? Yes, fair comment - we'll make this change.
thanks, Geoff _______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
