Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

From: Yaron Sheffer <[email-masked]>
Date: Mon, 17 Jan 2011 22:00:51 +0200

Hi,

I'd like to support Paul W.'s position here, and strongly disagree with 
Paul H. Of course the DNS records are specifying policy. They (in 
conjunction with the DANE RFC) tell the client what it is allowed to do. 
That's policy in my book.

And specifying new RR types where the client MUST ignore everything in 
the cert, other than the public key, is a nice way out of the 
contradiction we've gotten ourselves into by trying to "sort of, but not 
really" reuse PKIX.

An even cleaner way out is to specify exactly what fields MUST and MUST 
NOT exist in the cert, and retain the PKIX semantics for all fields.

It would have been even cleaner to use raw RSA keys instead of 
self-signed certs, but I don't know whether they would be usable in TLS.

Thanks,
     Yaron

Date: Mon, 17 Jan 2011 08:10:18 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] Possible fix for pkix/dane certificate
>     disagreement
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/17/11 7:11 AM, Paul Wouters wrote:
> >
> > DANE is an alternative for PKIX.
> >
> > The important issue here is can someone use both or not, and can someone
> > migrate from one to the other. DANE should not be limited by PKIX, just
> > like PKIX should not be limited by DANE. But we have had this discussion
> > a few times already.
> >
> > My concern is for example with the regularly seen expired 
> certificates. I
> > forsee people, especially those using self signed certificates, to
> > generate TLSA records and forget about their certificate's expiry date.
> >
> > I think there is real value in ignoring all certificate properties. 
> But we
> > could decide on making such a TLSA record have its own "certificate 
> type".
> >
> > eg, we could add type 5/6 to section 2 of the DANE draft:
> >
> > 5 Hash of a public key taken from an end-entity certificate. All PKIX
> > elements are specifically ignored.
> >
> > 6 Full public key taken from an end-entity certificate. All PKIX
> > elements are specifically ignored.
>
> I agree that we should nail down in the spec whether PKIX information
> other than the key itself should be paid attention to in end-entity
> certificates gotten through TLSA. I disagree that we want to have two
> semantics based on different values in the TLSA record. Doing so says
> that the server gets to tell the client what security policy the client
> should use.
>
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 12:28:27 -0800

On 1/17/11 12:00 PM, Yaron Sheffer wrote:
> Paul H.

Just to be clear (because people are changing views as we discuss), you 
are supporting having some end-entity certificate types that are labeled 
as "ignore everything other than the key" and some end-entity 
certificate types that are labeled as "treat all PKIX information as you 
would if you had not gotten the cert from TLSA", yes? I'm not fond of 
that because I think host admins will make the wrong choice, but it is a 
tenable solution.

> Of course the DNS records are specifying policy. They (in

But that's now what Paul W suggested: he had it as a suggestion, not 
what the client is allowed to do. That's what I objected to.

> contradiction we've gotten ourselves into by trying to "sort of, but not

Thus, we fully agree.

> NOT exist in the cert, and retain the PKIX semantics for all fields.

Thus, we fully agree.

> self-signed certs, but I don't know whether they would be usable in TLS.

It is easy to find out by looking in the TLS specification. They are not.