Subject: Online Certificate Revocation Protocol

From: Massimiliano Pala <[email-masked]>
Date: Fri, 08 Jun 2001 01:24:32 +0200

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.

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

Looking forwards for comments.

-- 

Best Regards,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                     [email-masked]
http://www.openca.org                            Tel.:   +39 (0)59  270  094
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

---

From: Peter Williams <[email-masked]>
Date: Thu, 07 Jun 2001 18:41:28 -0700

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:[email-masked]]
Sent: Thursday, June 07, 2001 5:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Online Certificate Revocation Protocol

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

> submitted for comments and reviews ???

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

---

From: Frank Balluffi <[email-masked]>
Date: Thu, 07 Jun 2001 19:59:41 -0700

Yes. It sounds like a job for section 3.3.15 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-04.txt.

Frank

> From: Carlin Covey [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 9:18 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Online Certificate Revocation Protocol
> 
> 
> Massimiliano,
> 
> If you are interested in a protocol that indicates whether a
> certificate has been revoked, then the OCSP document that Hansen
> referred you to is appropriate.  You can get it at
> http://www.ietf.org/rfc/rfc2560.txt)
> 
> Version 2 of the OCSP protocol is described in an Internet Draft
> available at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-02.txt
> 
> Simple Certificate Validation Protocol is another candidate.  You
> can get the latest version of this at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-05.txt
> 
> But none of these allow a certificate to be revoked. I gather that
> you are interested in a protocol for requesting revocation of 
> certificates.
> Check out CMP, available at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-04.txt
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Hansen Wang
> > I am in search of some help and suggestions about 
> certificate revocation.
> The
> > the policy adopted by the corresponding CA, permits a 
> user/router/etc...
> to

---

From: "JANES, Mark" <[email-masked]>
Date: Fri, 8 Jun 2001 15:31:03 +0100

Does anyone know what implementations of CMP exist?

Thanks,
Mark Janes
Principal Technical Architect
e-Government Services
SchlumbergerSema UK Region
*Office:	(+44) (0) 1625 88 4698 NNH Wilmslow
*Fax:		(+44) (0) 1625 530 911 NNH Wilmslow
*Mobile:	(+44) (0) 7733 310 313
* Email:	[email-masked]
* Postal:	Ground Floor East, Norcliffe House, 
		Station Road, Wilmslow, SK9 1BB

-----Original Message-----
From: Nada Kapidzic Cicovic [mailto:[email-masked]]
Sent: 08 June 2001 12:21
To: [email-masked]; [email-masked]
Subject: Re: Online Certificate Revocation Protocol

At 11:01 AM 6/8/01 +0200, Massimiliano Pala wrote:
>Carlin Covey wrote:
certificates.
>This could be the case, anyway I was thinking of something more "robust"
>and a little bit complex -- as request/response contents -- to prevent
>unauthorized revoking requesting to prevent as much as possible DoS but
>allowing for a simple revocation method. This could help environments where
>legal issues are also covered -- govenment PKIs, Municipalities PKIs,
>etc...

This is exactly what CMP specifies. Many vendors already have support for 
CMP EE initiated certificate revocation. The interoperability of different 
implementations of CMP certificate revocation (among other things) has been 
conducted during PKI Forum and ICSA CMP interop testing quite successfully.

Nada

>The model I've been thinking of is mostly based on a structure very similar
>to the model proposed in OCSP. The choosen transport mechanism could be
>HTTP -- this could help browsers in adding the functionality and CSP to
>implement the service.
>
>--
>
>C'you,
>
>         Massimiliano Pala
>
[email-masked]
>http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director,   Entegrity Solutions
office: + 46 8 477 77 37,   cell: + 46 70 495 09 03,    fax: + 46 8 477 77
31

___________________________________________________________________________
This email is confidential and intended solely for the use of the 
individual to whom it is addressed. Any views or opinions presented are 
solely those of the author and do not necessarily represent those of 
Sema. 
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or 
copying of this email is strictly prohibited.

If you have received this email in error please notify the Sema UK
Helpdesk by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 9 Jun 2001 04:42:29 (NZST)

>Does anyone know what implementations of CMP exist?

Various companies have prototypes/test code (I'll let them speak up if they
want to admit to it :-), I'll be releasing an open source implementation in a
few days.

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 8 Jun 2001 16:50:25 -0400

I agree with Russ.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, June 08, 2001 4:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Online Certificate Revocation Protocol

Peter:

You make an interesting point.  I figure that a message signed with the 
private key that is claiming to be compromised is a good thing to pay 
attention to.

If the message is from the subscriber, then that subscriber probably knows 
that some bad thing just happened and the subscriber is trying to let 
everyone know.  He does not want any one to rely on the key any more.

If the message is not from the subscriber, then the key has absolutely been 
compromised.  What a nice attacker to tell everyone.

Russ

At 04:34 AM 6/9/2001 +0000, Peter Gutmann wrote:
>Nada Kapidzic Cicovic <[email-masked]> writes:
>
> >This is exactly what CMP specifies. Many vendors already have support 
> for CMP
> >EE initiated certificate revocation. The interoperability of different
>However there are two ways to look at revocation, the DOS model and the
scram
>switch model.  The DOS model says that anyone who can revoke your cert can
>cause a DOS, so it should be made as difficult as humanly possible to
revoke a
>cert.  The scram switch model says that when your private key is
compromised
>you want the cert revoked right now with no excuses, so it should be made
as
>easy as possible to revoke a cert.  CMP follows the DOS model and makes it 
>very
>difficult (in some cases impossible) to revoke your cert.  Programs like
PGP
>follow the scram switch model (via suicide-note revocations) and make it
very
>easy to revoke your cert.  Depending on your point of view, CMP may not be
the
>right thing for handling revocations.
>
>Peter.

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 08 Jun 2001 14:33:10 -0700

Oops.  Correction below.

At 04:47 PM 6/8/01 -0400, Housley, Russ wrote:
>If the message is not from the subscriber, then the key has absolutely 
>been compromised.  What a nice attacker to tell everyone.
>
>Russ

Indeed.  I have often considered that a revocation request signed with the 
corresponding private key is one of the few things in this world one can 
act upon reliably.  If we could build whole systems on such principles, 
we'd be home free.

A question:  If one discovers that they have accidently destroyed their 
private key (and there is no evidence of compromise), are they under any 
particular obligation to request revocation?  Is there any liability, or 
other real "downside" to simply getting a new key and keeping mum about the 
fate of the former key?

(I ask, because this seems the only [USER GENERATED] case where revocation 
request could NOT be signed by the key in question.)

___tony___

>>However there are two ways to look at revocation, the DOS model and the scram
>>cert.  The scram switch model says that when your private key is compromised
>>you want the cert revoked right now with no excuses, so it should be made as
>>easy as possible to revoke a cert.  CMP follows the DOS model and makes 
>>it very
>>difficult (in some cases impossible) to revoke your cert.  Programs like PGP
>>follow the scram switch model (via suicide-note revocations) and make it very
>>easy to revoke your cert.  Depending on your point of view, CMP may not 
>>be the

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900