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

From: "JK Jaganathan" <[email-masked]>
Date: Fri, 20 Feb 2004 18:13:37 -0800

I don't know why the citations did not come up properly in the draft but I am including the original text below.
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.

Original text below with citations:
OCSP request /response:
OCSP (Online Certificate Status Protocol) allows the use of online requests for a client or server to determine the validity of each other's certificates. It is particularly useful for clients authenticating across a constrained network. These clients will not have to download the entire CRL to check for the validity of the KDCs certificate. 
In these cases the KDC generally has better connectivity to the OCSP server and therefore it processes the OCSP request and response and sends the result to the client. The changes proposed below allow a client to request a OCSP response from the KDC when using PKINIT. This is similar to the way OCSP is handled in [TLSEXT] OCSP support is provided in PKINIT through the use of additional PA-DATA elements. The following PA-DATA elements are defined PA-PK-OCSP-REQ ::= SEQUENCE {
       responderIDList         [0]  SEQUENCE OF  ResponderID OPTIONAL
                                      ---- ResponderID is a DER encoded
                                     ----  ASN.1 type as defined in [OCSP]
       request_extensions                [1] Extensions  OPTIONAL
                                     ---   Extensions is a DER encoded
                                     ---- ASN.1 type as defined in [OCSP] }

PA-PK-OCSP-REP ::= SEQUENCE OF OCSPResponse
                               --- OCSP Response is a DER encoded ASN.1 type as defined in [OCSP]

A KDC that recieves a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP. KDCs MUST NOT send a PA-PK-OCSP-REP if they do not recieve a PA-PK-OCSP-REQ from the client. The KDC may either send a cached OCSP response or send an online request to the OCSP responder.
 
When using OCSP the response is signed by the OCSP server which is trusted by the client. Depending on policy configurations further verification of the validity of the OCSP server may need to be done. 

   [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. 
      and Wright, T., ôTransport Layer Security (TLS) Extensionsö, RFC 
      3546, June 2003

   [OCSP]         Myers, M., Ankney, R., Malpani, A., Galperin, S. and
                  C. Adams, "Internet X.509 Public Key Infrastructure:
                  Online Certificate Status Protocol - OCSP", RFC 2560,
                  June 1999.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Love
> Sent: Friday, February 20, 2004 10:30 AM
> To: [email-masked]
> Cc: Brian Tung
> Subject: Re: I-D ACTION:draft-ietf-cat-kerberos-pk-init-18.txt
> 
> 
> [email-masked] writes:
> 
> > 	Title		: Public Key Cryptography for Initial 
> Authentication in Kerberos
> 
> I spent two hours trying understand this version draft, below 
> are my comments so far.
> 
> Love
> 
> - TrustedCAs, make sure its compatible with -16 version.
> 
> - INTEGER usage ? should be uint32/int32 ?
> 
> - AnotherName is specified in RFC3280, drop
> 
> - Name is missing in IMPORT
> 
> - ValidationParms, isn't used (its part of DomainParameters)
> 
> - DomainParameters, isn't used but named, so I guess its ok 
> to import (but still pointless)
> 
> - EncryptionKey, PrincipalName, Realm, KerberosTime, 
> Checksum, TypedData should be IMPORTed from krb5 
> kerberos-clarifications.
> 
> - TypedData is named to TYPED-DATA in clarifications-05 AFAICT
> 
> - krb5 oid is defined in clarifications-05, but there it is 
> named id-krb5
> 
> - General question; should there be a kerberos nonce type in 
> clarifications
>   and should it be used by 
> 
> -- OCSP comments
> 
> I can't match what the author of this section match to 
> RFC2560.  For example, ResponderID is part of the ocsp 
> response not the request. And its the OCSP responders id, why 
> should a client ask for that ?
> 
> And before I read rfc2560, thinking that this text simply 
> should be dropped.
> 
> "The changes proposed
> in this section allow a client to request an OCSP response 
> from the KDC when using PKINIT."
> 
> What document is sited here ?
>  "This is similar to the way that OCSP is handled in [cite]."
> 
> Reading rfc2560, I can only say that PA-PK-OCSP-RE{Q,P} 
> should look like below
> 
> "The KDC MAY refuse to relay requests for certificate(s) that 
> isn't for it own certificate, or any of it peer KDCs 
> certificates, or any certificates in the chain."
> 
> PA-PK-OCSP-REQ ::= SEQUENCE
> 	request		[0] OCSPRequest,
> 	...
> }
> 
> PA-PK-OCSP-REP ::= SEQUENCE
> 	response	[0] OCSPResponse,
> 	...
> }
> 
>

---

From: Love <[email-masked]>
Date: Mon, 23 Feb 2004 19:25:59 +0100

"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