Re: Online Certificate Revocation Protocol

[Denis Pinkas <[e-mail]>]

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.