Re: [IETF-PKIX] OCSP Current Status

[Paul Hoffman / IMC <paulh@xxxxxxx>]

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1 than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand that
your protocol be changed, even if the bits on the wire don't change. Further,
if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm not
advocating this, since I happen to like ABNF more than ASN.1, but it is up to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium