[IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

I submitted this message to the list yesterday, but I haven't seen it
show up yet.  My apologies to anyone who receives it twice.

>----------
>From:  Robert Zuccherato
>Sent:  Tuesday, February 24, 1998 11:46 AM
>To:    'IETF X.509-based public key infrastructure mailing list'
>Cc:    'mmyers@verisign.com'
>Subject:       RE: [IETF-PKIX] OCSP Current Status
>
>Mike;
>
>----------
>From:  Michael Myers[SMTP:mmyers@verisign.com]
>Sent:  Monday, February 23, 1998 10:59 PM
>To:    IETF-PKIX@LISTS.TANDEM.COM
>Subject:       Re: [IETF-PKIX] OCSP Current Status
>
>You raise a number of very good points which I hope to resolve at the LA
>IETF.   These are my views.  In the interests of expediency, I suggest  we
>convene an ad-hoc subgroup at LA to deal with these issues and deliver to
>PKIX our joint resolution.
>
>I think that there are more than just a few people who are interested in this
>draft.  Meeting in the back room of a smokey bar doesn't allow for full,
>public discussion of these ideas.  Why don't we try and resolve these issues
>on the list.
>
>-----Original Message-----
>From: Robert Zuccherato <robert.zuccherato@entrust.com>
>To: 'IETF X.509-based public key infrastructure mailing list'
>
>>1) You continue to maintain that OCSP gives "timely" status information
>>and does so "efficiently and rapidly".  I guess this statement depends
>>on what your definition of "timely" is.  It seems to me however, that
>>there is a tradeoff.  In order to get current status information, the
>>responder must produce only fresh responses and sign each one.  This
>>does not seem to be efficient and rapid, and certainly isn't scalable.
>>In order to be scalable, the responder must use pre-produced responses
>>and chaching.  This doesn't provide timely status information (at least
>>no more than using a CRL).  I think the document should make this choice
>>clear.  Many people still believe that OCSP can give them both current
>>status information and scalability.
>
>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.   By analogy, consider that some
>Internet throughput needs are met by a 28K modem while other environments
>need, say, an OC3-size pipe.  In either case, TCP/IP flows across the wire
>to accomplish the interface.
>
>Presently, the draft talks about "timely" status information, being able to
>"efficiently and rapidly determine status information", using caching and
>response pre-production, using a nonce, etc.  It doesn't mention that using a
>nonce to produce timely status information does not allow efficient and rapid
>status information to be provided to a large number of people.  It doesn't
>mention that using caching and response pre-production doesn't allow timely
>status information.  These are not only system engineering problems, they are
>security issues.  This service has been advertised as providing up-to-date
>revocation status, but it cannot do so under all circumstances.  This should
>be made clear to all those using the service.
>
>>2) The draft still has no explanation of how one is to get the
>>verification key for the OCSP responder.  The document should clearly
>>explain that there are (at least) two options.  You can have the key
>>installed, but then you cannot revoke it.  If you run into trouble with
>>the responder's key, it is the same as losing the CA's key, you have to
>>start over.  Or, you can issue the OCSP responder a certificate and
>>revocation is possible by placing the certificate on an ARL.
>
>Here again I would assign this scope to a systems-level key management
>document. The diversity of options at this layer of the architecture
>strongly suggests there can be no one standard way of managing an OCSP
>responder's key(s).   Further, there's no reason that OCSP should operate in
>isolation of CRLs.  Again, I would leave this up to the PKI systems
>engineers to choose the configuration that best meets their local security
>policy needs.  Bearing in mind that the primary intent of revocation in this
>case would be to inhibit further use of a private key, one very effective
>way of revoking a responder's key is to take away its PCMCIA token, assuming
>that particulary key management decision was made by the system architect.
>
>I agree that there doesn't have to be one standard way to manage an OCSP
>responder's key(s).  Implementer's must be made aware, however, that if you
>choose one option, revocation is not possible, and if you choose another
>option, revocation is possible, but you must place the responder's key on an
>ARL.  This is a basic security requirement for an OCSP responder and should
>be discussed in the document, regardless of some future systems-level key
>management document.
>
>>3) The server still responds with VALID and INVALID, but certificates
>>are only valid with respect to a specific certification path and
>>explicitly stated policy.  There is a policy extension, but there is no
>>way to pass in a certification path for which validity is to be
>>determined.  Also, it appears to me that the responder doesn't have to
>>pay attention to the policy extension.  The service as presently
>>designed, really indicates whether or not a certificate is revoked, and
>>the responses should reflect this.
>
>May I ask that you provide a link-by-link example of how such chains would
>work in practice, starting with the public key needed to validate the
>signature on the subject certificate?  By "link" I mean "x-signs-y".
>
>Surely I don't have to explain how to do certificate path validation.  In
>order to validate a certificate, both a certificate path and a policy OID are
>required.  Policy mappings will not allow this to be done one certificate at
>a time.  If you do not want to allow both a certificate chain and policy OID
>in the request, then the best you can do is to determine the revocation
>status of the certificate.  If you want to determine certificate validity,
>then you must give the responder both the certificate chain and policy.
>
>>4) Unsigned error messages are still allowed.  This, of course, allows
>>anyone to produce responses to an OCSP request.  The statement is made
>>"It is reasonable to ask for error messages to be signed to address this
>>vulnerability."  I do not see how to ask for only signed responses in
>>the request however.
>
>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 do fear however that such a practice would evolve anyway,
>so we should also keep in mind  the utility of maintaining the provision as
>a means of achieving some level of interoperability.
>
>Again, since this is a security issue, the fact that unsigned messages should
>only be used within a secure enclave should be explicitly mentioned in the
>draft.  Otherwise, signed error messages must be used.
>
>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.  I doubt that an organization operating a
>responder that produces signed responses (ostensibly for the purposes of
>non-repudiation) would be willing upon request to produce any other type.
>Similarly, an organization that choses for reasons of expediency to not
>sign responses would most likely not be well positioned to selectively
>produce signed responses.
>
>Presently, the draft allows a server to produce all signed, all unsigned, or
>any combination of signed/unsigned error responses.  Your comment in the
>third paragraph of Section 5 seems to indicate that signed messages can be
>requested by the client.  Unless we specify exactly when signed/unsigned
>responses can be used (for example in a secure enclave, as discussed above),
>we should provide the mechanism that you allude to.  We should allow clients
>to request a signed error message in situations where it is not clear what
>they will get back, and they want to be sure someone isn't just sending back
>the unsigned response.
>
>>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.
>
>See other messages on the list, posted by others, on this topic.
>
>       Robert.
>
>
>