ietf-mailsig
[Top] [All Lists]

RE: In response to Housley-mass-sec-review

2005-02-25 15:23:59

On Fri, 2005-02-25 at 13:07 -0800, Hallam-Baker, Phillip wrote:

In particular you should look at OCSP which entirely eliminates the issues
you raise wrt CRL size and has been deployed at very large scale. You should
also look at XKMS which has similar operational requirements to OCSP but
provides support for the complete key lifecycle and eliminates the need for
certificates.

Clearly a key centric PKI that is built on the legacy DNS system is not
going to be as satisfactory as a PKI as a purpose built Web Service such as
XKMS. There is however no reason why we cannot use DNS for the cases it can
support and migrate to XKMS for more comprehensive support.

Given that certificate revocation technology is built into Windows since Win
2000 the CA industry is well aware of the operational difficulties raised by
CRLs.

The review draft provided two perspectives for this concern.

One was how per-user certificates would entail a large amount of data
exchanged for large domains, should there be expectations that
certificates scale to each user.  For both certificates and CRL lists,
even when information is iteratively polled, the underlying amount of
information remains an impediment.  By making the certificate lifetime
longer to ameliorate network loads, then this also increases the amount
of revocation data that will also require caching.

In other words, big gets bigger.  These checks per-user would be done
within the session to prevent generation of bounces, but pushing
certificate and CRL information out to hard storage and refreshing it
via TCP based protocols does not seem as practical from a performance
perspective as per-domain keys cached and retrieved from DNS.

When scaled to just the server and not to the population at large, then
certificates do become more practical and would be akin to how they are
used for commerce.  For smaller or low-budget domains, the expense for
server certificates may become another concern, and will likely
represent another impediment for deployment.  Adding a
revocation-identifier signed within the signature header offers a viable
means for either approach, however.

-Doug 





  



 


<Prev in Thread] Current Thread [Next in Thread>