RE: Online Certificate Revocation Protocol
"Carlin Covey" <ccovey@cylink.com> Tue, 12 June 2001 22:42 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 SAA26256 for <pkix-archive@odin.ietf.org>; Tue, 12 Jun 2001 18:42:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CLpps17780 for ietf-pkix-bks; Tue, 12 Jun 2001 14:51:51 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CLppJ17775 for <ietf-pkix@imc.org>; Tue, 12 Jun 2001 14:51:51 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M4H20TYB; Tue, 12 Jun 2001 14:51:20 -0700
From: Carlin Covey <ccovey@cylink.com>
To: "Scherling, Mark" <mscherling@rsasecurity.com>
Cc: ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol
Date: Tue, 12 Jun 2001 14:52:02 -0700
Message-ID: <KHEDLMGGCCGHDAAKNAFOMEKFCAAA.ccovey@cylink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <016D1D1E0314D5118A7F00508BD9525272DC38@exvan01.x509.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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
Mark, as I understand it, when a Relying Party encounters a revoked or expired signature certificate, the RP is supposed to reject the signature as invalid. There has been discussion on this list and elsewhere of historical verification of signatures, i.e. "was this signature valid at a certain time in the past?" This is straightforward if the signature certificate is still valid. But if the certificate was revoked, particularly for reason of key compromise, then historical verification of an associated signature becomes troublesome. It is also troublesome to verify a signature after the certificate has expired. I believe that the expiration of a certificate relieves the issuing CA of the responsibility to maintain revocation status for the certificate. Of course a Relying Party can continue to use the public key in the expired certificate, whether for encryption or signature verification, if the RP is willing to accept the risk that the private key has not been compromised after the certificate expired. Basically the public key is no longer certified, so the previous obligations of the CA and subject of the certificate no longer obtain. If the signature must be validated after the certificate has expired or been revoked, the signed document should be timestamped while the signature is still valid (certificate not expired or revoked) by a timestamping authority whose certificate is still valid. Eventually the authority's signature will expire, and before that happens the the timestamped document should be encapsulated in another layer of timestamping. As an alternative to repeatedly encapsulating the signed document in additional layers of timestamping, the original timestamp authority could hold a "private key destruction ceremony" in an attempt to demonstrate that its retired key will never be compromised. Another alternative might be for the timestamping authority to assume the responsibility for reporting compromises of the expired private key. If the expired private key were ever compromised, it could sign a "my private key was compromised" notice either with the expired private key, or with a private key associated with a non-expired certificate with the same subject DN as the expired certificate. Regards, Carlin ____________________________ - Carlin Covey Cylink Corporation -----Original Message----- From: Scherling, Mark [mailto:mscherling@rsasecurity.com] Sent: Tuesday, June 12, 2001 10:41 AM To: 'Bob Jueneman'; Scherling, Mark; 'Carlin Covey' Cc: ietf-pkix@imc.org Subject: RE: Online Certificate Revocation Protocol My understanding is that if you revoke a certificate or key that the key is no longer valid for signing and the user cannot use the key or certificate to gain access. It does not mean that anything prior to that point is invalid. What happens when the certificate or key expires? Does that mean that all documents and transactions signed before are invalid? No you can still validate the signature. And what happens 10 years from now, the public key is still valid for that time. It should be available (either through archive or on-line) to check to determine if the status was valid. If I remember correctly the CRL merely indicates that the certificate was revoked on a specific date. Now getting into an area I'm not that familiar with, path validation checks to see if the certificates are valid. If a certificate is invalid, it fails. This only applies to current transactions. I don't think we have considered past or expired keys. It's somewhat analogous to doing a search on a deed title or any record retrieval. There has to be somewhere where a record of the transaction and the signatures attached. In the case of a paper document the signatures are with the document, in an electronic document, where are the signatures, with the document. How do you verify them? In paper, you have to compare with other samples. If you don't have samples, then you have a problem. How do you prove that that is the person's signature and there was intent by that person to sign. In the case of most legal documents, you have a witness signature, usually a public notary or a person representing an entity involved in the transaction. So we get back to Lynn's notary and how they could be of value in proving the signature. There are no right answers, each organization will determine the risks and create a process based on perceived risks. The financial community will demand far greater security measures than most other organizations, but I think in the end we will require some sort of notary function on higher value or risky transactions. -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Tuesday, June 12, 2001 10:12 AM To: mscherling@rsasecurity.com Cc: ietf-pkix@imc.org Subject: RE: Online Certificate Revocation Protocol Mark, I still disagree. If a key was deliberately destroyed, then it is in a considerably less unknown state than it was before. After all, the question of unknown duplicates, or even known duplicates (escrow) also applies while the key is in active use, as well. If the user was sloppy about the destruction, then maybe he was sloppy about its protection before the fact, as well, and that is something no notary is going to be able to help with. But I think there may be a more fundamental disconnect. My point is that few, if any, people are likely to go to all of the trouble to time stamp and notarize messages that are received, just so they can prove at some point after the certificate has expired (or been revoked) that it was valid at the time the document was signed or the signature was first verified. Unfortunately, having spent the last 15 or so years of my career in this field, I see a very disappointing amount of uptake for PKI other than for immediate access control decisions (including SSL certificates). And despite a number of brave, (and perhaps increasingly desperate) vendors of time stamping/notarization systems, I see little indication of any significant deployment of such systems. Even if PKI is eventually used and accepted by businesses (and I certainly hope it will be), most transactions are over and done with at the time they are first received. Even those that aren't concluded immediately, such as back-ordered merchandise, are accepted and held in abeyance. And the number of times that the signature validity of such a transaction would be questioned is virtually nil. Business simply don't operate on the fictional "let's do business with complete strangers" model. Instead, virtually every business, of whatever type, operates on a cyclical, monthly statement type of basis, and on the basis of trust between the partners -- a trust which goes far beyond the simple question of identity. While I don't disagree that it might be nice to have all of the powerful timestamping, etc., mechanisms, available in case they just might be needed, I would argue that they are far from necessarily in the vast majority of cases -- maybe 999,999 out of a million. And the cost and complexity of establishing such mechanisms may not be worth it. We simply aren't using (nor very likely to use) PKI for the type of enduring transactions between strangers (wills, deeds of trust, etc.) that gives rise to the necessity of nonrepudiation measures. Even in those cases where documents are examined long after they were written, a legal challenge to the signature is exceptionally rare. The rest of the time, and this was the essence of my previous comment, it is sufficient to validate the signature at the time it was received, or shortly thereafter. If any question arises and the certificate hasn't expired, then the relying party can revalidate the certificate at that time and will still receive a valid answer. Perhaps I should state my assumption explicitly: The probability that a given certificate will need to be reverified declines very sharply with time after the initial verification, at least for most relevant business transactions (not including wills and trusts, obviously). Time stamping is therefore only required if one believes that the transaction will have significant probative value at some uncertain time in the future, after the certificate has expired. (True notarization, as opposed to a mere time stamped validity check, is probably even less necessary. An exception might be for those transactions (typically involving unsophisticated consumers) where it is necessary to impress them with the ceremonial importance of their acts and to act as a true witness for their mental competency, absence of coercion, etc. as well as justifying the high fees typically involved in such a routine transaction. Buying or selling a house and taking on a mortgage is about the only such transaction that people do very often that might benefit from true notarization, and even then it is quite questionable. After all, if you move out of your house and let someone else move in, it is pretty obvious that you approved of the transaction. And if you don't pay the mortgage, the bank will foreclose, regardless of the signature or lack thereof.) If you assume, as I suggested, that private keys and certificates are taken out of service well before the end of their validity period and new ones created, i.e., for most transactions the certificate expiration date will be a year or more in the future, then this is a safe and reasonable assumption and timestamping is probably not required. And this is true regardless of whether the private key was destroyed or not. Some correspondents have suggested that providing anything less than the absolute ultimate in security will prevent PKI from ever getting off the ground. While I would hesitate to predict whether or not PKI will ever succeed, the fundamental problem would seem to be due to spending too much time and effort to mitigate risks that weren't terribly large to begin with, or didn't fit a reasonable business model. And even then, classical PKI only provides information about an entity's identity. And identity, while certainly useful for auditing terms, is neither absolutely necessary nor sufficient for the ultimate purpose, which is to decide exactly what that entity is trusted to do, or why the entity should be trusted at all. Granted, given someone's identity I can look up their privileges in my locally maintained directory,.but in that case why do I need a certificate at all, especially if the keys are ultimately going to be protected with a password in any case. Too much mechanism to mitigate too little risk, and this 10 years after the first PKI standard was first written. Too little, and much too late, I am increasingly afraid. Bob >>> "Scherling, Mark" <mscherling@rsasecurity.com> 06/12/01 09:18AM >>> 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
- RE: Online Certificate Revocation Protocol JANES, Mark
- Online Certificate Revocation Protocol Massimiliano Pala
- Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Hansen Wang
- RE: Online Certificate Revocation Protocol Carlin Covey
- RE: Online Certificate Revocation Protocol Peter Williams
- RE: Online Certificate Revocation Protocol Frank Balluffi
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Nada Kapidzic Cicovic
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Peter Gutmann
- RE: Online Certificate Revocation Protocol Peter Gutmann
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Housley, Russ
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Andrew W. Gray
- Re: Online Certificate Revocation Protocol Paul Hoffman / IMC
- Re: Online Certificate Revocation Protocol Hansen Wang
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Marc Branchaud
- RE: Online Certificate Revocation Protocol Paul Gogarty
- Re: Online Certificate Revocation Protocol jim
- Re: Online Certificate Revocation Protocol Hansen Wang
- Online Certificate Revocation Protocol Mr Jonathan W Jenkyn
- Re: Online Certificate Revocation Protocol Hansen Wang
- Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Online Certificate Revocation Protocol Massimiliano Pala
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Paul Hoffman / IMC
- Re: Online Certificate Revocation Protocol jim
- Re: Online Certificate Revocation Protocol Peter Gutmann
- Re: Online Certificate Revocation Protocol Peter Gutmann
- Re: Online Certificate Revocation Protocol Peter Gutmann
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol Bob Jueneman
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Carlin Covey
- Re: Online Certificate Revocation Protocol Marc Branchaud
- RE: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Marc Branchaud
- Re: Online Certificate Revocation Protocol Marc Branchaud
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- RE: Online Certificate Revocation Protocol Lynn.Wheeler
- Re: Online Certificate Revocation Protocol Marc Branchaud
- RE: Online Certificate Revocation Protocol Carlin Covey
- RE: Online Certificate Revocation Protocol Lynn.Wheeler
- RE: Online Certificate Revocation Protocol Paul Gogarty
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Carlin Covey
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Bob Jueneman
- RE: Online Certificate Revocation Protocol Scherling, Mark
- Re: Online Certificate Revocation Protocol Terry Hayes
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Carlin Covey
- Re: Online Certificate Revocation Protocol Peter Gutmann
- RE: Online Certificate Revocation Protocol Lynn.Wheeler
- Re: Online Certificate Revocation Protocol Massimiliano Pala
- Re: Online Certificate Revocation Protocol jim
- Re: Online Certificate Revocation Protocol jim
- Re: Online Certificate Revocation Protocol Lynn.Wheeler
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Hal Lockhart
- Re: Online Certificate Revocation Protocol Peter Gutmann
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol jim
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Liaquat Khan
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- Re: Online Certificate Revocation Protocol Tony Bartoletti
- RE: Online Certificate Revocation Protocol Scherling, Mark
- RE: Online Certificate Revocation Protocol Santosh Chokhani
- RE: Online Certificate Revocation Protocol Tony Bartoletti
- Re: Online Certificate Revocation Protocol jim
- RE: Online Certificate Revocation Protocol Luis Azevedo
- Re: Online Certificate Revocation Protocol Denis Pinkas
- Re: Online Certificate Revocation Protocol Peter Gutmann
- RE: Online Certificate Revocation Protocol Liaquat Khan
- Re: Online Certificate Revocation Protocol Denis Pinkas
- Re: Online Certificate Revocation Protocol Denis Pinkas
- Re: Online Certificate Revocation Protocol Nick Pope