Re: request for WG to adopt draft-chadwick-webdav-00.txt as a work item

[Stephen Kent <[e-mail]>]

At 11:01 AM +0100 9/11/07, David Chadwick wrote:
>Hi Steve
>
>As you know nearly everything in security is a tradeoff in one way 
>or another. What the webdav scheme gives you is instant revocation 
>status, which CRLs do not give you, but the tradeoff is having to 
>trust the repository. So the schemes are fundamentally different, 
>but I submit that there are many user requirements where the 
>tradeoff of instant revocation is preferable to the more 
>cryptographically protected though stale CRL scheme.
>
>regards
>
>David

The phrase "instant revocation status" is, I fear, a misnomer. In 
OCSP an RP can make a query about a single cert and get a response 
that applies to just that cert, but that says nothing about the 
relative freshness of the revocation  status data vs. what a CRL 
tells us.  The same is potentially true here.

Also, if one argues that a CA will manage a repository under the 
WebDAV approach to offer fresher revocation status data than a CRL, 
the same argument could be made for the CA managing an OCSP server, 
right? In the case of OCSP, one need not trust a repository, but 
rather trust an OCSP server.  Is there a difference? Maybe, maybe 
not. It will depend on what forms of authentication one requires for 
WebDAV access, e.g., if you mandated use of TLS and required that the 
TLS server cert be issued under the CA in question, then maybe the 
security would be equivalent to what we have with an OCSP server (not 
lightweight) with a server cert issued under the CA.

In general I think that instant revocation is over emphasized. In 
many (most?) contexts the decision to revoke a cert is a serious one, 
and thus people generally do not act very quickly. In fact, this is a 
big part of why the financial community insisted on cert hold status 
as a half-way revocation mechanism.  Thus the speed with which a 
revocation decision is reflected in a database (OCSP, CRL, or WebDAV) 
is probably the fastest link in the process chain.

Steve