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. 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. 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). Sec 5: I think you have to specify the proof-of-possession mechanism. 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. Sec 5.2.1: Need to explicitly prohibit issuerUID and subjectUID fields. 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). spt _______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
