Subject: Revoking bogus certificates

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 18 Jun 2001 14:04:16 -0600

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

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

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

---

From: david <[email-masked]>
Date: Mon, 18 Jun 2001 13:28:27 -0700

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.
>
>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.
><snip>
>Bob
>
>Robert R. Jueneman
>Security Architect
>