Subject: RE: Revoking bogus certificates

From: Peter Williams <[email-masked]>
Date: Mon, 18 Jun 2001 16:06:39 -0700

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: Terwilliger, Ann [mailto:[email-masked]]
Sent: Monday, June 18, 2001 2:56 PM
To: [email-masked]
Subject: RE: Revoking bogus certificates

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.
>
>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
>
>Novell, Inc -- the leading provider of Net services software

---

From: Rich Salz <[email-masked]>
Date: Mon, 18 Jun 2001 22:23:53 -0400

> server certificates issuances per annum, for the last 5 years.

If a cert expires and nobody notices, does it make a sound?
(authenticode root expiring)

What if they held a revocation and nobody came? (SPn for a special
two-entry CRL)

> I do wish
> real world.

C'mon, given the state of client due diligence, the whole community
seems to be living in lala land, or dot-com bubble.

	/r$