Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Yoav Nir <[e-mail]>]

On Mar 31, 2011, at 3:09 PM, Martin Rex wrote:

> Yoav Nir wrote:
>> 
>> On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote:
>>> 
>>>   Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary,
>>>   Yoav> while the others are the restrictive. While the sever (and
>>>   Yoav> domain owner) can't dictate client policy, they should be able
>>>   Yoav> to indicate whether the Certificate (TA or EE) that's in the
>>>   Yoav> TLSA record is supposed to be validatable or not. The client
>>>   Yoav> (relying party) may have a policy to ignore records that push
>>>   Yoav> a non-valid certificate, but if you're going to publish a
>>>   Yoav> record with a certificate that you have just issued using
>>>   Yoav> openssl on your laptop and expires in 1975, the TLSA record
>>>   Yoav> had better reflect that this certificate is just a container
>>>   Yoav> for a public key, not something you can chain and validate. 
>>> 
>>> So, you are arguing that the protocol must signal the intent.
>> 
>> It's not strictly speaking "intent". It's more of an attribute.
>> Either "this certificate of mine, you can use your regular validation
>> techniques" or "this certificate of mine, just make sure you get this one."
> 
> I also think that leaving it up to the client to make assumptions
> about what type of TLS Server cert validation scheme should be used
> is likely going to result in a lot of bad decisions among the
> implementors.
> 
> If the TLSA record includes the information on the intended validation
> scheme for this information, then there is going to be more consistency
> among the implementations.
> 
> When a particular HTML page renders without apparent problems in
> one particular web browser, this is no proof that the page is correctly
> formed and can be expected to render without problems in other
> browsers as well.

Just as long as we avoid the rat-hole of calling it "policy"