Subject: [Sidr] Comments on draft-ietf-sidr-res-certs-07.txt

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 26 Jul 2007 10:22:13 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/sidr