Re: Online Certificate Revocation Protocol

jim <jimhei@cablespeed.com> Wed, 13 June 2001 13:58 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 JAA23266 for <pkix-archive@odin.ietf.org>; Wed, 13 Jun 2001 09:58:02 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DDIYH18220 for ietf-pkix-bks; Wed, 13 Jun 2001 06:18:34 -0700 (PDT)
Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DDIXJ18216 for <ietf-pkix@imc.org>; Wed, 13 Jun 2001 06:18:33 -0700 (PDT)
Received: from cablespeed.com (c216-45-71-147.md1.cablespeed.com [216.45.71.147]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id GAA31319; Wed, 13 Jun 2001 06:17:54 -0700
Message-ID: <3B276973.DAF9DB29@cablespeed.com>
Date: Wed, 13 Jun 2001 09:24:03 -0400
From: jim <jimhei@cablespeed.com>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Lynn.Wheeler@firstdata.com
CC: Carlin Covey <ccovey@cylink.com>, ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol
References: <OFE4D83FC6.3DA0F841-ON88256A69.000A0804@fdcsg.1dc.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

This is especially true if the secure audit trail contains the information that
the user was authenticated at the beginning of the session and that the
authentication was successful, the certificate was within its validity period
and that it was not revoked.
Jim

Lynn.Wheeler@firstdata.com wrote:

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