Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Yoav Nir <[e-mail]>]

On Apr 1, 2011, at 10:13 AM, Paul Wouters wrote:

> On Thu, 31 Mar 2011, Yoav Nir wrote:
> 
>> Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.
>> 
>> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.
> 
> Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
> that I vouched for via the RRSIG"?

Stated like this, it conveys policy. I just want it to say that this is the cert I'm going to use, and I can't vouch for anything there besides the public key.