Subject: RE: Revoking bogus certificates

From: Carlisle Adams <[email-masked]>
Date: Mon, 18 Jun 2001 16:46:06 -0400

Hi Bob,

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Monday, June 18, 2001 4:04 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Revoking bogus certificates
 
(...some text deleted...)

> Normally, I would agree that the presumption-of-liability model is that
> the subscriber who is identified in the certificate is presumed to be
> liable for transactions signed by the keypair which is bound to the
> subscriber's identity in the certificate, until such time as that
> certificate is revoked BY REQUEST OF THAT SUBSCRIBER.
> 
> But this model implicitly assumes that the certificate has been issued
> correctly, and in particular that the subscriber has been duly notified of
> the certificate's issuance, and has accepted that certificate and the
> corresponding responsibilities and obligations. Otherwise, the subscriber
> may be completely uninformed and helpless to defend himself. some form of
> technical proof of possession was presumably demonstrated during the
> certificate's creation (or maybe not), but if the subscriber hasn't been
> properly identified then POP proves nothing.
> 
> In the case of a bogus certificate issued by the CA, either accidentally
> or deliberately, there is clearly no acceptance by the legitimate
> subscriber, who probably doesn't even know of the certificate's existence
> and therefore cannot request that it be revoked. 
 
(...some more text deleted...)

What you have described above gives a clear argument in favour of the
"confirm" message in CMP (RFC 2510 and subsequent updates).  In that
protocol, a cert is requested by an end entity, created by the CA (after POP
has been checked), and inspected by the end entity PRIOR to being
disseminated by the CA for public consumption.  It is the EE's confirm
message that triggers publication by the CA.  [A further confirm message
from the CA to the EE lets the EE know that it is now free to start using
the cert.]

I recall lengthy discussions regarding this extra round trip in the
initialization / cert-request protocol with some arguing strongly to have
just a single round trip (a la PKCS 10/7).  However, the explicit
confirmation messages make it clear to all parties involved just what can be
assumed regarding whether or not a certificate was ever valid.  As we have
seen, this can be important in some environments...

Carlisle.

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 18 Jun 2001 14:53:19 -0700

At 04:46 PM 6/18/01 -0400, Carlisle Adams wrote:

>Hi Bob,
>----------  From:   Bob 
>Jueneman[SMTP:[email-masked]]  Sent:   Monday, June 18, 2001 4:04 
>PM  To:     [email-masked]  Cc:     [email-masked]  Subject: 
 >   Revoking bogus certificates
>
>certificate is revoked BY REQUEST OF THAT SUBSCRIBER. But this model 
>implicitly assumes that the certificate has been issued correctly, and in 
>particular that the subscriber has been duly notified of the certificate's 
>issuance, and has accepted that certificate and the corresponding 
>responsibilities and obligations. Otherwise, the subscriber may be 
>completely uninformed and helpless to defend himself. some form of 
>properly identified then POP proves nothing. In the case of a bogus 
>certificate issued by the CA, either accidentally or deliberately, there 
>is clearly no acceptance by the legitimate subscriber, who probably 
>doesn't even know of the certificate's existence and therefore cannot 
>request that it be revoked.
>
>protocol, a cert is requested by an end entity, created by the CA (after 
>POP has been checked), and inspected by the end entity PRIOR to being 
>confirmation messages make it clear to all parties involved just what can 
>be assumed regarding whether or not a certificate was ever valid.  As we 
>have seen, this can be important in some environments...
>
>Carlisle.

I'm not up on my CMP, but if I can pose as the end-entity to a degree 
sufficient to convince a CA to have a bogus certificate issued, how is the 
CA to ensure that the "real" end-entity is the one that inspects the 
certificate, prior to its dissemination?  I can see this may sometimes 
work, and sometimes not, depending upon the specifics of the certificate or 
of the means by which the "impersonation" is effected.  For high-value (or 
broad-impact) certificates, such as code-signing, the second round trip 
needs to be made through an independent channel.

I don't see any escape from the fact that a bogus certificate (one never 
requested by the apparent end-entity) is always a possibility, and that 
upon such discovery, it is the CA that must provide a means to indicate 
that the certificate is "revoked retroactively".

___tony___

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

---

From: "Terwilliger, Ann" <[email-masked]>
Date: Mon, 18 Jun 2001 14:55:45 -0700

So in essence you are 'future-dating' a certificate--ensuring that the start
of the certificate validity period and private key usage period for some
classes of certificates (say high value) begin far enough out in the future
to allow confirmation/acceptance from the requestor before the certificate
becomes active.  

This is similar to what happens in the payment card world today.  A new or
renewed card will be distributed but will not become active until the
cardholder contacts the issuer to verify receipt and is authenticated
through a shared secret.

-----Original Message-----
From: david [mailto:[email-masked]]
Sent: Monday, June 18, 2001 1:28 PM
To: [email-masked]
Subject: Re: Revoking bogus certificates

Bob

Responding to your comment about a certificate "issued in error"....

It seems to me that we already have the mechanisms in place; what's needed 
is perhaps a better policy at a CA.

I'm patterning my thoughts upon the check-back that occurs when one 
subscribes to one of the IETF mailing lists.  I have in mind a situation 
where a "high-value" certificate is issued 'apparently' at the request of 
the subscriber.  The CA could insert that certificate into the appropriate 
(delta)CRL, with a code [forgive me for not knowing all the code reasons by 
heart] that said "temporarily unusable, but not revoked".

Now, the CA communicates with the subscriber in a manner depending upon 
their policy and trust model (and cost of the certificate), to confirm that 
the cert was actually requested.  The cert is then "revoked", or the CRL 
entry removed.

The other possibility is to issue such a certificate with a NOT-VALID-UNTIL 
date that's post-dated by an agreed amount, and allow that time for an 
off-line confirmation that the cert was legitimately issued.  This would 
give the CA time to revoke it.  I would expect CA's to charge more for such 
treatment.

David Kurn

At 02:04 PM 6/18/2001 -0600, you wrote:

>Denis, I am not so sure that I agree with your logic (I'm still thinking 
>about it), but you are absolutely right on one point -- the impact of a 
>bogus code signing certificate vis a vis nonrepudiation has not been fully 
>thought through.
>
>It appears that we may not have been thinking too clearly regarding the 
>possible stakeholders in the case of a bogus certificate issued by mistake 
>by a CA.  Perhaps we were all overly optimistic, but we now have certainly 
>seen evidence that we need to deal with that situation.
>
><snip>
>Bob
>Robert R. Jueneman
>Security Architect
>Novell, Inc -- the leading provider of Net services software

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 18 Jun 2001 18:03:25 -0400

Hi Tony,

> ----------
> From: 	Tony Bartoletti[SMTP:[email-masked]]
> Sent: 	Monday, June 18, 2001 5:53 PM
> To: 	Carlisle Adams; 'Bob Jueneman'
> Cc: 	[email-masked]
> Subject: 	RE: Revoking bogus certificates
> 
 
The CMP initialization exchange is protected by a MAC derived from
(out-of-band established) shared secret information between the EE and the
CA.  Depending upon the amount of entropy required by the CA for this secret
information, the probability of impersonation can be carefully controlled
(and effectively reduced to a negligible value).

Carlisle.

---

From: david <[email-masked]>
Date: Mon, 18 Jun 2001 15:22:54 -0700

Ann:

I guess you stated a lot more succinctly than I.  The only point I make is 
that the cert should be considered INVALID until it is confirmed.

I furthermore believe that for sufficiently-high valued certs, this 
confirmation should be out-of-band, and not rely upon CMP 
protocols.  There's really no replacement for that phone call, or the 
certified snail mail letter and a returned signature on company stationary.

In the credit card world, the 'value' isn't so high, as to forbid the 
simple phone call and touch-tone stuff with that hard-to-guess secret of 
one's social-security number.  Afterall, such shared secrets are real 
secrets.  Right?  <GRIN>  In the CC world, there are other mechanisms in 
place to limit the exposure.

David Kurn

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 18 Jun 2001 15:51:36 -0700

Hi Carlisle,

At 06:03 PM 6/18/01 -0400, Carlisle Adams wrote:

>Hi Tony,
>----------  From:   Tony Bartoletti[SMTP:[email-masked]]  Sent:   Monday, 
>June 18, 2001 5:53 PM  To:     Carlisle Adams; 'Bob 
>Jueneman'  Cc:     [email-masked]  Subject:        RE: Revoking bogus 
>certificates
>
>I'm not up on my CMP, but if I can pose as the end-entity to a 
>degree  sufficient to convince a CA to have a bogus certificate issued, 
>how is the  CA to ensure that the "real" end-entity is the one that 
>inspects the  certificate, prior to its dissemination?  I can see this may 
>sometimes  work, and sometimes not, depending upon the specifics of the 
>certificate or  of the means by which the "impersonation" is 
>effected.  For high-value (or  broad-impact) certificates, such as 
>code-signing, the second round trip  needs to be made through an 
>independent channel.
>
>I don't see any escape from the fact that a bogus certificate (one 
>never  requested by the apparent end-entity) is always a possibility, and 
>that  upon such discovery, it is the CA that must provide a means to 
>indicate  that the certificate is "revoked retroactively".
>
>CA.  Depending upon the amount of entropy required by the CA for this 
>secret information, the probability of impersonation can be carefully 
>controlled (and effectively reduced to a negligible value).
>
>Carlisle.

For well-established entities, I am sure the (out-of-band established) 
shared secret information is initialized with suitable pomp and 
circumstance to ensure that the real entity is being 
represented.  Thereafter, assuming the shared secret remains secure, all 
seems well (although I must ask, if this secret has been established a 
priori, why require end-entity confirmation of an issuance, the "second 
round trip"?)

I wonder about start-ups, and smaller parties.  If I can forge credentials 
reasonable to pose as an entity from the start (prior to there being any 
established relationship EE-to-CA) then it seems I can still 
succeed.  Granted, this is a more extensive and unlikely attack on average.

Somewhere, the rubber must meet the road.

Cheers!

___tony___

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 18 Jun 2001 15:46:20 -0700

Doesn't the invalidityDate extension in CRL Entries meet your
requirements?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Tony Bartoletti [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 2:53 PM

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 19 Jun 2001 14:55:17 (NZST)

>is perhaps a better policy at a CA.
 
This isn't going to work (or at least it isn't going to work in the real 
world).  It's a standard, uh, feature of the CMP protocol that a CA can issue 
a cert which needs to be revoked almost immediately (the way it works is that 
the CA issues a cert and presents it to the EE (possibly with RAs and who 
knows what sort of other middlemen involved) who then acknowledges it or 
rejects it.  If it's rejected, the CA has to revoke it with a status of "never 
valid" (no existing status value is appropriate)).
 
The reason why I originally brought this up is that although the spec says the 
CA MUST revoke this cert, there's no way to cleanly handle it in a CRL without 
the existence of a "never valid" reason code.  This operation is somewhat 
different from the issued-in-error-and-used-live case since it represents an 
undo on the immediately preceding issue operation rather than a "oops, that 
cert last week is a dud" type operation.
 
Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 19 Jun 2001 15:02:51 (NZST)

Ambarish Malpani <[email-masked]> writes:
 
>Doesn't the invalidityDate extension in CRL Entries meet your requirements?
 
Not really, it merely says that (as far as the CA is aware, ie it may have 
been merely claimed by the EE) the private key (or whatever you're 
interpreting as the reason for the revocation) was invalid starting from the 
given time.  It doesn't unambiguously say that the cert was issued in error 
and should never have been issued (and by extension was never valid at any 
time for any reason).  The way I see it, a claimed invalidityDate can come 
from the EE while a never-valid reasonCode can only come from the CA and 
definitely says that the cert was never valid.
 
Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 18 Jun 2001 21:17:14 -0700

Hi Peter,
    If the behavior you are trying to get the application to
exhibit is reject signatures associated with the offending
certificate, you should get that behavior with any application
that does the right thing with that extension in the CRL/OCSP
response.

The legal battles of whose liability it was will anyway be
fought outside the electronic world....

Ambarish

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 8:03 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: "JANES, Mark" <[email-masked]>
Date: Tue, 19 Jun 2001 09:13:38 +0100

So who's IP?

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: 19 June 2001 00:07
To: 'Terwilliger, Ann'; [email-masked]
Subject: RE: Revoking bogus certificates

Its also what happens in 40,000 Internet PKI secure
server certificates issuances per annum, for the last 5 years. I do wish
PKIX had at least a minimum of resemblance to the 
real world. We are in a classical OSI vs IP situation,
where this time IETF/PKIX is playing the role of OSI.

-----Original Message-----
From: david [mailto:[email-masked]]
Sent: Monday, June 18, 2001 1:28 PM
To: [email-masked]
Subject: Re: Revoking bogus certificates

Bob

David Kurn

>Novell, Inc -- the leading provider of Net services software

___________________________________________________________________________
This email is confidential and intended solely for the use of the 
individual to whom it is addressed. Any views or opinions presented are 
solely those of the author and do not necessarily represent those of 
Sema. 
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or 
copying of this email is strictly prohibited.

If you have received this email in error please notify the Sema UK
Helpdesk by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________

---

From: "Bland, Graham" <[email-masked]>
Date: Tue, 19 Jun 2001 09:22:48 +0100

Bob,

I see the problem here as varying depending on the use to which the bogus
certificate has been put.

In the code signing case revocation of the certificate ideally should say
'do not trust code signed by this certificate regardless of the time at
which you installed it and verified the signature', this is the never valid
case.

However in the case for example of a goods purchase transaction made and
validated before the revocation, we cannot allow a status which implies
'please unwind all transactions using this certificate, the purchaser must
return the goods and a refund will be issued' as this removes all the
certainty which PKIX is trying to provide.  There is no 'real time'
revocation of certificates, a process must always be followed which leads to
a time lag between the need to revoke (stolen), the realisation of the need
to revoke (theft discovered) and the publication of the revocation
information.

The primary difference here must be who is liable for the certificate
issuance.  No protocol will ever guarantee that the party identified in the
certificate has actually requested it, just look at the number of companies
who fall for false invoicing scams.

My recommendation would be this:

To revoke such a certificate the CA may unilaterally revoke the certificate
using the status of 'invalid certificate' The revocation date may be set to
the issued date of the certificate, however the definition of 'invalid
certificate' status must state that this is an advisory status and the
effective date of revocation should be taken as the CRL issuance date.

This allows applications which for example are involved in code verification
to identify code which should no longer be trusted and allow transactions
made in good faith to still be valid based on the information available at
the time the transaction was processed.

Graham Bland  

> From: Bob Jueneman [mailto:[email-masked]]
> Sent: 18 June 2001 21:04
> Denis, I am not so sure that I agree with your logic (I'm 
> still thinking about it), but you are absolutely right on one 
> point -- the impact of a bogus code signing certificate vis a 
> vis nonrepudiation has not been fully thought through.
> 
> It appears that we may not have been thinking too clearly 
> regarding the possible stakeholders in the case of a bogus 
> certificate issued by mistake by a CA.  Perhaps we were all 
> overly optimistic, but we now have certainly seen evidence 
> that we need to deal with that situation.
> 
> Normally, I would agree that the presumption-of-liability 
> model is that the subscriber who is identified in the 
> certificate is presumed to be liable for transactions signed 
> by the keypair which is bound to the subscriber's identity in 
> the certificate, until such time as that certificate is 
> revoked BY REQUEST OF THAT SUBSCRIBER.
> 
> But this model implicitly assumes that the certificate has 
> been issued correctly, and in particular that the subscriber 
> has been duly notified of the certificate's issuance, and has 
> accepted that certificate and the corresponding 
> responsibilities and obligations. Otherwise, the subscriber 
> may be completely uninformed and helpless to defend himself. 
> some form of technical proof of possession was presumably 
> demonstrated during the certificate's creation (or maybe 
> not), but if the subscriber hasn't been properly identified 
> then POP proves nothing.
> 
> In the case of a bogus certificate issued by the CA, either 
> accidentally or deliberately, there is clearly no acceptance 
> by the legitimate subscriber, who probably doesn't even know 
> of the certificate's existence and therefore cannot request 
> that it be revoked. 
> 
> Revocation in this case must be unilateral and solely the 
> CA's responsibility, rather than due to a request by the 
> subscriber, and so there is no reason why the subscriber 
> should be held liable for any signatures created and verified 
> by that certificate, either before or after the error is 
> discovered.  Instead, the liability is clearly on the CA, and 
> in order to minimize that liability, the CA needs to takes 
> steps to ensure that that key will never be accepted again, 
> REGARDLESS OF WHEN THE INITIAL TRANSACTION MIGHT HAVE BEEN 
> TIME STAMPED, and whether or not some transaction might have 
> already been accepted as valid.
> 
> If a transaction has already been validated once, before the 
> certificate is revoked, then the liability is clearly on the 
> CA if that can be proven and harm resulted.  However, many 
> transactions are validated multiple times, either as they 
> flow through many people's hands, or as a given transaction 
> is reexamined for some reason, with a code signing 
> certificate being the most obvious example.
> 
> In this case, in order to prevent even further harm, the CA 
> really does have a legitimate reason for effectively 
> backdating the CRL to the beginning of the validity period, 
> in order to keep the damage from being compounded.
> 
> Suppose a piece of signed code was dated January 1, 2001, and 
> installed on January 2nd, after having validated that the 
> certificate was apparently good.  And let's even suppose that 
> we had a timestamped proof that the certificate was allegedly 
> valid at that time, and that we saved that proof along with 
> the signed module.
> 
> Now on February 1st, during a routine reboot when all of the 
> module's signatures are revalidated, it might be noticed that 
> the certificate has now been revoked.  But according to your 
> logic, it wouldn't be necessary to question that code, for 
> you have timestamped evidence that the certificate was valid. 
>  Unfortunately, the fact that it was timestamped as being 
> valid doesn't make it so, and in this case, despite the 
> timestamp, the certificate was not valid, even back then.
> 
> I therefore think that I am coming to the same conclusion 
> that Peter did, and that is that some kind of an "Issued in 
> error, never valid, CA accepts full responsibility" error 
> code may be appropriate to highlight this problem in the 
> event of subsequent validations.  Otherwise, if the date of 
> signing preceded the expiration date, the problem might not 
> be noticed.
> 
> 
> But I want to emphasize that this is not a code that can be 
> requested by the subscriber if a certificate was validly 
> requested, issued, and most importantly, accepted by the real 
> subscriber.  So it isn't a case of the legitimate subscriber 
> attempting to repudiate transactions after the fact.
> 
> But this is admittedly new and unexplored territory, and I'm 
> open to whatever well-thought out counter-arguments can be made.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> >>> Denis Pinkas <[email-masked]> 06/18/01 06:43AM >>>
> 
> Peter,
> 
> I do not want to come into long discussions on that topic. I 
> just wanted to
> make sure that "never valid" will be dropped.
> 
> > >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.
>  
> > But if the certificate was issued in error then it should 
> (once discovered) be
> > marked as never having been valid for any purpose at any 
> time.  Are you saying
> > that a bogus cert should be regarded as valid until it was 
> officially revoked?
> 
> Before the "error" was discovered, relying parties have 
> legitimately used
> the *valid* certificate. The CA may be liable for the error. 
> This depends on
> the guarantee attached with the certificate.
> 
> > Does this mean that if I get something signed with one of 
> those bogus
> > Microsoft certs I should regard it as coming from MS 
> provided it was signed
> > before they were revoked?
> 
> The answer is not as simple as "yes" or "no". In order to be 
> able to tell
> that a signature is valid, the relying party must prove that 
> the signature
> was checked as valid at a time T prior to the revocation 
> time. In the case
> you cite, unless the relying party can prove that he made the 
> verification
> before the revocation was announced, then he cannot claim for 
> any dammage.
> 
> In other words, if I take today one signature made by that bogus
> certificate, I will need to prove that I have verified the 
> validity of it at
> the time I used it. If I use it for the first time today, I 
> would need to
> get a time-stamp over it today. In that case, that's too 
> late: my time-stamp
> will be after the revocation date.
> 
> Now, you are probably going to tell me that you could re-use the data
> captured by someone else that did the validation before the bogus
> certificate was revoked (some kind of replay attack). In the 
> work I have
> been involved with, I have worked in the context of signed business
> transactions, but not signed code. In the context of signed business
> transactions at least one party is deeply interrested to make 
> sure that the
> signature is valid and the signature applies to conditions between two
> parties.
> 
> In the context of signed code, thousands of relying parties 
> are interrested.
> It is an un-explored area. I would tend to say that we should 
> have a replay
> protection against the above scenario of attack. One possible 
> direction
> would be to link the signed applet that has been used with 
> the transaction
> making use of it. In this way, a relying party could validly 
> claim that his
> transaction has been done using the bogus applet, otherwise 
> there is no
> proof.
> 
> Denis
> 
> > Peter.
> 
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Jun 2001 14:24:10 +0200

Bob,

> Denis, I am not so sure that I agree with your logic 
> (I'm still thinking about it), but you are absolutely right 
> on one point -- the impact of a bogus code signing certificate 
> vis a vis nonrepudiation has not been fully thought through.

Agreed.

(text deleted)

> Suppose a piece of signed code was dated January 1, 2001, 
> and installed on January 2nd, after having validated that 
> the certificate was apparently good.  And let's even suppose 
> that we had a timestamped proof that the certificate was 
> allegedly valid at that time, and that we saved that proof 
> along with the signed module.

You have a proof that the signed code was valid, but you have no proof that
you used the signed code and that it has created a dammage to you.
In order to prove that you had such a dammage, I said that one possible
direction would be to link the signed applet that has been used with the
transaction making use of it. In this way, a relying party could validly
claim that his transaction has been done using the bogus applet, otherwise
there is no proof.

(more text deleted)
  
> But I want to emphasize that this is not a code that can 
> be requested by the subscriber if a certificate was validly 
> requested, issued, and most importantly, accepted by the 
> real subscriber.  So it isn't a case of the legitimate 
> subscriber attempting to repudiate transactions after the fact.

I understand the difference, but even so, I do not think this kind of status
is needed.
 
> But this is admittedly new and unexplored territory, 

I think we both agree on this. :-)

Denis

> and I'm open to whatever well-thought out counter-arguments can be made.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 18 Jun 2001 21:07:35 -0600

Carlisle and David,

I completely agree with you regarding the absolute necessity of having some confirmation of acceptance by the EE back to the subscriber.  But there are two problems.

First of all, the more mechanized these processes are, the more likely it is that the confirmation message goes to, and comes back from, the bogus subscriber, not the real one.  If the failure is one of not doing sufficient due diligence, not to see if the subscriber listed in the certificate is indeed a member in good standing within the community, etc., but to confirm that the entity holding the private key is in fact duly authorized by the REAL entity, then no mechanized process is likely to help.

Second, the primary beneficiary of this process is the CA, not the relying parties at large.  If the CA can show proof of acceptance from the subscriber, then they are off the hook for the liability.

The situation we are potentially facing, as was apparently the case with the VeriSign/Microsoft certificate, is when a certificate request comes in containing the name of a perfectly valid enterprise, in fact one that the CA has done extensive business with, yet something goes wrong with the process.

The proper due diligence investigation should assure three things:

1.  That the listed enterprise actually exists, and that they have a legal right to use the requested name and other attributes.
2.  That the certificate is being requested by a duly-authorized agent of that enterprise, and that that agent's authorization is still valid.
3.  That that particular agent did in fact request this particular certificate with this particular key, and that this isn't an unauthorized request being carried out by either an insider or an outsider.

Although confirmation processes may help uncover accidents, I don't see how they can resolve these particular situations, which are process oriented and seldom computerized.  In fact, requiring them to be computerized would be circular, if what is being requested is a certificate that would allow such processes to be performed safely!

Ideally, I would hope that these confirmations would be carried out by a minimum of six separate processes, say three mechanical or programmatic, and three involving human judgement or some external agency, preferably involving a potential felony violation if violated.  For example,  Registered Mail could be used for confirmation, which not only requires identification of the acceptor by a postal employee, but causes two different felony statutes to kick in  ― Misrepresentation of to a Federal Official, and Mail Fraud ― if someone spoofs the system.

Assuming each of these six processes have at least a 90% chance of uncovering a fraudulent request, then there would be a one in a million chance of a bogus certificate getting out.

Unfortunately, not all such crimes could be effectively prosecuted, for example if the perpetrator was an underaged minor, or perhaps an outraged Chinese hacker after the spy plane incident.  So no absolute guarantees can be given.

In addition, there is always the possibility of insider collusion or corruption within the CA, or simple incompetence (gross negligence).  I'll let the lawyers deal with the court cases and the liability ― our job is just to help figure out how the CA can sweep up the pieces after the problem has been discovered.

We all know the bumper sticker " **** Happens".  Well, it does, sometimes.  And we have to design processes that are robust and self-correcting despite those kinds of flaws. Systems that require perfection as an input almost never deliver it as an output, and we would be naive not recognize this, particularly after a rather egregious example. 

Its rather depressing that we are just getting around to this level of understanding, 10 years after Steve and others wrote RFC 1422!

"Ve get so soon alt, und so late schmart!"

Bob

>>> Carlisle Adams <[email-masked]> 06/18/01 02:46PM >>>
Hi Bob,

 

Carlisle.

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 19 Jun 2001 08:40:39 -0600

Graham,

I fully understand the discomfort that would caused if we were to issue an "unwind" command to a whole lot of transactions.  But this may be unavoidable if the certificate on which those transactions were based is in fact erroneous.

Let's try think this through carefully.
>which you installed it and verified the signature', this is the never valid

Correct.  But please note that the "never valid" code is just a REASON code.  It does not, and should not, take the place of the effective date of the CRL, which is whenever the problem was discovered and/or published.
>a time lag between the need to revoke (stolen), the realization of the need

Unfortunately, in the case of a major CA screw-up, all bets are off as to the legitimacy of all pending transactions, and all previous transactions will certainly have to be scrutinized by both parties.  Again, it isn't the subscriber who is requesting that the certificate be revoking, it is the CA (no doubt kicking and screaming, and perhaps only under a court order).

This doesn't necessarily mean that all previous transactions are in fact invalid.  Presumably the vast majority of transactions between honest trading partners would go through correctly even if there were not PKI involved at all.

There is, however, the chance that an order for business supplies gets delivered to "Itty Bitty Movers" but charged to International Business Machines Corp, because the certificate said "IBM" and that's how the payment invoice was indexed in the system.  In that case, unless Itty Bitty Mover's returns the goods, they are going to owe the supplier, and the real IBM is going to have to receive and adjustment to their invoice.  And if they have already paid it, despite the fact that they hadn't received the goods, some more adjustments are going to have to be made.  and that's just the way it is.

Except perhaps in the interbank transfer system, there are few cases where absolute liability applies, and someone is out the money no matter what happened.  And PKI isn't going to suddenly change business practices all that much -- certainly if that supplier wants any further business from a good customer who wasn't at fault.
>who fall for false invoicing scams.

If you are asking for nine nines reliability, I would agree.  I think that six nines ought to be achievable, and is about the minimum in the case of a major code signing certificate, because of the enormous number of people who might be impacted.
>effective date of revocation should be taken as the CRL issuance date.

No.  The revocation date should be set as usual.  This preserves the ability of the relying party to claim damages if and only if his reliance was based on the apparently valid status of the certificate before it was revoked.  And by the way, this does NOT require all sorts of elaborate, bullet-proof time-stamping procedures, although that might be nice.  The standard in a civil (tort) process is  merely the "preponderance of the evidence", and that evidence can include business records such as time and date entries in the file system.
>the time the transaction was processed.

But by setting the CRL revocation date to the date when the problem was discovered, not to some roll-back date when the certificate was first issued, then the systems still works.  The "never valid" flag merely alerts users who may have an occasion to revalidate some transaction or piece of signed code that there is something seriously amiss.

Bob

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 21 Jun 2001 09:49:45 -0600

Hal, that was a useful attempt to at least highlight the apparent differences.

But perhaps we can find some accommodation between the views.

With respect to "true" NR (whatever that really means in practice), I don't have a problem with what you said -- "This group wants it to be the case that if a RP does all the right things and determines that a signature is valid at some point, then no technical mechanism can come along and change this retroactively." -- and I don't think that anything I have proposed would have such an effect.

In particular, I would propose that in ALL cases, the revocation date of a particular certificate should be the date/time (within a few seconds, perhaps) when the CA first published a CRL containing that revocation, where published means "made widely available to any requestor".

So no fair sitting on the request for two weeks, and then backdating the invalidity time to when the  revocation request was received but not acted on.  And certainly, backdating the invalidity date to when the subscriber, the local prosecutor, or some revisionist historian "thinks" that a compromise occurred should not be tolerated.  It is the date of publication that matters from a NR perspective, because that is the earliest date by which an RP could have taken notice of the change of status and modified his behavior accordingly. Anything else falls into the area of mental telepathy and prognostications, at least from the perspective of the RP.

However, the revocation date and the reason code for the revocation are two different things.

Maybe it would have been better to have had two dates -- one would be the revocation date, and the other would be the "last known valid date".  And BTW, note the significant difference between a "last known valid date" and a "suspected compromise date". The last known valid date is the last time the subscriber is reasonably sure that the key hadn't been compromised, and so he would essentially be saying that any transactions prior to that time are to be considered valid, and he will stand behind them, whereas any transactions after the revocation date are certainly invalid, and will be rejected.

Of course the rub comes when the date of a transaction is in between those two dates -- then it's in a sort of twilight zone where the legal issues and assumptions are the most important, and not the technical ones.

Technically, in this twilight period the RP is entitled to a rebuttable presumption that it was the subscriber that signed the transaction, since the certificate hadn't been revoked.  And IF (capital letter IF) the governing law or contract assigns strict liability to the subscriber in that case, then the RP can wash his hands of the matter and get his money back, even if he knew or had reason to know that something was amiss.

More commonly, however, the law does not assign strict liability to the apparent signer. Instead, most of the time the relying party is required to rely on (in part) "commercially reasonable" judgment in accepting a transaction.  So if the RP read in the newspaper about a major robbery at the subscriber's premises the night before he receives a significant order, apparently from the subscriber but with a different "ship to" address, then he has some responsibility to investigate further, just as he would without PKI.

Likewise, if I download some code from the www.microsoft.com, and it is signed with a certificate apparently issued to Microsoft, then it is reasonable from me to assume it came from Microsoft.  But if I download the software from www.saddamhussein.com, yet it is signed by Microsoft, I might have some occasion to at least wonder what was going on, and perhaps check further.

In the case of the naive consumer, the law is even more forgiving.  The person who actually did sign the transaction, i.e., using a stolen key, is in fact liable for the transaction, but assuming that person is unknown, most of the risk of loss falls on the merchant and/or the subscriber's bank.

But I don't believe any of this negates in any way the use of the invalidity date as I describe it.

Now, suppose it wasn't the subscriber who screwed up and allowed his key to be compromised, but rather the CA.  If we had the flexibility of a "last known valid date" we could set that date to zero, or to the start of the certificate validity period. But in any case the date the CRL was published MUST be the revocation date for that certificate, because that is the date that determines when strict liability shifts from the alleged subscriber (and/or the CA) to the relying party, and that must remain inviolate.

Remember -- the legal principle is that the person who actually signed the transaction is in all cases liable for his signature, AND THIS IS TRUE EVEN IF THE CERTIFICATE IS REVOKED or HAS EXPIRED.  If you revoke your certificate and then sign something, you may still be held liable for that act, assuming that it can in fact be proven that you signed the transaction.  The fact that the certificate was revoked may provide you some defense as to the reasonableness of the RP accepting the transaction, but you are the still the signer assuming that can be proven.

So in the case of the bogus Microsoft certificate, if that key had actually been used (and I haven't heard any evidence that it was), then the person who possessed that key and actually signed a transaction with it would be liable.  The tricky part is catching him, and even if he were caught he is not likely to have sufficient assets to cover his civil liabilities, but those are different issues.

So in the case of a bogus certificate, there presumably is someone out there in possession of the corresponding private key, or at least there might be.  And if that person could be caught, VeriSign would presumably be able to sue him and pass off a good part of whatever liability they have to Microsoft and/or all of the relying parties, but until that time VeriSign is presumably liable.

Now, given their CPS, it isn't likely that they would be held to a strict liability standard in any case, but if they were, it would presumably end upon the publication of a CRL, i.e., on the published invalidity date. (I'm ignoring the fact that the MS browser couldn't handle the CRL -- that makes the facts a little bit more messy.)

However, that situation wasn't changed appreciably by all of the publicity that let everyone know that the certificate was bogus from the start, and likewise, it wouldn't have changed if a "Never Valid" or "Issued in error" reason code had been included in the CRL. that's essentially the same as publishing the facts in the newspaper, except for the fact that it is more readily processed during certificate validation.

Perhaps "Issued in error" would be a more accurate and more acceptable terminology, because from the point of view of the relying party the certificate certainly was valid up until the moment it was revoked.  An even more euphemistic term would be "Issued but not accepted".

So in my judgment, a "Never valid", "Issued in error" or "issued but not accepted" reason code is NOT an attempt to roll back the clock or retroactively invalidate transactions that have already been accepted and processed -- what is done is done, and all we are talking about in that case is who should pay and how much.

But as compared to a possible covert key compromise, when it is anyone's guess when the key might have been stolen, in this case we know that the certificate was bogus from its creation, and in that case helps both the RP and the CA if any further damage can be prevented.  Maybe it is possible to undo the transaction, uninstall the software, or whatever, and in that case that ought to be done and done promptly, and figure out the size of the damages later.

I confess that I haven't followed the argument about emergency CRLS closely enough to understand the issues, so I won't comment on that.

But I do think that is possible to have both strict liability based on the date of publishing of the CRL, AND include the concept of an "Issued in error" code to limit the consequential damages. The two concepts are not incompatible.

Bob

Robert R. Jueneman
Security Architect

>>> Hal Lockhart <[email-masked]> 06/19/01 10:36AM >>>

Tony Bartoletti wrote in part:

> upon such discovery, it is the CA that must provide a means 
> to indicate that the certificate is "revoked retroactively".

After listening to all these related threads, it seems to me that this
working group needs to face up to the fact that there are two camps with
distinctly different views of revocation. These views cut across emergency
CRLs, NeverValid reason and invalidityDate. They are also independant of
assumtions about the availablility of a trusted time source and the
difference between signed code and signed data. 

I think both views have sound arguments, but I do not see any way to
reconcile them. I also do not think we can ignore this difference forever.
At least in an open PKI, the views directly affect the operation of an RP.

I will label the two views with what I consider neutral names, as I am not
in either camp at the moment.

The group I will call "consistency" is focused on either true NR or at least
situations where some action occurs which is difficult to reverse. "We
shipped the TV to Romania." This group wants it to be the case that if a RP
does all the right things and determines that a signature is valid at some
point, then no technical mechanism can come along and change this
retroactively. (This has nothing to do with might happen in a legal
proceeding.) This group want to outlaw or deprecate the use of NeverValid,
invalidityDate in the past and is even suspicious of emergency CRLs, because
they can "alter history", leading to irresolvable conficts.

The group I will call "accuracy" wants to get the word out no matter what.
If a cert is issued in error, they want to mark it NeverValid. If they get
evidence of a key compromise, they want set invalidDate to the suspected
date of compromise even if it is a good while in the past. They are in favor
of issuing emergency CRLs. This group believes that if a key is invalid,
especially if it may be in the hands of an attacker, the most important
thing to do is to make sure everybody stops trusting it from the point it
became invalid. This group believes that the fact that someone may have
already trusted a key that they should not have, will have to be dealt with
sooner or later and should not be swept under the rug.

Neither of these views necessarily says anything about who is liable for
errors. I believe it would be best to leave this for the lawyers to decide.
However, obviously a party who is never informed of something, by design, is
in a strong position to disclaim responsibility.

Hal

---

From: Carlisle Adams <[email-masked]>
Date: Thu, 21 Jun 2001 17:59:09 -0400

Hi Ann, Peter,

> ----------
> From: 	Peter Williams[SMTP:[email-masked]]
> Sent: 	Monday, June 18, 2001 7:06 PM
 
Peter, you wish there was "at least a minimum of resemblance to the real
world".  In fact, the resemblance is striking.  See below.

> renewed card will be distributed but will not become active 
 
CMP analogy:  "A new or renewed certificate will be sent to the EE in the
response message but will not be published or otherwise distributed..."

> until the
> cardholder contacts the issuer to verify receipt 
 
CMP analogy:  "until the EE contacts the CA using the confirm message to
verify receipt..."

> and is authenticated
 
CMP analogy:  "and is authenticated through a shared secret (i.e., the MAC
on the confirmation message, using a symmetric key derived from the shared
secret)."

The procedure is very close (almost identical).  In fact, if the CA wished,
it could future-date the certificate (by a few seconds, minutes, hours,
whatever) so that even the EE couldn't use it before the confirmation
message had been sent.  And, if a valid confirmation message didn't show up
in time, the cert could be revoked prior to ever being usable, if the CA
wanted to do this.

Peter, I honestly don't see what your difficulty is here.  What makes you
think that this aspect of PKIX is so different from the "real world"?

Carlisle.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 22 Jun 2001 20:07:52 (NZST)

>response message but will not be published or otherwise distributed..."

.. at least as far as the CA knows, the EE can do whatever it wants with it.

>The procedure is very close (almost identical).  In fact, if the CA wished, it
>could future-date the certificate (by a few seconds, minutes, hours, whatever)
>so that even the EE couldn't use it before the confirmation message had been
>sent.  And, if a valid confirmation message didn't show up in time, the cert
>could be revoked prior to ever being usable, if the CA wanted to do this.

Some of the things required in CMP already make it extremely difficult to
reliably implement a CA (key update being the main example), having to
implement kludges like this isn't going to help much... I'd really prefer not
to have to code hard real-time constraints with full fault-tolerance into my CA
just to get a cert issued.  Handling this in the presence of faults is going to
be almost impossible (what happens if the CA server crashes, or the EE DOS's
it?  What if the relying party's clock is out (virtually guaranteed with a
Windows machine)?). This seems to be relying on luck in order to function,
which isn't a good way to run a PKI.

Peter.

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 22 Jun 2001 11:20:59 -0400

Hi Peter,

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, June 22, 2001 4:07 PM
> To: 	[email-masked]; [email-masked]; [email-masked]
> Cc: 	[email-masked]
> reliably implement a CA (key update being the main example), 
 
I beg to differ on this point.  There are a number of reliably-implemented
CAs out there using CMP (even offering proper key update), and they don't
seem to have been "extremely difficult" to do.

> having to
> implement kludges like this isn't going to help much... 
 
Nobody has to implement this.  Ann mentioned "future-dating the credit
cards"; all I said was that if a CA wanted to copy such a practice, it could
do so within this protocol.  That's it.  No recommendation on whether this
was a good idea or bad, easy or hard to do, worth doing or not.  Simply "if
a CA wants to do this, there's nothing in the protocol to prevent it".  Such
a statement hardly seems to merit the following reaction:

> I'd really prefer not
 
Carlisle.

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 22 Jun 2001 12:25:37 -0400

The effect of revoking the CA's certificate with reason code
"keyCompromise" may depend on whether the RP is treating that CA as a
trusted root or not.  If it isn't, the CA revocation will certainly work.
If it is, the RP MIGHT not check for its revocation status.  In such a
case, revoking the client certificates with reason code caCompromise
provides an extra safeguard.

          Tom Gindin

[email-masked] (Peter Gutmann)@mail.imc.org on 06/20/2001
10:44:37 PM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked], [email-masked], [email-masked],
      [email-masked]
cc:
Subject:  RE: Revoking bogus certificates

"Paul Gogarty" <[email-masked]> writes:

>>(Looking through the codes again, what *is* a caCompromise, as opposed to
a
>>keyCompromise?  Could this be used for neverValid (caCompromise implies
they
>>issued the cert in error)?  OTOH a CMP-style "undo" isn't really a
>>caCompromise, and it's possible that many CAs won't like using a reason
code
>>which implies they screwed up).
>
>It was my understanding that caCompromise signalled that the certificate
had
>been revoked because the private key of the CA had become compromised.

Wouldn't that be handled by revoking the CA's key with a reason code of
keyCompromise?

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 26 Jun 2001 23:18:02 (NZST)

"David P. Kemp" <[email-masked]> writes:

>Are you saying that CMP is uniquely challenging in this respect (in a manner
>that, say, CMC would not be)?  Or are you saying "certificate update is a
>difficult requirement - PKIX shouldn't have any protocol to satisfy it
>reliably."?

The point of my posting wasn't to criticise CMP as a whole, but to point out
that there are certain operations which are a real pain to handle, with the
proposed postdated certificate issue being the most painful of the lot.  In
terms of error recovery handling, the breakdown is as follows:

Basic PKCS #10 -> cert: None (my implementation is build on top of a TP system,
  this operation doesn't need anything not already provided by the TP
  software).  I haven't thought too much about what it'd take to implement CMC,
  but since it's built on top of this sort of mechanism I assume it'd fall into
  this category in terms of compelxity of error recovery.
CMP normal cert issue (in CMP terms, ir, cr, and rr): About 50% of the error
  recovery code (this covers a lot of operations).
CMP updates (in CMP terms, kur): The remaining 50% of the error recovery code.

>One third of code to handle fault recovery -- that doesn't sound too extreme.

It is if you consider that at least half of that is to handle recovery for
kur's (that's as much as for all other operations combined).  The postdated-
issue operation would be even nastier in that it leads to (relatively easy-to-
encounter) error situations where you can't ever recover.  What I was trying to
do was motivate people into putting a bit more thought into what it's going to
take to implement some of the stuff that's appearing in RFCs (I've been tempted
to add a config option to my code to disallow kur just to avoid the headaches
that processing them reliably causes, so users can choose between reliability
or kur handling).

Peter.