Subject: RE: Revoking bogus certificates

From: Hal Lockhart <[email-masked]>
Date: Tue, 19 Jun 2001 12:36:05 -0400

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: "Liaquat Khan" <[email-masked]>
Date: Tue, 19 Jun 2001 22:03:05 +0100

With regards to the never valid discussion, I do not think that unwinding
transactions after they've happened or changing things retroactively in some
other away is a good idea.  But I also do not thinking that it is reasonable
for a CA to continue to be responsible to a RP for a bogus certificate after
it has been revoked and identified as never valid, if and only if the RP
verifies it for the first time after this revocation information has been
published.  If the RP had verified the certificate beforehand and found from
the CA that the certificate was valid (because it had not been determined
that the certificate was bogus at this stage) then of course the RP should
be protected from this and the previous transaction should not be unwound.
In this case the RP would need to prove that when the certificate status
check was first made the CA reported the certificate as not revoked, but
this is nothing new.

Therefore in my mind the never valid reason code is not to be used to unwind
previous decisions, but only for protecting new transactions which may
happen in the future.  But maybe I'm missing something obvious.

Regards,
Liaquat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hal Lockhart
Sent: 19 June 2001 17:36
To: 'Tony Bartoletti'
Cc: [email-masked]
Subject: RE: Revoking bogus certificates

Hal