RE: More on OCSP and CSL

[Simon Tardell <simon.tardell@xxxxxxxxxxx>]

> Antonio Lioy wrote:
>  
> > This is another view: the CSL is being used as a waiting
> > list for possibly revoked certs. If it is later revoked,
> > then you'll put it in the CRL, otherwise you'll remove it
> > from the CSL.
> > 
> > But I disagree with this view: if I temporarily lost control
> > of my smart-card, I can never know what has happened during
> > that period of time.
> 
> Yes, but I think that if you are not sure about some misusage
> of the private key, then you should request it to be revoked.
> 
> This is for two reasons: the first is about how long a CSL will
> become if we keep track about every suspension of certificates
> and the second is about your trusting in your key-pair.

> If we keep every suspension tracked on the CSL, it can get a
> very long list and it could suffer from problems related to
> this aspect (distribution, definition of delta's CSL, and so
> on... ). I'd like to avoid these problems as them tend to
> get the CSL more complex than needed.

Your CSLs will of course suffer from the same problems as CRLs but worse.
However this is only a problem if regularly transfer all of the list (CSL or
CRL) from a CA somewhere. 

The whole idea of having a _periodically_ updated list of the current status
of the database of the CA is to me a rather ridiculous attempt of modelling
an old technology solution to a problem using new technology, NOT solving
the problem with the new technology. (The old technology solution is of
course the printed books that merchants used to check your card against.)
Serializations of the database are needed when you need to transport all of
the data from the CA to somewhere, e.g. to startup the cache of a validation
authority -- other certificate status consumers should only care about the
status of the certificates involved in the operation they are about to
perform (that's why we have OCSP).

Finally, I do realize that issuing CRLs periodically is convenient from an
implementor's perspective (because that's what I am), but following the
arguments above I think it is unhealthy to mandate that nextUpdate _always_
be set in a CRL (like RFC2459 does).
 
> The second aspect is related on the fact that if you do not
> trust your key for a certain period, than you should not trust
> it at all because it could be open to every kind of attacks:
> let's say someone discovers your password and uses it non only
> when it is suspended, but he/her can get in touch with your key
> during the working time when you are having a coffe-break...
> 
> If you are now trusting your key it is possible you think that
> the 5 mins of a coffe break do not represent a real danger...
> 
> So my vision is: if you trust your certificate is because it has
> never been in danger, if there is a possibility your certificate
> (read key-pair) has been compromised (so it con be compromised
> again...) either if you are not sure about it, than you should
> revoke it...
[...]
> Once a key/pair has been compromised (or possibily compromised)
> it should not, to me, being trusted any more.

Well, if you have a smart card the idea is that your typical office pick
pocket, teenage son or whatever is the most common wallet poacher type, does
not have access to a tunneling microscope or some other equipment to extract
the keys from the card. So, it would suffice to change PIN code of the card
once you regain physical possession of the card to be able to trust the keys
from that moment on.

If you allow reestablishing trust in a smart card token that way or not is
again a policy question. But given the manufacturing cost of a smart card, I
think it is not unlikely that some CAs would.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
simon.tardell@iD2tech.com, http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999