Subject: Re: [keyassure] dane-04 trust anchors

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Feb 2011 22:40:55 +0200

Hi Paul,

Having read and enjoyed numerous posts by Steve Kent, and skimmed (I 
don't know who might have actually read) Sec. 6.1 of RFC 5280, I still 
don't see your problem with my example list, nor any statement by Kent 
that contradicts it.

All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well 
as even more wondrous beasts. The list is non-normative, serving as an 
example of the kind of validation that RFC 5280 mandates.

Thanks,
	Yaron

> ------------------------------
>
> Message: 2
> Date: Fri, 11 Feb 2011 08:44:09 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] dane-04 trust anchors
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/10/11 11:26 PM, Yaron Sheffer wrote:
>> the new text is a major improvement over the previous version. But it is
>> still missing some necessary guidance.
>>
>> My reference scenario is this: I am a phisher. I'd like to trick
>> BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now
>> I can get a certificate that they will use as a trust anchor, and
>> include whatever I want in it, such as the Subject field, "Your trusted
>> BigBank".
>
> Good scenario.
>
>> Moreover, even if I am the rightful owner, the current text does not
>> allow me to restrict the certificate's use.
>
> Correct. That is on purpose.
>
>> So I propose the following text added:
>>
>> Client treatment of any non-key information included in the trust anchor
>> is a matter of local policy. It is noted that this specification does
>> not mandate that such information be inspected or validated by the
>> domain registrar.
>
> Sounds good to me.
>
>> The client MUST obey any constraints included in the trust anchor,
>> including but not limited to:
>> - Validity period.
>> - Key usage fields.
>> - Path length constraints.
>> - Name constraints.
>> The normal rules of RFC 5280 apply.
>
> As Steve Kent pointed out earlier on the list, the normal rules of RFC
> 5280 for trust anchors disagrees with that list you gave. I would prefer
> to follow the normal rules of RFC 5280 for trust anchors, and not come
> up with ones of our own.
>
>
> ------------------------------
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
> End of keyassure Digest, Vol 7, Issue 24
> ****************************************

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Feb 2011 08:59:49 -0800

> don't see your problem with my example list, nor any statement by Kent

Please re-read section 6.1.1, particularly element (d) there. Your list 
would fall under (d)(4), which is explicitly listed as optional.

>>> The normal rules of RFC 5280 apply.

I don't see now a "MUST obey" can be considered "non-normative".

Further, you are simply incorrect that RFC 5280 mandates any of those, 
given that RFC 5280 says that they are optional.

One of the reasons I am pushing hard against this is that the DANE WG 
should not be propagating myths about PKIX. Another is that some of the 
things that you are trying to mandate are often done poorly in PKIX 
certificate-writing implementations.

You have still not said what the security advantage of following that 
these optional parts of trust anchors is. For example, if a 
certificate-writing application does a typically stupid thing with key 
usage, what security advantage is there to either the TLS server or 
client for the client to not be able to communicate with the server 
securely for that one reason? Note that I am not arguing against 
following PKIX for normal path processing: we are talking about trust 
anchors only here. You seem to confuse the parts of the validation 
algorithm that are for end-entity certificates and intermediate CAs with 
trust anchors, and that is very bad here.