[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: I-D ACTION:draft-ietf-ipsec-pki-req-05.txt


Hi,

Some comments on the latest pki-req draft....

1) In section 5. Algorithm Requirements

Based on the number of odd OIDS I've seen for sha-1WithRSAEncryption and
id-dsa-with-sha1, I would suggest we either include the actual numeric oids
in this document, or reference the sections in RFC2459 (or son of) where
they are specified (7.2.1 for sha-1WithRSAEncryption and 7.2.2 for
id-dsa-with-sha1)

2) In Section 6.1 paragraph 3

> In order to protect the identity in a Certificate payload, the IKE
> device that wishes to deliver its own certificates to its peer MUST use
> Main Mode MUST only include Certificate payloads in message 5 or 6.
           
I *think* you wanted to say ".....its peer MUST use Main Mode *and* MUST
only include...." 

3) In Section 7.1

> 2. Create a PKCS #10 [RFC-2314] object that includes the public key
>    portion of the key pair. This object MUST NOT use any PKCS #10
>    extensions.

I just noticed the "MUST NOT use any PKCS #10 extensions" statement.  Looks
like this was also in the -03 and -04 versions.  First of all I think the
word "extensions" is not correct here.  I believe we are referring to
PKCS#10 attributes, specifically the use of the extensionReq attribute
defined in PKCS#9, right?  Anyway, based on workshop experience, there are
quite a few implementations that use this attribute to request the
subjectAltName value.  What is, or what was, the reason to make it a "MUST
NOT"?   

4) Further down in Section 7.1

> message as the Base64 transformation of the PKCS #10 object. That
> Base64 object SHOULD be preceded with either the line:
> 
> -----BEGIN CERTIFICATE-----
> 
> or the line:
> 
> -----BEGIN CERTIFICATE REQUEST-----

Why would a pkcs#10 certificate *request* be wrapped in a -----BEGIN
CERTIFICATE----- line?  Are we trying to document what implementations are
currently doing?  Or specifying what implementations *should* be doing.  If
its the latter, then we shouldn't specify that people use the -----BEGIN
CERTIFICATE----- wrapper for certificate requests.  If its the former, we
should strongly recommend -----BEGIN CERTIFICATE REQUEST-----

5) 
> [[[ OK, folks, that really doesn't help on interoperability. Should
> we pick one of those four as a SHOULD? ]]]

I vote for the first one "- A PKCS #7 object holding the certificate"  

6) In section 10. References

Believe it or not, CMC is now officially RFC 2797.

7) In Appendix A. Change History

> 7. (A.) Added "Note that P10POUB using PKCS7 responses is one mode of
> CMC."....

I didn't see this in the main document.  Did it get lost?

Alex