Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Stephen Kent <[e-mail]>]

At 4:51 AM -0400 3/30/11, Paul Wouters wrote:
>On Wed, 30 Mar 2011, 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).

Eric's text provide a good rationale for this, and I think a solid 
rationale is an important part of the requirements spec.  I would be 
a bit more precise, and note that the CAs that pose a threat are the 
TAs configured into the system, any CAs below those TAs, and any 
other CAs that have been accepted by the client as TAs.

>  > 2. Allowing TLS to work without getting a certificate from one of the
>>  established trust
>>  anchors.

right. also, don't we want the TAs acquired via DANE to be treated, 
for the session in question, to be as god as the configured TAs, 
i.e., yield no error messages/  (I'll duck for the moment the issue 
of EV certs and whether we ought
to have a DANE-validated icon, and what color it should be :-).)

>3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
>keeping statistics on these (as proven recently with Comodogate)
>
>Paul

Presumably #3 applies only to the configured TAs (and their offspring), right?

Steve