Re: [IETF-PKIX] OCSP draft 2

[Michael Myers <mmyers@xxxxxxxxxxxx>]

Marc,

A very thorough review and much appreciated.

Mike

-----Original Message-----
From: Marc Branchaud <marcnarc@XCERT.COM>
>
>(1) There's very little "online" about this protocol.  It's basically a
>mechanism for server-based CRL processing, with specific reference to the
>validation logic in PKIX1.
>
>There's nothing wrong with that.  It allows for thin clients that don't
have
>to bother with CRLs, which I think is great.  But because of this I don't
>think that words such as "timely" belong in the draft, because there's
>nothing that ensures the timeliness of a response any more than if CRLs
were
>used directly.  Indeed, calling it "OCSP" at all goes against my (probably
>skewed) pre-conceived notions of what an online status protocol should do,
>which is get status information as straight from the CA's mouth as
possible.


I'm having trouble understanding this line of reasoning.  OCSP exists
specifically to address timelineness issues.  True, the specification
enables one to take advantage of caching, but it doesn't mandate that you do
so.  If you have customers who need a real-time production of a
certificate's status, this is what OCSP is for.  I know I do.  One the other
hand, that same mechanism can be relaxed for CA key pairs that represent
customers with less stringent timeliness needs.

>The current proposal does no such thing.  In fact it's "caching" mechanism
>isn't really about a cache of responses from other OCSP servers or CAs, but
>is instead a way to preserve the results of certificate chain processing
>(incurred when the certificate's status is first determined).  For these
>reasons I propose that the draft be renamed "Server Based CRL Processing"
or
>some such thing.  On the other hand, Carlisle's right that there's nothing
>here that can't be done within the Notary Protocol draft.

As I said, the specification does not require one to implement caching.  You
can certainly take advantage of it if meets the needs of your customers or
market.  One way I've heard proposed is to acquire a certificate's status
through an LDAP directory.

I'm beginning to wonder though if the value-added variations of the proposed
Notary Protocol may have less to do with PKI (or PKIX) than with other fora
where such contexts are well defined.  Where, for example, is the boundary
between PKI and electronic rights management?  A bank's management of its
customer's accounts?  The validity of an electronic stock trade request?
The up-to-the minute validity of pre-established IPSEC Security
Associations?  How does the notary protocol help me revoke a signed object
distributed throughout an enterprise?

I first need a simple, workable, imlementable, deployable alternative to
CRLs.  This is OCSP.

>
>(2) There's been some call for the protocol to use ASN.1.  I agree with
those
>comments, and I would even attempt to propose some actual ASN.1 to get
things
>started were it not for some confusion I have about various parts of the
>draft (I'll get to those below).

I believe we've fairly well resolved this issue.  ASN.1 for ASN.1's sake is
an endless debate.

>
>(3) Let me restate my opinion that this protocol should not be tied to
HTTP.
>Although HTTP, particularly 1.1, may be well suited for the protocol, it
also
>makes sense to allow it to be implemented using CMP or SMTP or whatever
other
>P people might fancy.  Note, too, that the richness of HTTP 1.1's cache
>control is hardly needed with this protocol's notion of "caching" anyway.

Early readers of the OCSP drafts will recall that it was cast into a
transport-independant framework, which was subsequently judged to be
overkill for the scope of the problem.

If you or someone else wishes to produce an I-D that details transport of
OCSP request and response in, say, SMTP, then we would have the basis to
consider a multi-draft approach to the specification.  Until then, there
needs to be at least one transport to ensure interoperability among those
who choose to implement OCSP.

I would however debate the validity of the claim that CMP is a transport
mechanism in the same sense that HTTP, SMTP, FTP or LDAP are transports.

>
>(4) The draft says that definitive response messages SHALL be digitally
>signed.  This is good for providing some degree of non-repudiation, but I
>would suggest that signed responses be optional (or be "SHOULD" at most) to
>allow for SSL-authenticated connections when non-repudiation isn't a
>requirement.  Granted, for individual requests there isn't much benefit as
>the crypto would get done somewhere anyway, but a single SSL connection
could
>support several requests, which would make things a lot faster.

This is a good point that's been brought up earlier.  It would be useful to
detail out how SSL would be used in this context.  May I ask that you
provide some text that I could drop into the draft?

>
>(5) In the middle of page 6 there's mention of the "value '2' for the
>version field" but there is no definition of a "version" field.

I should have deleted that sentence in view of the simplification
of the top-level specification of a request which reads:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]

I would hope that the presence of "/ver/1" requires no further explanation.

>
>(6) On page 7 it says that the requester's signature is computed over { url
>request target extensions sig-fields } but "request" isn't defined
anywhere.

Good catch.  The syntactic definition of "request" was absorbed into the
definition of "OCSP-request".

Given the specification of:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]
[signature] [extensions]

The signature should be calculated over the first four elements.


>
>(7) Just below that, it says that the responder "verifies the signature,
>using the public key identified by key-id and the requester certificate
>extension defined below."  Shouldn't that "and" be an "or" since extensions
>are optional?

Yes.  I'll amend the text to reflect the optional inclusion of extensions in
this context.

>
>(8) Section 4.3 describes the cryptographic algorithm requirements of
>clients, but makes no mention of responders.

Yes, responders would be required to implement according to these
requirements as well.

>
>(9) The Requester Certificate extension (section 4.4.2) specifies the use
of
>MD5 for producing the reqid.  Shouldn't SHA1 be used here as it is
everywhere
>else?

Yes, this has been brought to my attention by others.  It should be SHA1
throughout.

>Also, a note in this section suggests that several certificates may
>need to be passed to the OCSP responder.  Wouldn't this be better served by
>POSTing them?  Taking that idea further, it seems to me that these extended
>request strings are getting awfully long and that the whole protocol would
be
>better served by using POST exclusively instead of GET.

>
>(10) The "/ocsp/ver/1/" defined in section 4.1 doesn't match the "/status/
>check/ver/1/" used in the examples from section 4.6.

Done.

>While we're on it,
>what's the advantage of using "/ver/1/" instead of "/ver1/" or just "/v1/"?

The latter point is intended to align the more general syntatic concept
of {name, value} so that in implementation the code structure would
be more uniform.

>
>(11) Finally, the distinction between minimal and definitive error
responses,
>and between error and definitive responses, is fairly muddled and needs to
be
>made more explicit earlier in the draft.

OK.

>
>
>To sum up, I think the basic idea behind this draft -- to offload CRL
>processing from client applications -- is good.  But I also think that the
>draft's title is misleading.  What's more, it could be specified as a
profile
>of the Notary protocol, but I don't mind it remaining a stand-alone
document.
>Either way, it needs substantial changes before going to last call.



Appreciate the review.  It will help in tightening it up and moving OCSP
forward.

As for the larger issue of just how far we can legitimately extend
PKIX protocols into what might arguably be considered non-PKI realms,
I'll leave that debate to the list.


>
>                Marc