Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey)

[Paul Wouters <[e-mail]>]

On Tue, 23 Apr 2013, Bert Greevenbosch wrote:

> I think name-to-key association is half of the problem, whereas revocation is the second half. SSH seems to focus on the first half, whereas OCSP-lite focuses mainly on the second half.

Revocation is only required in the indirect path. That is, supplier A
signs something for consumer B, and enduser C needs to verify B. Now A
needs a method to tell C about revocation of B.

When you use raw public keys, the authentication happens out of band. If
there are no three players, with two of them talking only indirectly,
no OCSP-like mechanism is required.

For instance, using DNS(SEC) with raw keys there is only B and C. When
B loses trust in their key, they simple remove it from DNS(SEC) to
communicate this to A. The same applies to SSHFP records in DNS(SEC)
or ActiveDirectory.

OCSP was only needed before because there were three parties. While it
is still possible an out of band method to validate TLS keys to require
three parties, any revocation list mechanism should be part of the out
of band method specification. I am not sure what out of band method this
OCSP-lite case covers. If there is a specification of that out of band
method, then that specification should perhaps include this OCSP-lite
specification as part of it.

I don't see a value of specifying a generic revocation method. I see
danger in such a specification if it _introduces_ a third player where
there should not be one for a specific out of band authentication
method.

Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can
tune the behaviour of when TLS raw keys are valid or not. No OCSP variant
is neccessary. The same is true for content based on ActiveDirectory/LDAP
or Radius/Diameter where there is already a central control mechanism
for relaying this information.

Paul