Re: [Trans] text to address DKG's conspiring CAs attack

[Stephen Kent <[e-mail]>]

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