RE: Online Certificate Revocation Protocol

"Scherling, Mark" <mscherling@rsasecurity.com> Tue, 12 June 2001 16:15 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18470 for <pkix-archive@odin.ietf.org>; Tue, 12 Jun 2001 12:15:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CFICm29705 for ietf-pkix-bks; Tue, 12 Jun 2001 08:18:12 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CFIBJ29699 for <ietf-pkix@imc.org>; Tue, 12 Jun 2001 08:18:11 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f5CFI5i07957; Tue, 12 Jun 2001 08:18:05 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f5CFI5U17782; Tue, 12 Jun 2001 08:18:05 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <L2KC51ZJ>; Tue, 12 Jun 2001 08:18:38 -0700
Message-ID: <016D1D1E0314D5118A7F00508BD9525272DC2B@exvan01.x509.com>
From: "Scherling, Mark" <mscherling@rsasecurity.com>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>, Carlin Covey <ccovey@cylink.com>
Cc: ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol
Date: Tue, 12 Jun 2001 08:18:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

If there is a notary in the context of the transaction then the notary would
be liable for the transaction if the certificate and private key that signed
the document originally was proven to be invalid (i.e. key was assumed
destroyed but copy made and copy signed document).  I think that we can
argue that there was no intent by the owner of the key to sign the document,
however their digital signature is attached to the document signed by the
notary, who did not know that the key was destroyed (no record of key
revocation, certificate is valid, so notary signs).

I really like the idea of a notary function but you still need to revoke the
key if it was destroyed.  A key that was destroyed is in an unknown state
(was the key really destroyed and are there no duplicates?).  So the CA must
revoke the key to place it in a known state.  The public key can still be
used to verify transaction prior to the revocation.  However anything after
revocation should be rejected.  I feel that the security risks associated
with leaving a key in an unknown state are far greater than the problems
associated with revoking a key.  


-----Original Message-----
From: Lynn.Wheeler@firstdata.com [mailto:Lynn.Wheeler@firstdata.com]
Sent: Monday, June 11, 2001 7:04 PM
To: Carlin Covey
Cc: ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol





.... as per aside ... having somebody sign a document ... and then a
notary validate the signature with the public key, and then the notary
signs a composite document ... consisting of the originally signed
document, the signer's public key, and the current time ... and then log it
to a secure audit trail ..... could be done completely w/o the original
signer's certificate .... since in effect, the notary can perform at least
all the feature/function of a RA & CA as part of their function (in effect
the composite document that the notary signs .... is a kind of
certificate).

It isn't absolutely necessary to know any validity period (from a
certificate) of the original signer's public/private key .... it is just
necessary that the notary validates the information as correct at the time
it was signed/validated (and/or can be later shown to be valid at the time
of the signing).

.... have you noticed that the postings to the mailing list seems to have
some sort of lag? I've yet to see my original reply to you made at 3:59
(MDT) ... 3 hrs later (presumably you answered the copy of the reply sent
directly).






"Carlin Covey" <ccovey@cylink.com> on 06/11/2001 04:42:12 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   <ietf-pkix@imc.org>
Subject:  RE: Online Certificate Revocation Protocol


Lynn,

I quite agree that notarizing, with or without secure time, is a more
comprehensive solution.  I simply proposed one-time signature keys as an
example of a situation in which the certificate is expressly intended to be
valid after the private key has been destroyed.  Now whether anyone would
want to use one-time signature keys is another matter ....

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Lynn.Wheeler@firstdata.com [mailto:Lynn.Wheeler@firstdata.com]
Sent: Monday, June 11, 2001 3:59 PM
To: Carlin Covey
Cc: Bob Jueneman; ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol




in many cases, notary can include the idea of (secure) time .... i.e. that
not only can you proove who signed it ... but also when it was signed.

in principle, private keys (whether compromised or not) should not be able
to "pre-date" such a notorized, secure "time" signing.

typical solution is either a secure audit trail .... and/or to encapsulate
the signing inside some other transaction/document which includes a secure
time which is then signed by the notary function. The notary function
(wether audit trail or encapsulated function) can also include the business
function of validating/prooving the original signature (aka the notary
attests to the validity of a specific signature at a specific time).

while a one-time key with non-expiring certificate could meet a subset of
the business requirement .... it is not clear how many business processes
would need just the subset w/o needing the rest of the capability (aka, a
secure audit that establishes the validity of a signature executed at a
specific time would subsume the need for a one-time signature key and also
meet additional normal, day-to-day business requirements .... aka not only
is there the issue of what order a sequence of signatures might have taken
place .... but also what order did signatures take place within the context
of real-world events and sequences ... i.e. time).

If you are going to go to all the trouble of a notary ... dump the stuff
with the one-time private key .... and meet the rest of the business
requirements which includes did the signature verify and at what time did
the signature verify.






"Carlin Covey" <ccovey@cylink.com>@mail.imc.org on 06/11/2001 10:00:12 AM

Sent by:  owner-ietf-pkix@mail.imc.org


To:   "Bob Jueneman" <bjueneman@novell.com>
cc:   <ietf-pkix@imc.org>
Subject:  RE: Online Certificate Revocation Protocol



[Bob Jueneman]:

Indeed, although some have deprecated the concept of a private key validity
period, it makes a great deal of sense to DELIBERATELY destroy a given
signature key, especially a code or certificate signing key, well before
the
corresponding certificate expires.  From the point of view of the
certificate subscriber, this minimizes his risk by making certain that the
key can NOT be compromised, yet the certificate has not expired or been
revoked, so the certificate will continue to validate properly.

[Carlin Covey]:

I agree with Bob.  It might even be desirable to use "one-time" signature
keys for signing particularly important documents, such as major contracts,
wills, etc.   There might even be a "super non-repudiation" policy
associated with the guaranteed destruction of the signature private key.
This might be implemented via some trusted hardware token that generates
the
keypair, signs the document, destroys the private key, and signs a
notification of private key destruction.  Another possibility is some sort
of trusted "key-destruction notary" service that notarizes the document,
and
then destroys the certified one-time signature key as a matter of policy.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation