Re: draft-ietf-ipsec-pki-profile-01.txt

["Housley, Russ" <rhousley@rsasecurity.com>]

Brian:

I dropped the sections where we have agreement.

>>In section 3.3.9.1, it assumes that the party has ready access to the 
>>most recent CRLs, and any certificates needed to validate the CRLs.
>>In a road warrior scenario, one of the peers is in a much better 
>>situation to obtain these than the other.  Should this be discussed?
>
>I thought that 3.4.9 "Using local keying materials" covered this base
>by stating that if you've got better keymat around, use it.  Perhaps
>a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
>suggesting something more would be good?

A forward pointer would be fine, if the referenced section id beefed 
up.  Here is my issue.  Consider two peers with certificates from the same 
CA.  One is a laptop being used in a hotel room on a dial-up line.  The 
other is a server at the corporate HQ, and it has a multi-mega-bit 
connection.  Both devices should not fetch the most recent CRL from the 
CA's repository just to send it along to the peer.  The server should fetch 
it, and pass it along to the laptop in the IPsec key management exchange.

>>Please adjust the example description in section 3.3.11.3.  There is no 
>>requirement that a trust anchor be specified by a self-signed 
>>certificate.  The peer should never be asked to provide a certificate 
>>associated with a trust anchor.
>
>3.3.11.3 doesn't state that R is a self-signed certificate.  I'm
>also not sure that Trust Anchor is what most people will think of
>when they think of certificates for which they have cached the
>validity status.  I see what you're saying, but I'm not sure
>how best to say it.

The example should refer to an intermediate certificate (like CA1), not the 
trust anchor (R).

>>In section 3.4.10.5, you say: "Implementations MUST be prepared to 
>>receive certificates and CRLs which are not relevant to the current 
>>exchange. Implementations MAY discard such keying materials." I agree, 
>>but I think that the last sentence potentially confusing.  An 
>>implementation should disregard the extraneous certificates and CRLs, not 
>>the symmetric keying material that was generated.

You did not respond to this comment.

>>In section 4.1.1, I agree that v3 certificates should be required for end 
>>entity and CA certificates.  However, the same code will likely be used 
>>for several purposes, and one of them is trust anchors.
>>Self-signed v1 certificates are often used to establish trust anchors.
>
>3280 mandates that BasicConstraints appear in CA certificates, but
>doesn't appear to state that a self-signed trust anchor can
>be treated differently.  3280 does state the following:
>
>    When the trust anchor is provided in the form of a self-signed
>    certificate, this self-signed certificate is not included as part of
>    the prospective certification path.
>
>However, without going back and examining the validation algorithm,
>it's difficult to know what this means with regards to BC.
>
>In the context of IPsec, do we see many v1 certificates used for this
>purpose?  I kinda thought that v1 certificates were a dying breed.

Management of trust anchors is outside the scope of the validation 
algorithm in RFC 3280.  If self-signed certificates are used, the algorithm 
will not validate them.  They are not part of the certification path.

I would like to see v1 certificates go away too.  I do not think it will 
happen soon.  For example, there are several v1 certificates built in to 
Internet Explorer that will not expire until 2018.  Others will not expire 
until 2028.  So, if the IPsec certificates chain to these trust anchors, 
one can expect to encounter the situation that I raised.

>>In section 4.1.2.2.2, describing conventions for FQDN Host Names, I think 
>>that the SHOULD and MAY are backwards.  When a DQDN is carried in the 
>>subject field of a certificate, the domainComponent attribute SHOULD be 
>>used.  The commonName attribute MAY be used instead.  I prefer dNSName in 
>>the SubjectAltName extension to both of these!

You did not comment on this one.

>>In section 4.1.3, I do not understand the second paragraph on the 
>>criticality bit.  Implementation MUST reject a certificate if it contains 
>>an extension that it does not know how to handle with the criticality bit 
>>set to TRUE.
>
>Yes, that text is confusing, and has been rewritten a number
>of unsatisfactory times.  The point was that if you support
>(and thus are going to process) a given extension, then it
>isn't necessary to fail if the criticality bit is different
>from what PKIX states it must be.  If you don't support an
>extension you MUST be critical if PKIX says it must, and
>thus you must fail.
>
>    recognized
>    extension?    bit in cert     PKIX mandate    what to do
>    YES           TRUE            TRUE            ok
>    YES           TRUE            FALSE           ok
>    YES           FALSE           TRUE            ok
>    YES           FALSE           FALSE           ok
>    NO            TRUE            TRUE            fail
>    NO            TRUE            FALSE           fail
>    NO            FALSE           TRUE            fail
>    NO            FALSE           FALSE           ok
>
>When the bit in the cert matches the PKIX mandate, what
>to do should be obvious.  I don't recall to what extent
>3280 addresses the others.

The truth table makes your intent clear.  I suggest you use it in the document.

>>In section 4.1.3.3, I suggest that signature validation operations should 
>>proceed if either the nonRepudiation or the digitalSignature key usage 
>>bit is set in an end entity certificate.  In my opinion, digitalSignature 
>>is preferred, but nonRepudiation should be allowed.
>
>Uh oh, you don't really want to start another NR debate, do you?  ;)

No, I do not want to start another NR debate.  That is why I think that DS 
and NR should both be accepted.

>>In section 4.1.3.13, you say that no IPsec extended key usage values have 
>>been registered.  This is incorrect.  Three extended key usage values for 
>>use with IPsec have been registered.  Do you propose to deprecate their use?
>>
>>    id-kp-ipsecEndSystem         OBJECT IDENTIFIER ::= { id-kp 5 }
>>    id-kp-ipsecTunnel            OBJECT IDENTIFIER ::= { id-kp 6 }
>>    id-kp-ipsecUser              OBJECT IDENTIFIER ::= { id-kp 7 }

No response to this comment?

>>In section 4.1.3.16, you should state that most implementations do not 
>>support delta CRLs.

Do you agree?

>>In section 6.1.2.1, I suggest that signature validation operations should 
>>proceed if either the nonRepudiation or the digitalSignature key usage 
>>bit is set in an end entity certificate.  In my opinion, digitalSignature 
>>is preferred, but nonRepudiation should be allowed.

This is related to the NR vs DS discussion above.

Russ