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

From: Love <[email-masked]>
Date: Thu, 04 Mar 2004 01:50:54 +0100

"JK Jaganathan" <[email-masked]> writes:

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

Then there doesn't need to be a SEQ of OCSPResponse.

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

Yes. That would be ok.

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

Yes, but can't autoconfiguration, it have to be static policy, that is also
what I object too.

Love