Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Yoav Nir <[e-mail]>]

On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:

> To follow up on my comments at the microphone, there are two potential
> objectives for
> technology of this type:
> 
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 2. Allowing TLS to work without getting a certificate from one of the
> established trust
> anchors.

I think the current draft is mostly focused on the second objective. Unless we declare #2 to be a non-goal, a (web) client cannot do the regular PKIX validation of the certificate.

More specifically, with a type-2 certificate (CA cert in the record) you anyway have to validate the EE certificate using regular PKIX procedure, except that you replace the trust anchor store with the CA certificate in the DNS record. This makes sense for the 2nd objective, but not for the first (you could put the Verisign root certificate in the DNS record, but then you're protected from mis-issue only by the other CAs). So with a type #2 record, you get both objectives

With a type-1 certificate (EE cert in the record) you get objective #1, but how is a client to know whether it is intended to just compare bits or also to validate the certificate? As long as objective #2 is not a non-goal, the client can't rely on such a record containing a certificate that can be validated. Maybe we need three types of records: CA certificate, untrusted EE certificate, and PKIX EE certificate. In that case, I don't the what advantage an "untrusted EE certificate" has over bare keys. So maybe it should be: CA certificate, PKIX certificate (that needs to be validated) and bare keys.