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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 13 Feb 2011 23:36:28 +0200

Hi Paul,

please see my response below.

Thanks,
	Yaron

> Date: Sun, 13 Feb 2011 08:59:49 -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/11/11 12:40 PM, Yaron Sheffer wrote:
>> 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.
>
> Please re-read section 6.1.1, particularly element (d) there. Your list
> would fall under (d)(4), which is explicitly listed as optional.
>
I believe this characterization is incorrect. 6.1.1.d.4 discusses 
"public key parameters", which are never defined, but seem to refer to 
actual mathematical parameters of the public key, such as algebraic 
groups, generators etc.

I agree that RFC 5280 is essentially silent about the semantics of 
anything in the TA, when it is provided as a self-signed cert. I would 
appear that the authors of RFC 2459 (back in Jan. 1999) considered the 
self-signed cert that wraps the public key as extraneous. However if a 
modern browser were to ignore the validity period on a Verisign 
top-level CA cert, this would be considered a bug.

>> 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.
>
> There are two problems here. You said:
>
>>>> 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.
>
> 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.

I accept that I confused the processing of EE certs with trust anchors. 
But it would seem that modern practice diverges *a lot* from RFC 5280. 
Moreover, people expect certain behavior from TLS self-signed CA certs 
and we should ensure that such behavior (to the extent it is formally 
specified) is also followed by a conformant DANE RP.

All the items on my list can appear in intermediate certs, and sometimes 
do (with the possible exception of name constraints). So applications 
should behave sanely when presented with them.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Feb 2011 22:16:06 +0000

Hiya,

> actual mathematical parameters of the public key, such as algebraic

Right.

> anything in the TA, 

Right.

> when it is provided as a self-signed cert. 

Or in any other way. 5280 just says TA info "may" be in an SSC
and that was quite deliberate. (Smartcards for example didn't
use SSC's much - they disliked those extra useless signature
bits as I recall:-)

PKIX did a bunch more on this with TAMP afterwards as well so
there's plenty of mail and RFC text to argue from.

>From my personal p-o-v, (i.e. no hats) I don't see that DANE's
handing of additional TA inputs  (compared to the things 5280
needs) can be driven by 5280 since 5280 is silent on the topic.
Equally, I don't think the (sometimes not so great) browser
implementations of TA handling ought drive everything DANE
does. So DANE should decide what it wants basically. Treat the
info as a 5280 TA, as a bare key, as some kind of TAMP-like
thing, whatever meets the use cases, and can be secure enough.

S.

> I would
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Feb 2011 15:46:51 -0800

> actual mathematical parameters of the public key, such as algebraic

As you say, they are not defined, so you could be right. However, that 
doesn't make much sense because I would doubt that needed parameters 
such as those would be optional; this is why I assumed that they were 
parameters such as "how long is this key good for" and "what can this 
key be used for" and so on.

> self-signed cert that wraps the public key as extraneous.

I'm glad we agree here.

> However if a

...by you, but not by the spec.

> I accept that I confused the processing of EE certs with trust anchors.

Good.

> But it would seem that modern practice diverges *a lot* from RFC 5280.

That might be true, but I'm not sure how it is relevant to what we make 
as MUST-level considerations in the TLSA document.

> specified) is also followed by a conformant DANE RP.

We disagree here: just because people might expect something that is 
wrong, I do not see why institutionalizing it makes it right.

> should behave sanely when presented with them.

Fully agree. In an intermediate certificate in a chain from a trust 
anchor, the full PKIX non-TA semantics need to be used. That's not what 
we are talking about in this thread, of course.

---

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

> thing, whatever meets the use cases, and can be secure enough.

This seems like a good way to dissect the topic, except that there is 
obvious disagreement about what a "5280 TA" is. I would say that 
treating the TLSA info as a bare key is the clearest statement.