Re: [IETF-PKIX] OCSP Current Status

[Michael Myers <mmyers@xxxxxxxxxxxx>]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <paulh@imc.org>

>At 08:59 PM 2/23/98 -0700, Michael Myers wrote:
>>OCSP is an interface specification; it exists to ensure interoperability
>>between two endpoints.  The quality of service delivered by those
endpoints
>>is more a matter of system engineering.
>
>True, but I think that this argument argues even more strongly for the
removal
>of marketing words like "efficiently and rapidly" and "timely" from the
spec.

We probably have a wordsmithing problem if that's the case since we need to
state the existence of the timeliness requirement.  OCSP owes its existence
to this requirement.  My point being that this draft is not a design spec
intending to constrain implementors so as to ensure they develop products
that will deliver timely service.



>
>>Provision for unsigned responses was in response to an observation that
>>within an enterprise, one may already be operating with a secure enclave
and
>>so have little need of the overhead of signature production.  If you and
>>others agree that this provision is unwise, I have no problem striking it
>>from the draft.
>
>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.


>
>>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.  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.

>
>>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>>would seem more appropriate, and general purpose.
>>
>>In short, yes. This topic was discussed and closed at D.C.  It enables
ease
>>of implementation.
>
>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.

>
>On a separate note, I do not think this discussion should wait until the LA
>meeting. That's more than a month away. Put out another draft and keep
>discussing it here. The IETF is designed to do most of its work on mailing
>lists (even ones with no working archives, as this one is), and use the
>face-to-face meetings for finalizing work and correcting misguided drafts.
>Unless you are lablelling this draft as misguided already, there is no need
to
>postpone the discussion on this list.


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.

>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>