Subject: OCSP thoughts

From: Sam Hartman <[email-masked]>
Date: Sat, 26 Jun 2004 19:05:11 -0400

Greetings, folks.  I've been migrating to a new laptop so I haven't
had the opportunity of participating in the OCSP discussion in real
time.  However I do have a few thoughts after reading all the messages
in this thread.

A lot of the discussion seems to focus on process issues.  For
example, Nico believes it is lame to include a feature because there
is insufficient motivation to standardize it on its own.  Sasha and
Eric are concerned that this will delay the document and is
unnecessary.

It's not wrong to consider these process issues, but I believe that in
this case, resolving the process debate may take longer than resolving
the technical issue.  I'd hate to spend longer deciding whether OCSP
tunneling has met some barrier for inclusion at a process level than
we do deciding how to specify it and whether it is a good idea at a
technical level.   

Even from the people who believe the current process debate is
important, I'd appreciate a few minutes of consideration to some
technical questions:

1) Is OCSP tunneling a useful feature in some pkinit environments?

2) Is OCSP tunneling a useful feature in most open pkinit
   environments?  By open, I mean environments where multiple
   different implementations are likely to be involved as opposed to
   closed enviroments like Cable Labs.  If I need to do a better job
   of specifying what I mean by this question or why I think it is a
   useful question, please ask.

3) To be useful, does OCSP tunneling need to be a SHOULD/MUST or is it
   useful as a MAY?

4) If OCSP tunneling is not available, how should a client proceed in
   order to be interoperable?

5) Do we believe we understand how to specify OCSP tunneling well
   enough to do a good job now?

6) Do we believe we understand OCSP tunneling well enough to do an
   efficient job?  Do we believe we have enough qualified reviewers?

7) Could OCSP be specified without updating the pkinit protocol?

I will give my opinion on these questions in a separate message.

--Sam

---

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 30 Jun 2004 16:39:20 -0400

>1) Is OCSP tunneling a useful feature in some pkinit environments?

In "some" environments - Yes.   The bigger question is how to
measure the usefulness in relation to the burden it will place
on this group to hash out all the technical issues.   Is it
useful enough to warrant further delay of this spec?

>   useful question, please ask.

How many people have OCSP enabled in their browsers today? I'd
guess that its a VERY small percentage.  If it's not important
enough (or useful enough) to be enabled and used for things
like online banking and handling sensitive personal information,
then maybe OCSP isn't really that useful in this environment either.

I think that in order for interop in an open environment to succeed,
then OCSP support must be optional on all sides or else there will
be various non-interoperating implementations.

>3) To be useful, does OCSP tunneling need to be a SHOULD/MUST or is it

"MAY", if at all.

>   order to be interoperable?

It should not be required for interoperability.  Imagine one implementor
making its client require an OCSP response.  But when it talks to another
implementation's KDC (which does not support OCSP tunnelling), the client
fails.  The client vendor then says "well, you have to use our server
in order to use PKINIT".    All of a sudden, interop is lost and
the user is locked into one vendor's solution.  

-Wyllys Ingersoll