Subject: RE: I-D ACTION:draft-ietf-cat-kerberos-pk-init-18.txt

From: "JK Jaganathan" <[email-masked]>
Date: Mon, 23 Feb 2004 14:14:26 -0800

The main point of OCSP support in PKINIT is to verify the status of the
leaf(KDC) cert without downloading large CRLs. For intermediate certs in
many cases(applications) there is no status checking. This is due to
many reasons such as that the validity of intermediate CAs is usually
considered long and these are very well protected. Also most
intermediate CAs are usually offline and are only used to grant certs to
other CAs and as such an online status check is usually not desirable.
Even if there is status checking it is usually easier to just download
the CRL since the CRLs in these cases are small. 
So I don't think we need to build a mechanism into PKINIT for checking
the status of intermediate certs or that it would be used in real world
scenarios if we do. Note that OCSP is not used to build the trust chain
itself but only to verify the status of the cert.
I agree that we need to specify the behavior when responderIDList is not
sent especially since this will be the common case. How about this? 
"In the case that the responderIDList is not sent or is empty then the
OCSP response must be signed by the authority issuing the certificate
unless explicitly specified otherwise by a mutually agreed policy
between the client and the KDC"
The client list of responderIDs would be maintained by policy if it is
used. In many cases I suspect the list would be empty or small enough to
be configured through policy on the client. 
> -----Original Message-----
> From: Love [mailto:[email-masked]] 
> Sent: Monday, February 23, 2004 10:26 AM
> To: JK Jaganathan
> Cc: [email-masked]; Brian Tung
> Subject: Re: I-D ACTION:draft-ietf-cat-kerberos-pk-init-18.txt
> 
> 
> "JK Jaganathan" <[email-masked]> writes:
> 
> > The purpose of the OCSP support in PKINIT is not for the 
> client to be 
> > able to issue an OCSP request directly but rather it 
> requests the KDC 
> > to provide an OCSP response. We believe the KDC will have better 
> > connectivity to the OCSP responder and also it will be able 
> to cache 
> > the OCSP responses.
> 
> My point is that the client may want to verify the whole 
> certificate chain with ocsp, and from what I understand, the 
> kdc have no idea of that. If the KDC should should send back 
> OCSP responses for all certs, I think this should be stated.
> 
> Since the PA-PK-OCSP-REQ fields are optional, I think you 
> have to describe the behavior when responderIDList isn't send.
> 
> How is the client supposed to know the list of 
> responderIDList ? And how to keep it uptodate, it seems to be 
> able to change w/o notice ?
> 
> Love
> 
>