Subject: Re: [dane] #29: Request new Reference Type - Public Key

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Sep 2011 14:33:43 -0400

On Aug 30, 2011, at 10:43 AM, Warren Kumari wrote:

> 
> On Aug 25, 2011, at 1:57 PM, Jakob Schlyter wrote:
> 
>> On 25 aug 2011, at 17:56, Paul Hoffman wrote:
>> 
>>> The problem we are having in agreeing on terms is that we don't agree to the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. The most vocal proponents of providing an SPKI-not-in-a-cert is no PKIX validation, just exact matching with the end entity certificate or SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able to use SPKI-not-in-a-cert for the kinds of matching that will also involve PKIX validation.
>> 
>> Yes, I forgot about the difference between "require PKIX, match on SPKI" and "ignore PKIX, match on SPKI" - thanks for pointing that out.
>> 
>>> My feeling is that the easiest way out of this is to let the SPKI-not-in-a-cert folks have their own usage type that explicitly says "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA record". Using Jakob's three-part taxonomy, there would be a fourth usage type, and any record with that usage type would have to use "SPKI" and otherwise be ignored as bad; the matching type could be either full or hashed. I don't think that adding a usage type that has to have a specific selector type is that dangerous.
> 
> 
> So, from the "Please indicate a preference" mail (http://www.ietf.org/mail-archive/web/dane/current/msg03272.html) the chairs see consensus for option #3 ('Richard's "very different" proposal').
> 
> This below suggestions is a small revision to that, and I wanted to confirm with the WG that this 3 fields revision is acceptable (just the 3 fields revision, not the "Ignore PKIX, match the TLSA record" bit).
> 
> This feels like a minor cleanup to us, no on has objected on list, and so:
> a: silence will be taken as consent
> b: we will call this at 16:00GMT on September 2nd.

Ok, and we are calling it.

While not universal, the chairs see consensus for this proposal.

We would like to thank the working group for staying focused...

W

> 
> W
> 
>> Given Paul's feedback, my proposal would have three fields (in addition to the association data itself):
>> 
>> usage:
>> - 0. Certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record
>> - 1. Certificate MUST pass PKIX validation and MUST match the TLSA record
>> - 2. Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation
>> - (future) 3. Ignore PKIX, match the TLSA record
>> 
>> selector:
>> - 0. Certificate
>> - 1. SubjectPublicKeyInfo
>> 
>> matching type:
>> - 0. match on exact selected contents
>> - 1. sha-256 hash of selected contents
>> - 2. sha-512 hash of selected contents
>> 
>> 
>> 	jakob
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>> 
>