Rob,
On 16/03/16 17:45, Stephen Kent wrote:
Rob,
<snip>
So we (where "we" may or may not be TRANS) need to fix revocation!
Revoking an intermediate _certificate_ just isn't sufficient.
To be effective, the intermediate _public key_ needs to be revoked
somehow.
One does not revoke keys in a PKI. One revokes certs.
Steve, I know very well how the existing IETF mechanisms for
revocation (i.e. CRL and OCSP) work. But I don't see why that should
mean that new revocation mechanisms can't be invented, especially if
those new mechanisms can thwart attacks that CRL and OCSP can't.
I don't dispute the potential for developing new revocation mechanisms.
But, in writing the threat
analysis I am dealing with what is specified in current IETF standards.
If your comment was meant
to suggest a mechanism for use in browsers, not PKIs in general, then I
apologize. Also, it would
be good if there were an RFC defining browser cert blacklisting
mechanisms, so that we might know
what capabilities we can rely on, in general.
Note that, in PKI in general, revoking a key, vs. a cert, may be
inappropriate. For example, in the
RPKI context we focus on address and ASN extensions as capabilities, for
authorization. We might
want to revoke a cert, but not the key in the cert, because a new cert
will be issued with different extensions. We may not want to create
operational problems by requiring the new cert to have a new key.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
