Subject: RE: PKINIT open issues

From: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 23 Jun 2004 08:46:07 -0600

I strongly object to including OCSP tunneling. First, OCSP tunneling is one mechanism, among many, to convey revocation information. It seems best to specify individual mechanisms in separate documents. 

Second, it is expanding the scope of PKINIT, which can only further delay an already overdue document. We have been pushing PKINIT for almost a year now; two planned "last call" dates have come and gone, and the document doesn't seem to be any closer to RFP status, as indicated by the ever expanding list of open issues. I believe the WGs focus should be on finishing a tighly scoped PKINIT document.

-Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750

Email: [email-masked]
Phone: 303-661-3841
Fax: 303-661-9199

-----Original Message-----
From: JK Jaganathan [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2004 1:05 PM
To: Jeffrey Altman; [email-masked]
Cc: Liqiang(Larry) Zhu; Sam Hartman
Subject: RE: PKINIT open issues

 I'm reviving this thread since Sam and Jeff brought up this topic while they were in Seattle. 
We generally agree that OCSP tunnelling support is useful as it permits caching at the KDC and it allows OCSP to be used when the client does not have direct connectivity to the OCSP responder. 
Also it is unlikely that this will have sufficient momentum to be standardised by itself outside of PKINIT. For these reasons we believe it is appropriate to retain OCSP tunnelling in the PKINIT draft.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> JK Jaganathan
> Sent: Wednesday, April 21, 2004 12:33 PM
> To: Jeffrey Altman; [email-masked]
> Subject: RE: PKINIT open issues
> 
> The OCSP tunneling logically belongs in the PKINIT draft. I 
> haven't heard any clear arguments for moving it to another 
> draft other than 'it can be done'. I don't see how it would 
> hold up the PKINIT draft in anyway. What are the major 
> technical objections here? The same work has already been 
> done for TLS so we are not doing something that is a major addition. 
> I very much doubt the OCSP work would be standardized if we 
> had to go through a whole separate draft process. 
> 
> ________________________________________
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Jeffrey Altman
> Sent: Tuesday, April 20, 2004 12:45 PM
> To: [email-masked]
> Subject: Re: PKINIT open issues
> 
> Nicolas Williams wrote:
> 
> I'm for moving the OCSP tunneling to a separate draft.  It's 
> a new feature that, unlike the CAs-verified authz-data 
> element, isn't crucial for security and interoperability, 
> even if it is desirable.
> 
> Nico
> I concur.  OCSP should be moved to a new draft.
> 
> Jeffrey Altman
> 
> 
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Jun 2004 15:48:11 -0400

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:

    Eric> I strongly object to including OCSP tunneling. First, OCSP
    Eric> tunneling is one mechanism, among many, to convey revocation
    Eric> information. It seems best to specify individual mechanisms
    Eric> in separate documents.

Is their another mechanism within the scope of the IETF?