Subject: Online Certificate Revocation Protocol

From: Massimiliano Pala <[email-masked]>
Date: Sat, 09 Jun 2001 11:36:46 +0200

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]                [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: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 9 Jun 2001 12:52:22 -0700

At 5:57 PM -0700 6/8/01, Hansen Wang wrote:
>But out-of-band could also mean going to the CA's web page and filling
>out a form such as typing in the some passwords/passphrase, presenting
>some electronic credentials or mother's maiden name (bad example) to
>request for the revocation. This would not involve staffing and would be
>nearly as quick as sending the revocation message through "in-band"
>means.

Exactly. But it is up to each CA, and we can't determine what they 
should do here.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 10 Jun 2001 23:52:31 (NZST)

Paul Hoffman / IMC <[email-masked]> writes:

>The latter is probably much more likely. Given that private keys are often 
>(usually?) protected with crackable passwords, the loss of a computer to an 
>attacker can be pretty disastrous. I assume that many CAs have out-of-band 
>revocation mechanisms for this case, but they certainly would take a long 
>time, and are probably difficult for a typical end user to find out about.
 
When I brought this up on the CMP list a while back, the response 
(tongue-in-cheek) was that users are expected to fly to the CA's place of 
business and beg in person to have their cert revoked.  This didn't strike me
as a very workable revocation mechanism.
 
(In case it isn't obvious anyway, I'm firmly in the scram-switch camp).
 
Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 10 Jun 2001 08:04:31 -0400

If a person was in possession of a private key and the organization can no
longer trust to have destroyed  the key is a different scenario, in my mind,
That is not a scenario of key being destroyed, but the scenario of
subscriber affiliation change.
 
In those cases, given stuff like DPA, even if the token is returned, in
sensitive domains, the policy could (should) call for revocation.

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Saturday, June 09, 2001 9:01 PM
Cc: [email-masked]
Subject: Re: Online Certificate Revocation Protocol

True, a destruction event does not mean that a key has been compromised, but
on the other hand, it does not mean that a compromise did not occur.  Thus,
there is still need to close the loop. 
Jim 

Santosh Chokhani wrote: 

     In all this, I do not see a security reason for key revocation.  If and
when a key is known or suspected of compromise, one should (must) revoke
it.A destruction event does not mean key has been compromised. 

-----Original Message----- 
From: jim [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, June 08, 2001 8:33 PM 
To: Santosh Chokhani 
Cc: Tony Bartoletti; Housley, Russ; [email-masked];
[email-masked] 
Subject: Re: Online Certificate Revocation Protocol 
 
I usually try to keep a low profile, but cannot help but get involved.
There is absolutely a need for revoking keys, even if they were destroyed.
If I were conducting a high-risk operation (large sales, financial
responsibilites, life responsibilities in the medical community, national
defense, etc.), I would not trust any system where keys were not revoked
just because someone reported them destroyed.  The associated key could
certainly be reproduced for later usage if someone were able to figure out
what was being used, and without revocation, there would be no way to ensure
that they usage of the key did not continue after the reported destruction.
When a key is no longer to be used other than at the end of its validity
period, it must be place on a CRL to end usage of it altogether. 

I have stated it pretty strongly, but I feel that way about it.  The problem
then becomes one of determining the risk mitigation with lost keys and
ensuring that the mitigation is as stringent as possible to ensure less
risk.  It is a matter of trust if the CP and CPS do not call for revocation
and will certainly disqualify the users of such keys from access to areas
where their certification is not considered suitable.  If the ability to put
trust into a certificate that is then used to authenticate a user so that
user can access information or workflow that they would not otherwise be
able to access, then the business decision behind using that form of trust
must make the risk mitigation decision to reduce the amount of trust that
can be divested into a certificate from a system that does not revoke it
because it is reported by the user to be destroyed.  For a system to be
validated, registration and certificate issuance have to be upheld by having
practices as strong for certificate revocation.  Otherwise, why have a PKI
to begin with? 
Jim Heimberg, ABC, Ph.D. 

Santosh Chokhani wrote: 

Destroying a private key used to generate signature may cause some
operational grief in terms of getting a new key certified, but there is no
need for that key any more and hence no revocation is needed. 

Destroying a private decryption key also does not require any revocation,
but underscores the need for key recovery.  Absent key recovery, data
encrypted with the public key companion to the lost private key, can not be
decrypted. 

-----Original Message----- 
From: Tony Bartoletti [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, June 08, 2001 5:31 PM 
To: Housley, Russ; [email-masked] 
Cc: [email-masked] 
Subject: Re: Online Certificate Revocation Protocol 

At 04:47 PM 6/8/01 -0400, Housley, Russ wrote: 
>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 

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 case where a revocation request could 
NOT be signed by the key in question.) 

___tony___ 

>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 
>> >implementations of CMP certificate revocation (among other things) has
been 
>> >conducted during PKI Forum and ICSA CMP interop testing quite
successfully. 
>> 
>>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. 

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

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 11 Jun 2001 12:19:49 -0400

Again, it is trust issue.  I have a very simple point.  If you trust the
holder of private key, you do NOT revoke a certificate.  If you do not trust
the holder of private key, you probably want to do something whether the key
was destroyed or not.

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Monday, June 11, 2001 12:28 PM
To: 'Santosh Chokhani'; jim
Cc: Tony Bartoletti; Housley, Russ; [email-masked];
[email-masked]
Subject: RE: Online Certificate Revocation Protocol

I see a big security reason to revoke the private key of an entity.  What is
the proof that the key was destroyed?  If it is a private key on a floppy or
disk or token, prove that no-one had access to the key and or the user did
not make a back up copy.  In the event that the key was destroyed and the
key was not revoked, then it would also not show up on the CRL or OCSP.
Would this not lead to other difficulties such as sending information using
an unknown key (encrypting or signing, would that be invalid or what
condition would the certificate indicate?).
 
If the private key of a CA was destroyed or claimed to be destroyed, I would
think that the CA should re-issue all certificates to be certain that there
is no possibility of compromise.  How else would you trust the CA and the
signing of CRLs and OCSP responses.  If the CA uses a new key to sign CRL's
and your application tests to validate that it came from the CA, it may
reject the new key as being invalid.  It is a matter of trust, however, as
Verisign/Microsoft case proves, keys can be compromised and we may not know
it until some later point in time.
 
I also think that if you determine that the key was compromised at some
later date and you put a claim that the key was compromised sometime between
the date of discovery and the date of destruction, the lawyers would have a
field day.  Anything signed between the date of destruction and date of
discovery/revocation could be refuted in court, you don't have a definitive
date and time.  
 
BTW, yes it is expensive and time consuming to re-issue all keys, however
the integrity of the PKI is at stake.  I'm just not sure the risks of not
revoking a destroyed key would be justifiable even for a CA key.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Saturday, June 09, 2001 6:27 AM
To: jim; Santosh Chokhani
Cc: Tony Bartoletti; Housley, Russ; [email-masked];
[email-masked]
Subject: RE: Online Certificate Revocation Protocol

    In all this, I do not see a security reason for key revocation.  If and
when a key is known or suspected of compromise, one should (must) revoke it.
 
A destruction event does not mean key has been compromised.

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Friday, June 08, 2001 8:33 PM
To: Santosh Chokhani
Cc: Tony Bartoletti; Housley, Russ; [email-masked];
[email-masked]

Santosh Chokhani wrote: 

-----Original Message----- 
From: Tony Bartoletti [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, June 08, 2001 5:31 PM 
To: Housley, Russ; [email-masked] 
Cc: [email-masked] 
Subject: Re: Online Certificate Revocation Protocol 

___tony___ 

been 
successfully. 
scram 

compromised 
as 
PGP 
very

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 11 Jun 2001 17:07:36 -0400

Marc:

I fail to see a security risk in a key that has been revoked.  Absent
trusted time stamp, all the unnecessary revocation does is cause denial of
service.

If the PKI always was implemented in conjunction with trusted time stamp,
standards fully address the issue of validation (e.g., X.509 and PKIX path
development) and the products incorporated all this, it might work.  Even
then, there is an issue of CRL size growth.

There is little benefit in revoking just in case type scenario.  That way, a
key that is not destroyed and is being used is more suseptible to
compromise.  So, if we just kept on rekeying and revoking old certificates,
it will be a pretty poor solution.

-----Original Message-----
From: Marc Branchaud [mailto:[email-masked]]
Sent: Monday, June 11, 2001 4:39 PM
To: [email-masked]
Subject: Re: Online Certificate Revocation Protocol

Two replies in one...
 
Santosh Chokhani wrote:
> 
> Revocation of a public key certificate whose companion key has been
> destroyed is a BAD idea.
>  
> For example, if the subject of the key is a CA, revocation of that
> public key certificate could cause denial of service for all the
> certificates issued by that CA.  There is nothing wrong with the
> certificates.

Just because the revocation mechanisms aren't up to the task is a poor
reason
to not take the precaution.

Santosh Chokhani wrote:
> 
> Again, it is trust issue.  I have a very simple point.  If you trust
> the holder of private key, you do NOT revoke a certificate.  If you
> do not trust the holder of private key, you probably want to do
> something whether the key was destroyed or not.

Trusting the holder is not enough.  The holder may consider the key
destroyed
because it's beyond his ability to recover, but that doesn't mean that it
can't be recovered by someone else.  Such recovery is less likely to be
noticed with an unused key.

The safe course is to revoke.  To do otherwise has security implications.

		Marc

---

From: "Scherling, Mark" <[email-masked]>
Date: Tue, 12 Jun 2001 08:18:37 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 7:04 PM
To: Carlin Covey
Cc: [email-masked]
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" <[email-masked]> on 06/11/2001 04:42:12 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   <[email-masked]>
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: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:59 PM
To: Carlin Covey
Cc: Bob Jueneman; [email-masked]
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" <[email-masked]>@mail.imc.org on 06/11/2001 10:00:12 AM

Sent by:  [email-masked]

To:   "Bob Jueneman" <[email-masked]>
cc:   <[email-masked]>
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

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 12 Jun 2001 11:12:27 -0600

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" <[email-masked]> 06/12/01 09:18AM >>>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 11, 2001 7:04 PM
To: Carlin Covey
Cc: [email-masked] 
Subject: RE: Online Certificate Revocation Protocol

... as per aside ... having somebody sign a document ... and then a

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

Lynn,

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 11, 2001 3:59 PM
To: Carlin Covey
Cc: Bob Jueneman; [email-masked] 
Subject: RE: Online Certificate Revocation Protocol

[Bob Jueneman]:

[Carlin Covey]:

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 12 Jun 2001 14:57:12 -0400

I agree with "thayes".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 2:50 PM
To: Scherling Mark
Cc: Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

Mark,

In this message you use the phrases "after I left the organization" and 
"someone leaves the company". This tells me that your affiliation has 
changed, and therefore any certificate you hold indicating that 
affiliation should be revoked.  This has nothing to do with whether the 
key has been destroyed.

Using the destruction of the key as a replacement for revocation is not 
a good idea for the reasons you give.  However, I see no requirement to 
revoke a certificate for a destroyed key if the subject is otherwise in 
good standing.

Terry

Scherling, Mark wrote:

>The problem is that today we have no way of determining what "hold" means.
>We can suspend a certificate which means it's not available, but my
>preference is to revoke a certificate if the private key is in an unknown
>state, that is we think it was destroyed but there is no way of determining
>if that is absolutely true.  
>
>If you look at a lot of the cyber-thefts, a large percentage was with
>insider knowledge.  It would be easy to say my key has been destroyed and
>then use my key for access to something after I left the organization.  You
>would have proof that the key was destroyed (I signed a piece of paper
>saying so, with date and time, witnessed by my VP, etc.) yet the key was
>used to gain access after the date and time.  It's not a matter of trust,
>but a matter of risk management.  If my key was unknowingly compromised and
>then destroyed, the key is still valid unless we revoke the key.  It is far
>safer than assuming that the key was destroyed.
>
>In the case of a CA key, I would rather revoke all keys and re-issue than
>take the risk that the CA key was destroyed and no other copies exist. 
>
>So we want to restrict the ability to use the key even if it has been
>destroyed because we cannot with absolution determine that the key was
>destroyed and no copies exist.  In many Subscriber Agreements and
>Certificate Policies, it states that the Subscriber may back up their keys
>using proper safeguards as long as they are the only ones with access.  In
>the event that someone leaves a company and their private key was destroyed
>prior to them leaving, the back up key may be in a sealed envelope with the
>passphrase at their desk or in their filing cabinet.  I know that most of
us
>would never do this sort of thing but many people do.   So now you are left
>with a key that has not been revoked and is still active.  Would we all not
>consider this a security risk?
>
>The bottom line is that if a private key is in an unknown state, the CA
>should revoke the key.
>
>From: Carlin Covey [mailto:[email-masked]]
>Sent: Tuesday, June 12, 2001 9:07 AM
>To: Paul Gogarty; [email-masked]; [email-masked]
>Cc: Ietf-Pkix
>Placing the certificate on hold and using some sort of hold instruction
code
>makes sense to me.  But the hold instruction code would have to refer to
>some date after which new signatures are considered invalid.  That
>presupposes a timestamp on the signed document, so there is a trusted
>signature time to compare with the the "no new signatures after ..." time
in
>the hold code.  Of course, we could use the private key usage extension to
>specify the time, if the CA, RA or subject of the signature certificate
>knows this time when the certificate is issued.  In an earlier posting Lynn
>Wheeler noted that in such a case the CA/RA functions might be combined
with
>the timestamping notary function.
>
>Mark, is this similar to what you had in mind when you mentioned revoking
>the private key?  That is, we want restrictions placed on validation of
>signatures made with the private key based upon when the signatures were
>created.
>
>Regards,
>
>Carlin
>
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Paul Gogarty
>Sent: Tuesday, June 12, 2001 8:11 AM
>To: Ietf-Pkix
>In cases where keys are destroyed before their revocation date would it not
>make more sense to place the certificate on hold (use a combination of
>'Reason Code' and 'Hold Instruction Code' CRL entry extensions).
>
>This allows the certificate to validate as part of a certification path or
>for signature verification, but provides a date after which signatures from
>the certificate should not be trusted and the encryption key should not be
>used.
>
>	Paul Gogarty
>	ASN.1 Developer
>
>	De La Rue InterClear Ltd.
>	De La Rue House
>	Jays Close
>	Viables
>	Basingstoke
>	England
>	RG22 4BS
>
>	Fax: +44 (0)1256 487755
>	Tel: +44 (0)7879 458416
>	mailto:[email-masked]
>
>	http://www.interclear.co.uk/
>

---

From: "Scherling, Mark" <[email-masked]>
Date: Tue, 12 Jun 2001 12:31:11 -0700

Sorry bad example in that leaving an organization should automatically
trigger a revocation of your certificate.  But, if you are an administrator
and you know that the key was destroyed and had other pressing things, you
may be tempted to forget despite the fact that it states that in your
policies and procedures.  Is it not true that human error is the cause in
most security breaches?
 
Then let me paint you another scenario, the VP gives his secretary (never
happens :-) her keys and access to her e-mail and accounts to handle routine
correspondence.  If the VP 's key is accidentally destroyed, is there
another copy?  Who has access to it?  If the VP stays and the secretary
leaves, is there a security risk?  I guess I'm just a little to paranoid.
 
Cheers

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:57 AM
To: [email-masked]; Scherling Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

I agree with "thayes". 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 2:50 PM 
To: Scherling Mark 
Cc: Ietf-Pkix 
Subject: Re: Online Certificate Revocation Protocol 

Mark, 

Terry 

us 

>From: Carlin Covey [ mailto:[email-masked] <mailto:[email-masked]> ] 
code 
in 

with 
>[ mailto:[email-masked] <mailto:[email-masked]>
]On Behalf Of Paul Gogarty 

>       mailto:[email-masked]
<mailto:[email-masked]>  
> 
>       http://www.interclear.co.uk/ <http://www.interclear.co.uk/>  
>

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 12 Jun 2001 15:56:29 -0400

Mark:
 
I think if the certificate issuing authority trusts that the subject key is
truly destroyed, I have not seen any cogent argument on this list yet for
revoking the certificate.  All I hear is:
 
1.  It is safe thing to do.
2.  Well we can use trusted time stamp or notary to get around the denial of
service
 
I see no particular reason for revocation in the case of a destroyed key.
Bob Juneman ha made the most cogent point that for private decryption key,
if there is no key recovery, you may want to revoke so that others do not
use the public key since the subject can not use the private key.
 
Rest of the discussion is NOT related to key being destroyed, but related to
not trusting the key being destroyed, not trusting the subject, or trying to
over-design the PKI.
 
I will give you one thing, it is always safe to revoke any key, if you do
not care about denial of service.

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 3:31 PM
To: 'Santosh Chokhani'; [email-masked]; Scherling, Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

 
Cheers

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:57 AM
To: [email-masked]; Scherling Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

I agree with "thayes". 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: "Scherling, Mark" <[email-masked]>
Date: Tue, 12 Jun 2001 13:30:23 -0700

Hi Santosh, I'm not sure why you would think that revoking a certificate
would result in a denial of service?  If your key has been destroyed and I
want to use your public key to send you a message, you cannot read it.  I
will assume you have received the message since there is no other indication
(CRL or OCSP response). Unless you tell me otherwise and then I may think
that you are denying receipt of my messages.   I'm assuming that we have an
agreement that the messages we are sending are confidential and sensitive
and require encryption and signing.  
 
I also don't understand why you would not want to revoke a key if it was
destroyed?  If I cannot use my key to sign or decrypt or gain access to a
service then what is the value of that key to me?
 
If a key is revoked, it is placed on a CRL until the key expires.  The key
can no longer be used for signing and as Bob pointed out others cannot use
the public key to encrypt messages to the key holder.
 
In my experience, most users forget their pass phrase (be it userid and
password or key and pass phrase).  If the user destroys their key at this
point, what is the purpose of keeping the key?  Why would you not revoke the
key?
 
Sorry to burden you but could you explain to me why you think revoking a
certificate is a denial of service?

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 12:56 PM
To: Scherling, Mark; Santosh Chokhani; [email-masked]
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

Mark:

 

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 3:31 PM
To: 'Santosh Chokhani'; [email-masked]; Scherling, Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

 
Cheers

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:57 AM
To: [email-masked]; Scherling Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

I agree with "thayes". 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 12 Jun 2001 16:37:06 -0400

Mark:
 
One more thing, revoking the public encryption key is also not a good idea
in all cases.  When key recovery (specifically key escrow) is employed that
provides the first party to recover their private decryption keys, there is
no need to revoke the certificate.
 
-----Original Message-----
From: Santosh Chokhani 
Sent: Tuesday, June 12, 2001 4:38 PM
To: 'Scherling, Mark'; Santosh Chokhani; [email-masked]
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

Please see responses in-line.

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 4:30 PM
To: 'Santosh Chokhani'; Scherling, Mark; [email-masked]
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

Hi Santosh, I'm not sure why you would think that revoking a certificate
would result in a denial of service?  If your key has been destroyed and I
want to use your public key to send you a message, you cannot read it.  I
will assume you have received the message since there is no other indication
(CRL or OCSP response). Unless you tell me otherwise and then I may think
that you are denying receipt of my messages.   I'm assuming that we have an
agreement that the messages we are sending are confidential and sensitive
and require encryption and signing. 
[Santosh Chokhani] If some thing has been signed and subsequently the
private key is destroyed, the public key can still be used to verify the
signature, if the key was not revoked.  I do not want to get into the time
stamp protocol since I want a PKI to function to some degree without
"trusted time stamp".  Now, imagine that an intermediate CA key is
destroyed.  There is no need to revoke the CA key and invalidate all the
certificates issued by the CA.  I realize that the CA can generate a new key
and re-issue all the certificates, but this work need not be done.  In
short, the denial of services comes from revoking a certificate that is
perfectly fine.
 
I also don't understand why you would not want to revoke a key if it was
destroyed?
[Santosh Chokhani] I do not understand what the need to revoke the
certificate is?
 
If I cannot use my key to sign or decrypt or gain access to a service then
what is the value of that key to me?
[Santosh Chokhani] You are right in the decryption scenario, but as stated
earlier not right in the signature scenario. 
 
If a key is revoked, it is placed on a CRL until the key expires.  The key
can no longer be used for signing
[Santosh Chokhani] But what about what was signed before, unless you
integrate trusted time stamp and revamp the X.509 and PKIX path validation
to account for time and trusted time, legitimate signatures will be
rejected.
 
  and as Bob pointed out others cannot use the public key to encrypt
messages to the key holder.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 12:56 PM
To: Scherling, Mark; Santosh Chokhani; [email-masked]
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

Mark:

 

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 3:31 PM
To: 'Santosh Chokhani'; [email-masked]; Scherling, Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

 
Cheers

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:57 AM
To: [email-masked]; Scherling Mark
Cc: Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

I agree with "thayes". 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: [email-masked]
Date: Wed, 13 Jun 2001 00:32:05 -0700

the notary can do what he does today ... certifies that the person
possesses some number of things (like some device for signing which can be
verified with a specific public key) and some number of other things ....
effectively a combination of the existing notary business practices along
with some things like a RA & CA  ....aka the notary is responsible for
whatever the notary standards require the notary to attest to ... if the
notary standard says that the standard is a driver's license, a passport, a
hardware token that requires a PIN, and actually perform a digital
signature ... then the notary can attest to that. If a different notary
standard requires the notary to validate a RA & CA process done by some
other entity (which checked a drivers license, a passport, and that a
specific digital signature could be verified) ... in the form of a valid
digital signature ... then the notary could attest to that.

The notary, in theory, could also do an online validation that a specific
public key was registered to a specific person (say a new kind of online
request sent to one of the existing credit bureaus) ... and that the entity
seemd to be the same (an online request instead of needing a certificate
designed for satisfying authentication requirements in an offline world)
.... it is whatever the notary is supposed to be notarizing.

Just because most existing (capital) PKIs happen to specify certificates
that were a paradigm solution to authentication opportunities in an offline
world ... doesn't necessarily mean that the process that a notary would use
in an online world need be the same

"Scherling, Mark" <[email-masked]> on 06/12/2001 08:18:37 AM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC, Carlin Covey <[email-masked]>
cc:   [email-masked]
Subject:  RE: Online Certificate Revocation Protocol

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 7:04 PM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: Online Certificate Revocation Protocol

Lynn,

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:59 PM
To: Carlin Covey
Cc: Bob Jueneman; [email-masked]
Subject: RE: Online Certificate Revocation Protocol

[Bob Jueneman]:

[Carlin Covey]:

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

---

From: [email-masked]
Date: Wed, 13 Jun 2001 14:26:14 +0200

Bob

You adress som interesting areas. One of them is if and when you need
notarization. In January 2001, Sweden passed a law about qualified digital
signatures, which basiclly states that a qualified digital signature is as
good as/ or better than a hand written signature.

We also have Busniess laws, which regulates how long you have to keep
buisness documents i.e. contracts. Now if our company gets into a legal
dispute after i.e. 15 yrs after a contract was signed, then it´s utterly
important to us that we can verify and validate, when a certifcate was
signed and valid. 

Real case scenario: 10 000 -15000 users (companies) will be able to
digitally sign their tax form and send to the National Tax Board ( swedish
IRS).

Therefore my opinion and conclusion is that:  It´s very important to support
and implement notarization by i.e time-stamping!

With best regards

Egil Mannerheim
Senior IS/IT Security professional

	-----Ursprungligt meddelande-----
	Från:	Bob Jueneman [SMTP:[email-masked]]
	Skickat:	den 12 juni 2001 19:12
	Till:	[email-masked]
	Kopia:	[email-masked]
	Ämne:	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.

	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" <[email-masked]> 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-----

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

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

	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" <[email-masked]>@mail.imc.org on 06/11/2001
10:00:12 AM

	[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

---

From: [email-masked]
Date: Wed, 13 Jun 2001 08:26:58 -0700

a certificate doesn't represent anything particularly magic ... pretty much
a credential target at being used in offline environments (when there
access to an online authority) ... and the thing the credential represents
is pretty much ... stuff that notaries do on a routine basis .... check
some sort of reference to authenticate some information. In fact, a big
part of the reason that a certificate has a validity period at all ... is
to limited the exposure of a certifying authority in an offline paradigm
environment where the certificate could be used in an unknown number of
unknown transactions. A notary doing the certification in real time and
online doesn't have that exposure because they typically know the number
and kinds of transactions they are certifying.

jim <[email-masked]> on 06/13/2001 06:24:03 AM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Carlin Covey <[email-masked]>, [email-masked]
Subject:  Re: Online Certificate Revocation Protocol

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

---

From: "Scherling, Mark" <[email-masked]>
Date: Wed, 13 Jun 2001 12:50:41 -0700

Are there standards for notaries?

Are they industry specific or general?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 7:04 PM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: Online Certificate Revocation Protocol

Lynn,

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:59 PM
To: Carlin Covey
Cc: Bob Jueneman; [email-masked]
Subject: RE: Online Certificate Revocation Protocol

[Bob Jueneman]:

[Carlin Covey]:

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

---

From: Hal Lockhart <[email-masked]>
Date: Wed, 13 Jun 2001 16:49:19 -0400

> Does this relate to why the "emergency CRL" published after the bogus 
> Microsoft code-signing certs were issued was not a "real CRL"?  I 
> understood that Microsoft supported one form of "CRL 
> mechanism" while they 
> routinely employed certificates incompatible with that 
> mechanism, and that 
> was the reason they cold not "just revoke" the (bad) 
> certificates that were 
> issued.

According to this:

http://amug.org/~glguerin/opinion/revocation.html

the problem is that Microsoft software will only find CRLs specified in the
CRL Distribution Point extension in the certificate. Verisign does not use
this method. Since the use of this field is optional and Versign has been
operating since before the field was even defined, it is debatable who is to
blame for this situation.

Apparently Micorsoft's "fix" was to hotwire a special CRL, containing just
these two certs into their products.

Hal

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 13 Jun 2001 21:47:26 -0400

Folks:

To me re-keying means issuing a new certificate to the same DN. 

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 2:07 PM
To: jim; Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

At 10:09 AM 6/13/01 -0400, jim wrote:
>I have to jump in again.  Mark is correct.  Remember that we are talking a 
>Certification Revocation List (CRL).  This is vastly different than a 
>Compromised Key List (CKL).  We place a certificate on the CRL because 
>there is a larger problem other than just the signing key.  If the token 
>set is damaged or destroyed (this is a good place to insert Bob's 
>reflection on bent keys), the cert needs to be added to the CRL.  If there 
>is some way to ensure that only a keyset is damaged, the cert can be 
>rekeyed so that service for the DN continues.  It specifically does come 
>back to the concern of knowing what is considered destroyed and what is 
>considered bent.  Since I have not seen the equivalent of a CKL in the 
>IETF world, I have to assume that the only way to truly cancel usage of a 
>key is either to put the cert on the CRL or to rekey the cert so that the 
>old key is no longer valid.  The question becomes how to demonstrate that 
>a key has been invalidated without invalidating the DN or cert.
>
>I think Santosh and I agree that the question is one of trust as to 
>whether the key is truly destroyed as opposed to being unusable to the 
>user, but the issuing authority still has the responsibility for making 
>that determination and if needed, revoking the cert to invalidate the 
>key.  There is a fine line between what happens technically and what needs 
>to happen procedurally.  Thus, I still side with Mark and the proponents 
>of transaction notarization (accomplishable through a retrievable audit 
>trail) as a better, more secure process.  I am not arguing about what 
>needs to happen as far as the technical capability of key management, but 
>from the risk mitigation standpoint, which is what business needs to deal 
>with.  They need to have an electronic system that is as inherently secure 
>as their paper system or PKI will never get off the ground.
>
>Jim

A (X.509) certificate is a CAs attestation of a given key->DN 
binding.  Thus, a new key *dictates* a new and different certificate.

This is the first time I've come across the terminology "the cert can be 
rekeyed".  This is a curious turn of phrase!  It sounds like "we changed 
the key, but don't fret, the *certificate* remains the same."

To my understanding, rather than "rekey a cert", you want to "recertify a
DN".

___tony___

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 14 Jun 2001 07:43:52 -0400

If you are saying that whether the CA believes the private key to be
destroyed, I agree.
 
If you are saying that even if the CA knows, the private key is destroyed
and still the public key certificate should be revoked, I disagree.
 
I can envision in some situations CA wanting to revoke the certificate even
if knows the key to be destroyed, but making that as a norm or
recommendation for IETF standard is absurd.

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 7:43 AM
To: Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

Comments in line... 

Santosh Chokhani wrote: 

 Jim:Please see comments in-line. 

-----Original Message----- 
From: jim [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 13, 2001 10:10 AM 
To: Santosh Chokhani 
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix 
Subject: Re: Online Certificate Revocation Protocol 
 
I have to jump in again.  Mark is correct.  Remember that we are talking a
Certification Revocation List (CRL).  This is vastly different than a
Compromised Key List (CKL).  We place a certificate on the CRL because there
is a larger problem other than just the signing key.  If the token set is
damaged or destroyed (this is a good place to insert Bob's reflection on
bent keys), the cert needs to be added to the CRL.  If there is some way to
ensure that only a keyset is damaged, the cert can be rekeyed so that
service for the DN continues.  It specifically does come back to the concern
of knowing what is considered destroyed and what is considered bent.  Since
I have not seen the equivalent of a CKL in the IETF world, I have to assume
that the only way to truly cancel usage of a key is either to put the cert
on the CRL or to rekey the cert so that the old key is no longer valid.  The
question becomes how to demonstrate that a key has been invalidated without
invalidating the DN or cert. 
[Santosh Chokhani] Why do you want to claim a destroyed key is invalid?

I do not want to claim that a destroyed key is invalid.  What I believe
needs to happen is recognition that the CA is the one to make the decision
as to whether the key is destroyed, not the user.  If, for instance, I am
using a system with a hard token, if the key is run over by a car and will
not be usable, there is still the remains of the key to be turned over to
the CA and the CA can make the decision.  If the key is a software token,
there is no such manner of determining that the key is truly destroyed by
the average PKI user.  As such, why allow a user to determine whether the
key is destroyed?  All I think needs to happen is recognize that this is a
CA decision and let the CA take the appropriate precautions in accordance
with the CP/CPS for the system. 

 As you know a subscriber or an authority will stop using a private key well
before the expiration of public key certificate used for signature
verification.  But, absent trusted time stamp, PKIX does NOT recommend use
of private key validity period.  So, just because key is not usable any
more, you should revoke it.  Besides if the subject is a CA and issued
numerous certificates, revoking CA's key will cause unneeded Denial of
Service.  BTW, even if you had trusted time stamp or notary, unless get
certificates notarized, revoking CA's public key certificate will either
cause denial of service or will not protect against a security breach.  Here
is the scenario.  If the you put the CA on the revoked list, all the
certificates issued have been invalidated for no reason.  If you apply the
logic that you will use "invalidity date" CRL: extension and match against
the certificate issuance time (let us say notBefore date), if the key was
truly in wrong hands, they will issue bogus certificates with pre-dated
notBefore date. 

I think Santosh and I agree that the question is one of trust as to whether
the key is truly destroyed as opposed to being unusable to the user, 
[Santosh Chokhani] I am not sure we agree.  I think certificate need not be
revoked if the key is destroyed.  Now if the CA stops trusting the holder of
the private key, that is a different matter.

Again, here is the decision point.  Does the CA make the trust decision?  I
think so, and if that is the case, the CA should be endowed with the final
decision as to whether the key is destroyed, not the user.  This takes us
back to Bob J.'s question about bent keys, which I totally agree with.
Again, it needs to be a CA decision in accordance with a CP/CPS. 

but the issuing authority still has the responsibility for making that
determination and if needed, revoking the cert to invalidate the key.  There
is a fine line between what happens technically and what needs to happen
procedurally.  Thus, I still side with Mark and the proponents of
transaction notarization (accomplishable through a retrievable audit trail)
as a better, more secure process. 
[Santosh Chokhani] I do not care buy that PKI is useless with trusted time
or notary service.

Useless no, but risk mitigation of possible court action is critical in
business depending on the value of the transaction and criticality of the
information being passed, so there is reason to have at a minimum an audit
trail that no only indicates the computer event that takes place, but also
what data or transfer of funds occurred with that transaction.  Whether this
is done by timestamping and notarization or with the persistent proof audit
log offered by Conclusive Logic, Inc., is a matter for each enterprise to
decide, but we as technologists need to let that be a business decision, not
try to make it for them by saying, "You don't need to do it, so we won't
include the capability." 

PKI systems need to be designed to support the enterprise business model and
the security managers at an enterprise define the CP/CPS for that system
with all of their security issues being invoked.  Thus, it makes sense for
the CA responsible for issuing authenticatable certificates to users to
cover the types of transactions the business wants to perform to be the
single decision maker in enforcing CP/CPS policy and procedures in the case
of determining whether a key is truly destroyed.  Most users do not have
that capability and the burden should not be put on them.  Those users who
do have that capability should be more capable of accurately reporting to
the CA that the key was truly destroyed.  Then the CA, working with the
Security Manager, can make the appropriate decision that implements the
policies and procedures that were designed for the system.  Obviation of the
security policies and procedures reduces the secure nature of the PKI, which
is why it was originally implemented.  If we reduce the secureness that is
offered by the PKI, we certainly reduce the PKI market. 

  I am not arguing about what needs to happen as far as the technical
capability of key management, but from the risk mitigation standpoint, which
is what business needs to deal with.  They need to have an electronic system
that is as inherently secure as their paper system or PKI will never get off
the ground. 

Jim 

Santosh Chokhani wrote: 

-----Original Message----- 
From: Scherling, Mark [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 4:30 PM 
To: 'Santosh Chokhani'; Scherling, Mark; [email-masked] 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol
Hi Santosh, I'm not sure why you would think that revoking a certificate
would result in a denial of service?  If your key has been destroyed and I
want to use your public key to send you a message, you cannot read it.  I
will assume you have received the message since there is no other indication
(CRL or OCSP response). Unless you tell me otherwise and then I may think
that you are denying receipt of my messages.   I'm assuming that we have an
agreement that the messages we are sending are confidential and sensitive
and require encryption and signing. 
[Santosh Chokhani] If some thing has been signed and subsequently the
private key is destroyed, the public key can still be used to verify the
signature, if the key was not revoked.  I do not want to get into the time
stamp protocol since I want a PKI to function to some degree without
"trusted time stamp".  Now, imagine that an intermediate CA key is
destroyed.  There is no need to revoke the CA key and invalidate all the
certificates issued by the CA.  I realize that the CA can generate a new key
and re-issue all the certificates, but this work need not be done.  In
short, the denial of services comes from revoking a certificate that is
perfectly fine.I also don't understand why you would not want to revoke a
key if it was destroyed? 
[Santosh Chokhani] I do not understand what the need to revoke the
certificate is?If I cannot use my key to sign or decrypt or gain access to a
service then what is the value of that key to me? 
[Santosh Chokhani] You are right in the decryption scenario, but as stated
earlier not right in the signature scenario. If a key is revoked, it is
placed on a CRL until the key expires.  The key can no longer be used for
signing 
[Santosh Chokhani] But what about what was signed before, unless you
integrate trusted time stamp and revamp the X.509 and PKIX path validation
to account for time and trusted time, legitimate signatures will be
rejected. and as Bob pointed out others cannot use the public key to encrypt
messages to the key holder.In my experience, most users forget their pass
phrase (be it userid and password or key and pass phrase).  If the user
destroys their key at this point, what is the purpose of keeping the key?
Why would you not revoke the key?Sorry to burden you but could you explain
to me why you think revoking a certificate is a denial of service? 
-----Original Message----- 
From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 12:56 PM 
To: Scherling, Mark; Santosh Chokhani; [email-masked] 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol 

Mark:I think if the certificate issuing authority trusts that the subject
key is truly destroyed, I have not seen any cogent argument on this list yet
for revoking the certificate.  All I hear is:1.  It is safe thing to do.2.
Well we can use trusted time stamp or notary to get around the denial of
serviceI see no particular reason for revocation in the case of a destroyed
key.  Bob Juneman ha made the most cogent point that for private decryption
key, if there is no key recovery, you may want to revoke so that others do
not use the public key since the subject can not use the private key.Rest of
the discussion is NOT related to key being destroyed, but related to not
trusting the key being destroyed, not trusting the subject, or trying to
over-design the PKI.I will give you one thing, it is always safe to revoke
any key, if you do not care about denial of service. 

-----Original Message----- 
From: Scherling, Mark [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 3:31 PM 
To: 'Santosh Chokhani'; [email-masked]; Scherling, Mark 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol
Sorry bad example in that leaving an organization should automatically
trigger a revocation of your certificate.  But, if you are an administrator
and you know that the key was destroyed and had other pressing things, you
may be tempted to forget despite the fact that it states that in your
policies and procedures.  Is it not true that human error is the cause in
most security breaches?Then let me paint you another scenario, the VP gives
his secretary (never happens :-) her keys and access to her e-mail and
accounts to handle routine correspondence.  If the VP 's key is accidentally
destroyed, is there another copy?  Who has access to it?  If the VP stays
and the secretary leaves, is there a security risk?  I guess I'm just a
little to paranoid.Cheers 

-----Original Message----- 
From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 12, 2001 11:57 AM 
To: [email-masked]; Scherling Mark 
Cc: Ietf-Pkix 
Subject: RE: Online Certificate Revocation Protocol
I agree with "thayes". 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: "Scherling, Mark" <[email-masked]>
Date: Thu, 14 Jun 2001 08:44:55 -0700

Without dragging this out longer, the choice is with the CA and what they
define in their policies and procedures (CP and CPS).  Technically a
destroyed key can be kept indefinitely.  From a business or security
perspective, it is the choice of the CA and the organization (the PKI
Management Authority would get a report or I hope that the CA would report
this and the PKI Management Authority would accept the risk of keeping the
destroyed key active otherwise they would request it be revoked).
 
Would you agree Santosh?

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 4:43 AM
To: Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

Comments in line... 

Santosh Chokhani wrote: 

-----Original Message----- 
From: jim [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 13, 2001 10:10 AM 
To: Santosh Chokhani 
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix 
Subject: Re: Online Certificate Revocation Protocol 

  

Jim 

Santosh Chokhani wrote: 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: "Scherling, Mark" <[email-masked]>
Date: Thu, 14 Jun 2001 08:54:45 -0700

What about mortgages?  How about property deeds?  How about long term bonds?
There is an increasing chance that these may be electronic and in the future
not a scanned copy.  I think that being able to validate a digital signature
in the future will become very important.  There are a lot of problems with
recovery of electronic information as we have witnessed in the information
management area.  Issues like technology obsolescence, recovery mechanisms,
audit and controls will become very important and in some cases require
maintaining vintage systems intact.  We have seen this with 8 inch disks,
mag tapes and other media already.  Does anyone remember Micom or AES Word
Processors?

Cheers

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 5:57 AM
To: Bob Jueneman
Cc: [email-masked]
Subject: Re: SV: Online Certificate Revocation Protocol

Bob,

(..)

> I really wasn't addressing the legal and/or technical requirements 
> for timestamping for certain  documents.  I think we all understand 
> what could and perhaps should be done, assuming the
> circumstances warrant it.

> Technically I agree with you -- it would be nice to be able to 
> confirm the validity of a certificate 15 years after the fact. 

I disagree with you. The right sentence should be:
"It would be nice to be able to confirm the validity of an 
*electronic signature * 15 years after the fact."

> But from a legal or business perspective, I would claim that is 
> pretty close to nonsense -- you simply aren't likely to get into 
> a dispute about whether a contract was signed properly 15 years 
> after the fact. 

It does make sense because someone will do an initial verification soon
after the signature has been generated and then the data captured at that
time will be re-used again to verify the signature later on.

Since the European Directive makes an electronic signature, *made under some
technical conditions*, equivalent to an handwritten signature, it is
necessary to be able to verify *again* such a signature as long as an
equivalent handwritten signature on the same type of transaction/document
can be verified. 

Denis

(remaining of the text deleted)

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 14 Jun 2001 11:41:46 -0400

I think we may agree on the philosophy.  But, some of your words are
confusing and misleading to me.
 
1.  The private key is not being kept active as your words can be
interpreted.  The public key certificate continues to be valid.
 
2.  I agree with you that would leave it up to the PKI and its CP and CPS as
to what to do with respect to the destroyed private keys.
 
3.  Since my sentiments are that destroyed keys pose minimal threat (one of
discovering the key), we should not make a recommendation or provide a
preferred approach if the private key is destroyed.  If we do provide a
recommendation, it should be that in most scenarios let the sleeping dogs
lie, i.e., do NOT revoke the certificate.

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 11:45 AM
To: 'jim'; Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

Would you agree Santosh?

-----Original Message-----
From: jim [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 4:43 AM
To: Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

Comments in line... 

Santosh Chokhani wrote: 

-----Original Message----- 
From: jim [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 13, 2001 10:10 AM 
To: Santosh Chokhani 
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix 
Subject: Re: Online Certificate Revocation Protocol 

  

Jim 

Santosh Chokhani wrote: 

-----Original Message----- 

Mark, 

Terry 

us 

code 
in 

with

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 14 Jun 2001 13:39:32 -0400

Mark:

I have the same understanding as you do.

-----Original Message-----
From: Scherling, Mark [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 1:47 PM
To: 'Tony Bartoletti'; jim; Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: RE: Online Certificate Revocation Protocol

In most CPs or Subscriber Agreements the subscriber has the right to ask
their key be revoked.  It is, correct me if I'm wrong, not the right of the
CA to refuse to revoke the authorized subscriber certificate.  There may be
a process that has to be completed such as written confirmation but that is
a formality.

The question that is being asked is if the subscriber says their key was
destroyed, should the CA revoke the certificate?  The answer as best we can
put it is it depends on the CP, CPS and the trust.  

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 10:34 AM
To: jim; Santosh Chokhani
Cc: Scherling, Mark; [email-masked]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol

>with the CP/CPS for the system.

All of this debate orbits around "who is on the hook" when bad things
happen.

If I suspect my key is compromised (but I cannot easily prove it), or I 
believe I have destroyed it (successfully or not), then what must I do to 
announce to the world that "any signatures generated after this point is 
time should not be attributed to me"?

If it is only up to the CA to make these determinations, and the CA chooses 
not to agree, how am I to protect myself from responsibility for future 
transactions made in my name?

If I make an effort to tell folks "this is the termination date of my key 
use", and the CA does not take action, do they (the CA) become responsible 
for any mischief that may ensue?  It would seem as if they must, since the 
decision on key reliability is in their hands.

___tony___

---

From: Luis Azevedo <[email-masked]>
Date: Sun, 17 Jun 2001 17:06:51 +0100

>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:[email-masked]]
Sent: sábado, 9 de Junho de 2001 10:03
To: [email-masked]
Subject: Online Certificate Revocation Protocol

Hi all,

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

   Signature       ::=     SEQUENCE {

   Request         ::=     SEQUENCE {

   CertID          ::=     SEQUENCE {
 
   Crin            ::=     SEQUENCE {

Hash Explanations
=================

   
-- 

C'you,

	Massimiliano Pala

---

From: "Nick Pope" <[email-masked]>
Date: Mon, 18 Jun 2001 17:33:31 +0100

Re-sending due to e-mail address problems:

>I agree with Denis.  The use of a "never valid" reason code needs to be
vary
>carefully considered before be included since it provides an easy means of
a
>signatory repudiating all his signatures.
>
>Nick Pope
>
>[mailto:[email-masked]]On Behalf Of Denis Pinkas
>Sent: 18 June 2001 09:59
>To: [email-masked]
>Cc: [email-masked]
>Liaquat,
>>  I agree a new reason code of ("never valid") has uses.  This will allow
a
>>  relying party when verifying a digital signatures using a certificate,
>which
>>  when performing revocation checking is found to be on a CRL with the a
new
>>  reason code ("never valid"), to detect that the digital signature should
>not
>>  be trusted even if the digital signature was produced before the time of
>the
>>  revocation of the certificate.   Otherwise in theory signature produced
>>  before the revocation will continue to be considered valid - not a good
>>  situation for the relying party or for the CA.
>
>This is the reverse situation. If a signature was tested to be valid e.g.
in
>June 2000 and the certificate was revoked for any reason e.g. in May 2001,
>then the signature tested good in June 2000, shall continue to be valid,
>otherwise it would not be a good situation for relying parties.
>
>Denis
>
>>  However, I cannot see the need to keep such a certificate on a CRL even
>>  after it has expired...what does this achieve?
>>
>>  Regards,
>>  Liaquat
>>
[mailto:[email-masked]]On
>>  Behalf Of Peter Gutmann
>>  Sent: 14 June 2001 11:13
>>  To: [email-masked]; [email-masked]
>>  Massimiliano Pala <[email-masked]> writes:
>>  >Peter Gutmann wrote:
>>  >>There's another revocation status which needs a way of indicating it
>which
>>  is
>>  >>somewhat trickier, I'll bring it up here in case anyone has any ideas:
>>  >>Sometimes a cert can be issued in error, what's needed here is a
>>  revocation
>>  >>reason which says that not only is the cert revoked, it should never
be
>>  and
>>  >>was never valid at any time for any reason.  You can sort of achieve
>this
>>  by
>>  >
>>  >In this case, when will br the entry removed from the CRL ? When the
>>  >certificate will be expired ?? Or should it be left in all future CRLs
?
>>
>>  Well, CMP leaves pretty much everything to CA policy so it's up to the
>>  individual CA.  I leave it in the CRL until the cert expires anyway, but
>>  that's just me (I'm also currently overloading the "undefined" reason
code
>  > in
>>  the hope that, since you're not supposed to use it, it's a spare code
>which
>>  can be used to mean "never valid", but it really needs its own reason
code
>>  to
>>  indicate the true status).
>>
>>  Peter.

--Paul Hoffman, Director