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

[khaja.ahmed@attbi.com]

Brian,

In section 4.1.3 the propsed truth table would be even clearer if you could 
use some verb in the "What to do column" instead of the 'ok'.  Something as 
clear as the 'fail'.

In the road warrior scenario discussed WRT to section 3.3.9.1, are there any 
disadvantages to prescribing/recommending something lighter and real time like 
OCSP?

Khaja
> 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
> briank@xythos.com
>