[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: can CRL's and short-life certs coexist?
> It seems to me to be important
> to support "lightweight" apps - ones which may not have access to the CRL,
> presumably usually through lack of connectivity, as well as the other reasons
> given for the two methods.
It could be possible for such apps to simply ignore the CRL,
or to fetch it whenever they could. It would depend on the level
of exposure that was acceptable. There is precedent for this
sort of thing already with credit cards, where low valued
transactions can happen without authorization codes, blacklist
In fact there is an equivalent case with short-lived certs (slc) and
no CRL. The same app. might well decide that a 2 day cert which
expired an hour ago was fresh enough for a low-valued transaction,
given that it didn't have the connectivity to always get a
completely fresh cert. (This is another example of the equivalence
Carl noted between CRL & short-lived certs).
It might be useful for apps with poor connectivity to have two
validity periods on an slc: a suggested maximum validity period P
which might be many months (giving some indication of
'reasonable' expected validity of the certified info), and a
'this quantum' validity Q (Q<=P) which is the current quantum
being doled out by the CA. Verifiers could then independently
vary their exposure between (and in the case of P, beyond) the
two validity periods, depending on connectivity, risk, and policy.
(The CA could even vary P as each quantum was dealt, in response
to changing conditions, or as a reputation was built or lost). A
CRL could be produced or not by the CA, and if produced, an app could
religiously fetch it, ignore it, or just fetch it whenever it could.
Ditto the certs themselves.
>Ben Laurie Phone: +44 (181) 994 6435
>Freelance Consultant and Fax: +44 (181) 994 6472
>Technical Director Email: email@example.com
>A.L. Digital Ltd, URL: http://www.algroup.co.uk