RE: Online Certificate Revocation Protocol

[Peter Williams <[e-mail]>]

I suspect Massimiliano Pala is thinking about 'notifying the CA 
of the need for revocation", rather than the OCSP functions.

I too wondered about his memo. And I initially asked
myself, is it not catered for by  "revokeRequest id-cmc 17 RevokeRequest".

If, as the question suggests, there is need for uniformity
of revocation request beyond standardizing the PDU, to
cater for CP/CPS conditions, then this is interesting.

PKIX authors have a habit of putting default policy rules
into the specification of the PDU and protocols, to (apparently) promote
security and uniformity. Massimiliano Pala's message
could be taken as implying that there is now a perceived need
for a default set of policy-related issues during
revocation request noticing.
 
I am curious about the background to such a 
train of thought. Its quite timely. The human "comment" 
string in the PDU is likely to cause operational
problems these days, now that we are at (or passed) the point
in some national PKIs of responding to a request for
the revocation of what are legal-grade, national-identity 
certificates.

That CMC human readable comment is likely to be the topic of
considerable dispute in case of creation of an inappropriate and 
dis-advantegeous revocation notice.

The message certainly got me thinking about the notice requirements,
and associated issues.

Peter.

Extract:


The revocation request control attribute has the following ASN.1
   syntax:

      RevRequest ::= SEQUENCE

          issuerName      Name,
          serialNumber    INTEGER,
          reason          CRLReason,
          invalidityDate  GeneralizedTime OPTIONAL,
          sharedSecret    OCTET STRING OPTIONAL,
          comment         UTF8string OPTIONAL }

   -- issuerName contains the issuerName of the certificate to be
   revoked.

   -- serialNumber contains the serial number of the certificate to be
   revoked

   -- reason contains the suggested CRLReason code for why the
   certificate is being revoked.  The CA can use this value at its
   discretion in building the CRL.

   -- invalidityDate contains the suggested value for the Invalidity
   Date CRL Extension.  The CA can use this value at its discretion in
   building the CRL.

   -- sharedSecret contains a secret value registered by the EE when
   the certificate was obtained to allow for revocation of a
   certificate in the event of key loss.

   -- comment contains a human readable comment.




-----Original Message-----
From: Hansen Wang [mailto:[e-mail]]
Sent: Thursday, June 07, 2001 5:36 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Online Certificate Revocation Protocol


Massimiliano Pala wrote:
> 
> Hi all,
> 
> I am in search of some help and suggestions about certificate revocation.
The
> problem is that, as far as I know, no rfc covers a possible online
revocation
> protocol to be used to revoke a certificate.

Isn't that what OCSP supposed to do? RFC 2560

2560 X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin,
C. Adams. June 1999.

Also Certificate Revocation Status is also a per request - per response
system.


> 
> The model I am thinking of is request-response oriented and, depending on
> the policy adopted by the corresponding CA, permits a user/router/etc...
to
> ask for revocation of a certificate. This can help environments where
> certificates from different vendors are used and we want to be able to ask
> for revocation without having to follow different procedures for different
> CSP -- additional steps could/shall, depending on the policy adopted,
> be taken to accomplish the revocation process.
> 
> Has my problem a solution yet ??? Or can I work on a proposal to be
> submitted for comments and reviews ???

-
Hansen Wang
<http://members.home.net/hansen.wang/