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

[Brian Korver <[e-mail]>]

Russ,

I'll send issues I'd like to see more discussion of
to the list as new threads.


On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
> 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.

How about if I put in your example here along with the
suggestion that the gateway can elide CRL CERTREQs
to save the road warrior from possibly having to
obtain the most up-to-date CRLs from the CA.  I think
the example would be best put in 3.3.7.


>
>>> 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).

I'll change R to CA3 and add ", which can be a self-signed root
or any other trust anchor".


>
>>> 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.

I agree with you.



>>> 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.

Agreed, and if you suddenly think of a really good way to
explain this in the text, let me know.


>
>>> 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.

Let's talk about this in Atlanta.  I'm surprised the NR bit is
being used this way and so a little explanation is probably
in order.


>>> 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?

I don't have any problem with deprecating this.  I just didn't
think it was necessary.  Done.


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

Yes.


>
>>> 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.

Right.

-brian
[e-mail]