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

From: Geoff Huston <[email-masked]>
Date: Sun, 19 Aug 2007 11:16:47 +1000

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Aug 2007 13:57:37 -0400

I agree with Geoff re the use of SHA-1 vs. SHA-256.

SHA-1 is called out in 3280 for SKI/AKI, although one could use other 
hash algorithms (or non-hash algorithms) for this purpose. My guess 
is that most CA software supports this.  There seem to be no serious 
security problems arising from use of SHA-1 here.  In contrast,  we 
have been advised to migrate to SHA-256 for cert signatures, at least 
until NIST certifies a replacement. So, it makes sense to call for 
SHA-256 in that context, and I have been told that software for 
SHA-256 support for signatures is available as well.