RE: Online Certificate Revocation Protocol

[Luis Azevedo <LCarlos@xxxxxxxxxxxxx>]

Massimiliano wrote:

>I've posted some days ago the idea of having a definition of a revocation
>protocol to be adopted by clients when asking for revocation. Some have
>objected there are some reference to rfcs covering the revRequests,
however,
>to me, a different structure (and a protocol definition -- I have not
>found anywhere a revocation protocol, is there any ? Where, if any, can
>I find it ?) could be more appropriate.


What's wrong with the CMP Revocation Request / Revocation Response messages?
You can find them on "draft-ietf-pkix-rfc2510bis-04.txt".
Why to define a new separate protocol when you have all this mechanism
embeded on CMP?

Luis Azevedo.




-----Original Message-----
From: Massimiliano Pala [mailto:madwolf@xxxxxxxxxxxxxxx]
Sent: sábado, 9 de Junho de 2001 10:03
To: ietf-pkix@xxxxxxx
Subject: Online Certificate Revocation Protocol


Hi all,

I've posted some days ago the idea of having a definition of a revocation
protocol to be adopted by clients when asking for revocation. Some have
objected there are some reference to rfcs covering the revRequests, however,
to me, a different structure (and a protocol definition -- I have not
found anywhere a revocation protocol, is there any ? Where, if any, can
I find it ?) could be more appropriate.

To have an example of what I am talking of I post a proposed revRequest
structure ( am I not an ace on ASN.1 so there are probably errors... ).

Let me know your comments and suggestions.


Proposed Request Syntax
=======================

   OCRPRequest     ::=     SEQUENCE {
       Version             [0]     EXPICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName,
       producedAt          [2]     EXPLICIT Time,
       validUntil          [3]     EXPLICIT Time,
       requestList                 SEQUENCE OF Request,  
       optionalSignature   [2]     EXPLICIT Signature OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate
   OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       hashAlgorithm               AlgorithmIdentifier,
       reqCert                     CertID,
       revCode                     Crin,
       reason                      CRLReason,
       comment                     UTF8string OPTIONAL,
       RequestExtensions   [0]     EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       serialNumber        CertificateSerialNumber,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       revCodeHash         OCTET STRING, -- Hash of Revocation Secret Code
                                            and of the serialNumber (Crin) }
 
   Crin            ::=     SEQUENCE {
       serialNumber        CertificateSerialNumber,
       certificateCrin     OCTET STRING  -- Certificate's Revocation
                                            Secret Code }

Hash Explanations
=================
       
   serialNumber is the serial number of the certificate for which status
   is being requested. issuerNameHash is the hash of the Issuer's
   distinguished name. The hash shall be calculated over the DER encoding
   of the issuer's name field in the certificate being checked.
   issuerKeyHash is the hash of the Issuer's public key. The hash shall
   be calculated over the value (excluding tag and length) of the subject
   public key field in the issuer's certificate. revCodeHash is the hash
   of the certificate's Crin. The hash shall be calculated over the DER
   encoding of the Crin. The hash algorithm used for both these hashes,
   is identified in hashAlgorithm.

   The importance of having the revCodeHash to be calculated over the
   Crin is to have a POP of the certificate without having to sign the
   request -- this is left OPTIONAL and depends on the CA's adopted
   Policy.
   
-- 

C'you,

	Massimiliano Pala

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