Subject: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

From: "dane issue tracker" <[email-masked]>
Date: Sun, 20 Feb 2011 19:59:26 -0000

#20: Change the format of the two fields to have fewer certificate types

 To reduce the chance that someone could give a certificate type that
 doesn't match the hash type, change the fields as follows:

 o  A one-octet value, called "certificate type", specifying the
    provided association that will be used to match the target
    certificate.  This will be an IANA registry in order to make it
    easier to add additional certificate types in the future.  The
    types defined in this document are:

       1 -- An end-entity certificate

       2 -- A certification authority's certificate

 o  A one-octet value, called "reference type", specifying how the
    certificate association is presented.  This value is defined in a
    new IANA registry.  The types defined in this document are:

       0 -- Full certificate in DER encoding

       1 -- SHA-1 hash of the certificate in DER encoding

       2 -- SHA-256 hash of the certificate in DER encoding

       3 -- SHA-384 hash of the certificate in DER encoding

    Using the same hash algorithm as is used in the signature in the
    certificate will make it more likely that the TLS client will
    understand this TLSA data.

-- 
-----------------------------------+----------------------------------------
 Reporter:  paul.hoffman@…         |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:     
Component:  protocol               |     Version:     
 Severity:  -                      |    Keywords:     
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/20>
dane <http://tools.ietf.org/dane/>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Feb 2011 09:15:05 +1300

>       2 -- A certification authority's certificate

What's the thinking behind this?  If I'm looking up a cert by a unique key,
the hash value, then anything else is superfluous.  How, as an implementer, am
I supposed to use the certificate type?

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Feb 2011 12:32:39 -0800

> I supposed to use the certificate type?

Unless we mandate one or more hash functions, we cannot assume a hash 
value. Once we mandate one or more hash functions, getting them changed 
later will cause a gap interoperability. Allowing the full cert as one 
of the identity types allows DNS admins who want to assure maximum 
interop to be able to identify the certificates, at the cost of larger 
DNS responses.

---

From: Scott Schmit <[email-masked]>
Date: Mon, 21 Feb 2011 01:26:29 -0500

On Sun, Feb 20, 2011 at 12:32:39PM -0800, Paul Hoffman wrote keyassure:
> Unless we mandate one or more hash functions, we cannot assume a
> hash value. Once we mandate one or more hash functions, getting them
> changed later will cause a gap interoperability. Allowing the full
> cert as one of the identity types allows DNS admins who want to
> assure maximum interop to be able to identify the certificates, at
> the cost of larger DNS responses.

I don't think that was the question that Peter was asking. Instead, he
was asking how the certificate type is used.

dane-04 section 2.3 specifies that for EE certs, the cert/hash is
required to match the first cert in the chain. For CA certs, the
cert/hash is required to match anything but the first cert in the chain.

The draft doesn't explicitly say what use cases these cover, but
presumably the purpose of the EE cert case is to simply state what cert
the server is expected to use (and allow for the simple case: a
self-signed cert).

In the CA cert case, the TLSA record asserts what CA cert is expected to
validate the EE cert. This can be done to maintain compatibility to
non-DANE clients while excluding other CAs from being able to issue
false certificates for DANE clients. Alternatively, it can provide trust
to an internal CA in a way not unlike the EE cert case.

Another question Peter is probably asking is "who cares?" Does the TLSA
record really need to say one way or another?

The certificate already identifies if it's a CA or EE certificate (or
even both, but the chain sent by the TLS server will say how it's being
used). So, in the case of a certificate, this is yet another case where
the data in the DNS could contradict the data in the certificate (and
thus is something for us to describe how to handle). And if your choice
of hash algorithm allows an attacker to find a collision and substitute
one for another, you shouldn't be using that algorithm anymore.

On the other hand, a bare key isn't going to make that assertion by
itself (unless you include more pieces of the certificate structure,
which slides you toward "just use certificates and save everybody the
trouble"), unless the TLSA record says. But the more I think about it,
the more I'm not even sure it needs to--if I as an attacker could use
the EE-intended key in a CA cert, I don't need to bother (I have the
key, just use it!) and vice versa. Is there an attack I'm missing?

Another (probably better) use for the cert type field is to distinguish
between X.509 certificate in DER encoding, OpenPGP, bare key, etc. I
think we want adoption of DANE to be quick and widespread, we must
support the first. The others could be added later. To support later
growth, we'd still need the field, even though it would only have one
assigned value (other than private use).

-- 
Scott Schmit

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 07:55:31 -0500

>        2 -- A certification authority's certificate

if we're talking about X.509 certs, this distinction is already expressed
within the cert itself, via the BasicConstraints extension. Not sure 
why one would need to express this cert type in the record as well, 
when a cert (vs. hash) is present).  Even if a cert hash is the 
record content, when the
relying party matches the hash against the cert, the cert will still 
say whether it is an E or a CA cert.  If we put this info here, it 
creates an opportunity
for a mismatch between the two, and a need to describe (and defend) why
one trumps the other.

Steve

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 21 Feb 2011 13:14:20 +0000

On 21 Feb 2011, at 12:55, Stephen Kent wrote:

> within the cert itself, via the BasicConstraints extension. Not sure why one would need to express this cert type in the record as well, when a cert (vs. hash) is present).  Even if a cert hash is the record content, when the
> relying party matches the hash against the cert, the cert will still say whether it is an E or a CA cert.  If we put this info here, it creates an opportunity

To which I reply, hesitantly:

This may be a really stupid comment, but ...
 Will there ever be more than one DANE record at the owner?
 If so, and there are two such records, might one refer to one cert with the other refers to a different cert?
  If that happens, might it be useful for a client to be able to scan the records without processing the certs themselves.
   [e.g. if the client is interested only in end entity certs]

With apologies for the lack of clue ...

all the best,
  Lawrence

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 05:37:19 -0800

There are two sets of issues:

1) To distinguish between different types of X.509v3 cert

2) To distinguish between different types of cert (X.509, SAML, PGP, etc...)

The first is covered by the X.509 spec, the second is not. So either the
spec has to say that it only allows use of X.509 keys or there has to be a
mechanism to allow the client to work out what type of information it is
handling.

On Sun, Feb 20, 2011 at 12:15 PM, Peter Gutmann
<[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 21 Feb 2011 16:03:54 +0200

>    [e.g. if the client is interested only in end entity certs]

("Ceritificate" here means certificate in the sense TLS defines it).

Yes. Some usecases:

- Certificate rollover (to avoid getting into trouble with TTLs)[1].
- Multiple (quad-)A records pointing at different hosts having different keys.
- Multiple certificates (hashes, TLS certificate types, etc...)[2]

[1] This should do the trick:

1) Insert TLSA record for new certificate
2) Wait at least one positive TTL.
3) Change the certificate webserver sends.
4) Remove the old TLSA record.

[2] These certificates can share the key if it is strong enough, because
TLS key usage is certificate format independent (key usage is implicit
in TLS 1.0/1.1, and implicit with extensions to override defaults in
TLS 1.2).

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Feb 2011 08:47:13 -0800

On 2/21/11 4:55 AM, Stephen Kent wrote:
> within the cert itself, via the BasicConstraints extension. Not sure why
> one would need to express this cert type in the record as well, when a
> cert (vs. hash) is present).

Simplicity. If you know you are holding an EE cert, you do this; if you 
know you are holding a CA cert, you do that. If we remove the 
differentiation in TLSA protocol, we force every client to do something 
they don't have to do now, namely to disassemble the cert to determine 
the type. That currently happens in the path processing software, but 
that software is usually a black box to the main TLS software. If we 
eliminate the certificate type differentiation, it has to happen before 
certificate comparison can happen.

> Even if a cert hash is the record content,
> when the
> relying party matches the hash against the cert, the cert will still say
> whether it is an E or a CA cert. If we put this info here, it creates an
> opportunity

Fully agree on the possibility of the mismatch, but in that case the 
TLSA association will fail for everyone and the DNS admin will hear 
about it. The cost of the possibility of mismatch should be weighed 
against the cost of making everyone add new ASN.1 parsing code to look 
for the cA bit in the basicConstraints extension.

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Feb 2011 18:39:13 +0100 (MET)

Stephen Kent wrote:
> when a cert (vs. hash) is present).

Simplicity and robustness.

When simple public keys for servers are to be used with DANE, these
will usually be X.509v1 certificates, which do not contain
a BasicConstraints extension.  Based on X.509 itself, a certificate
without the BasisConstraints extension "cA=FALSE" is _not_ limited
to be an end-entity cert.  The requirement that a CA certificate
is required to contain a "BasicConstraints cA=TRUE" marked critical
extension is specific to PKIX (rfc-5280 and predecessors).

But the CA-certificate conveyed through dane is more of a trust anchor
than a CA to an rfc5280 path validation, so it may be difficult to
enforce the Basic Constraints attribute check.

Keep in mind that even "renowned" commercial CAs get this wrong !!
My Firefox 3.5.13 contains a Trust Anchor called
"Entrust.net Certification Authority (2048)" that does not carry
a BasicConstraints extension.

I know that Entrust is (or has been) issuing Web Server certificates
under this TA, because I received a few customer problems where our
software rejected server credentials under this rootCA due to its lack
of the BasicConstraints extension in an X.509v3(!) certificate.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 17:13:54 -0500

At 5:37 AM -0800 2/21/11, Phillip Hallam-Baker wrote:
>The first is covered by the X.509 spec, the second is not. So either 
>the spec has to say that it only allows use of X.509 keys or there 
>has to be a mechanism to allow the client to work out what type of 
>information it is handling.

For a non-X.59 cert that does not express CA vs. EE attribute this 
marking might be useful. What types of certs are benign considered 
that have these attributes but do not encode it internally?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 17:16:11 -0500

At 8:47 AM -0800 2/21/11, Paul Hoffman wrote:
>Simplicity. If you know you are holding an EE cert, you do this; if 
>you know you are holding a CA cert, you do that. If we remove the 
>differentiation in TLSA protocol, we force every client to do 
>something they don't have to do now, namely to disassemble the cert 
>to determine the type. That currently happens in the path processing 
>software, but that software is usually a black box to the main TLS 
>software. If we eliminate the certificate type differentiation, it 
>has to happen before certificate comparison can happen.

Thanks.  That's a good rationale.
>against the cost of making everyone add new ASN.1 parsing code to 
>look for the cA bit in the basicConstraints extension.

The association will fail because we have decided which marking takes 
precedence?

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Feb 2011 15:17:14 -0800

On 2/21/11 2:16 PM, Stephen Kent wrote:
>> something they don't have to do now, namely to disassemble the cert to
>> determine the type. That currently happens in the path processing
>> software. If we eliminate the certificate type differentiation, it has
>> to happen before certificate comparison can happen.
>

No, because the cert from TLSA won't match the cert in TLS. If the TLSA 
cert is an EE cert that is erroneously marked as a CA cert, the TLS 
client will try to match it against a trust anchor in the chain after 
the cert offered by the TLS server and won't find it. If the TLSA cert 
is a CA cert that is erroneously marked as an EE cert, the TLS server 
won't have the private key for that CA.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 17:49:41 -0800

On Mon, Feb 21, 2011 at 3:17 PM, Paul Hoffman <[email-masked]> wrote:
> cert is an EE cert that is erroneously marked as a CA cert, the TLS client
> will try to match it against a trust anchor in the chain after the cert
> offered by the TLS server and won't find it. If the TLSA cert is a CA cert
> that is erroneously marked as an EE cert, the TLS server won't have the
> private key for that CA.

I think this is OK and that Steve's concern is not going to be realized
because there is going to be a very high probability that most if not all
code is going to recognize this distinction.

This could be a problem if there was a risk that only a small number of
clients would make the check in this fashion; In practice admins tend to use
trial and error as their basis for configuration. But I think there should
be a high probability that this is going to be rejected by most clients.

We should probably make it a MUST though. For a cert to be accepted as a
signing cert it has to be marked as such in BOTH places. For a cert to be
accepted as EE it has to be marked as such in the DNS.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 20:08:22 -0500

>a BasicConstraints extension.

Why would they be v1 certs?

We know that using v1 certs introduced vulnerabilities in browsers, 
e.g., it enabled EEs to issue subordinate certs.

I thought that browsers were fixed and that most commercial CAs used 
v3 certs now, since v3 has been the current standard for a very long 
time. I'm surprised to hear that Entrust still has a v1 cert out 
there, but it may be that it has been around for a very long time and 
they don't want to pay to replace it.

Anyway, why should we think in terms of v1 certs for servers at this 
point in time? Do you statistics that suggest that most (many?) web 
sites are using v1 certs?  if we're talking about certs that sites 
can issue themselves (vs. buying certs), then there is a lot of v3 
cert CA SW available.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 18:54:52 -0800

On Mon, Feb 21, 2011 at 5:08 PM, Stephen Kent <[email-masked]> wrote:

> We know that using v1 certs introduced vulnerabilities in browsers, e.g.,
> it enabled EEs to issue subordinate certs.
>
> I thought that browsers were fixed and that most commercial CAs used v3
> certs now, since v3 has been the current standard for a very long time. I'm
> surprised to hear that Entrust still has a v1 cert out there, but it may be
> that it has been around for a very long time and they don't want to pay to
> replace it.
>
> Anyway, why should we think in terms of v1 certs for servers at this point
> in time? Do you statistics that suggest that most (many?) web sites are
> using v1 certs?  if we're talking about certs that sites can issue
> themselves (vs. buying certs), then there is a lot of v3 cert CA SW
> available.

I would be surprised if Entrust had issued a v1 cert recently as a CA. But
there are other ways that the same situation can emerge.

One is that some of the earliest root keys have been re-certified. I am not
aware that any of the current roots embedded in current browsers was still
v1 and it would seem rather odd if it was due to the issues that Steve
mentions above. But that does not mean that you can't or shouldn't be able
to form a valid trust chain to one of the old v1 roots.

If we are comparing like with like, we are talking about current software
that is being actively maintained and has a current root store.

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Feb 2011 19:26:14 +0100 (MET)

> e.g., it enabled EEs to issue subordinate certs.

Getting all X.509v3 attributes into a usable consistent fashion is
pretty difficult -- and a complete waste if they're supposed to be
entirely ignored.

Also self-signed X.509v3 End-Entity certs don't really exist.
I know that self-signed X.509v1 certs work fine with TLS implementations.
I wouldn't know which exact attributes I would have to add to a
self-signed X.509v3 certificate in order to not run into interop
problems.  E.g. a KeyUsage constraint _without_ keyCertSign in an
X.509v3 self-signed certificate would obviously be self-contradictory.

> there

That Entrust cert is a v3 cert -- which is why our software rejects it.
But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...)
did not complain about this malformed X.509v3 TrustAnchor, because they're
shipping it as trust anchor.

> can issue themselves (vs. buying certs), then there is a lot of v3 

selfsigned X.509v1 containers are the X.509 public key bag that
we're looking for for TLSA EE certs -- those where NO PKIX certificate
path validation is to be performed on the certificate.

-Martin

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 Feb 2011 17:06:21 -0500

Ok, so it sounds to me as though their is consensus for this change /  
text.

Please clearly state if I have misread / misunderstood your views,  
otherwise I'm going to mark it as fixed....

W
On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:

> ----------------------------------- 
> +----------------------------------------
> ----------------------------------- 
> +----------------------------------------
>

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire,  
and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Feb 2011 00:39:06 +0200

On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari wrote:
> Ok, so it sounds to me as though their is consensus for this change
> / text.
> 

> >      3 -- SHA-384 hash of the certificate in DER encoding

What does DER encoding mean for possible future non-ASN.1 certificate
types?

I think it should be done this way:

Certificate type:
      1 -- An end-entity certificate in DER encoding
      2 -- A certification authority's certificate in DER encoding

Reference type:

      0 -- Full certificate
      1 -- SHA-1 hash of the certificate
      2 -- SHA-256 hash of the certificate
      3 -- SHA-384 hash of the certificate

This way it doesn't assume that future certificate types are
DER-encodable. The result will be the same with cert types 1 and 2
anyway.

-Ilari

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 22 Feb 2011 23:43:04 +0100

> DER-encodable. The result will be the same with cert types 1 and 2

+1

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 18:38:20 -0500

> DER-encodable. The result will be the same with cert types 1 and 2

According to the standard, a certificate is not X.509 or PKIX unless DER
encoded, thus it is unnecessary to specify in either case. Thus I propose
simply:

Object type:

Reference type:

     0 -- Full object
     1 -- SHA-1 hash of the object
     2 -- SHA-256 hash of the object
     3 -- SHA-384 hash of the object

I would also like to see some justification for supporting SHA1 in a new
specification. We really want all PKIX compliant code to support SHA2 and
that is going to need to be the must, so what is the value to having SHA1 in
there at all?

I can see choosing values so as not to tread on the DNSSEC hash value
registry, but would prefer to simply specify 'unassigned' than assign a
value to an algorithm we are starting to decommission.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 22 Feb 2011 18:47:33 -0500

> According to the standard, a certificate is not X.509 or PKIX unless DER
encoded, thus it is unnecessary to specify in either case.

True enough but there are plenty of base64 encoded certs kicking around.
Clarifying the hash is calculated over the DER encoded certificate seems
inoffensive enough while making a useful distinction.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 19:20:17 -0500

Then we should specify BINARY as in the MIME specification.

Specifying DER encoding is going to lead some twits to try re-DER encoding.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Feb 2011 19:51:44 -0500 (EST)

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> I would also like to see some justification for supporting SHA1 in a new specification. We really want all
> PKIX compliant code to support SHA2 and that is going to need to be the must, so what is the value to having
> SHA1 in there at all?

The reasoning at section 2.2 states:

 	Using the same hash algorithm as is used in
 	the signature in the certificate will make it more likely that the
 	TLS client will understand this TLSA data.

I think a lot (most?) certificates still use SHA1?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Feb 2011 19:52:44 -0500 (EST)

On Tue, 22 Feb 2011, Carl Wallace wrote:

> > According to the standard, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnecessary to
> specify in either case. 
> 
> True enough but there are plenty of base64 encoded certs kicking around.  Clarifying the hash is calculated
> over the DER encoded certificate seems inoffensive enough while making a useful distinction.  

There is also the OpenPGP container I believe? That might be called "certificate" as well?

Why are not calling it "PKIX certificate" to avoid confusion?

Paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 02:07:57 -0500

>pretty difficult -- and a complete waste if they're supposed to be

I agree, but that seems orthogonal to what I proposed, i.e., a profile
for certs that would be stored in TLSA records.

>Also self-signed X.509v3 End-Entity certs don't really exist.

I agree that if the cert is self-signed, it should, be a CA cert based
on fundamental X.509/PKIX rules, but if an SS cert is a TA package, this
is a bit less clear.

>X.509v3 self-signed certificate would obviously be self-contradictory.

because a self-signed cert used as a TA pkg is special, it's hard to argue what
is required.

>That Entrust cert is a v3 cert -- which is why our software rejects it.

I (and I think some others) got the opposite impression from your 
message.  Nevermind.

>shipping it as trust anchor.

I can believe that, because if you view it as a TA package, then there are
no hard and fast rules about what needs to be verified.

>path validation is to be performed on the certificate.

You really can't perform path validation on an SS cert, because there 
is no path :-). The issue is what other cert validation checks one 
should perform, and what use one should make of the fields in the 
cert wrt path validation for certs that chain to it.

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 23 Feb 2011 20:28:44 +1300

>There is also the OpenPGP container I believe? That might be called

Yeah, Phil named his key format after the one used by the mechanism that PGP
was diamtrically opposed to (PEM).  How about doing some checking instead of
just inventing things to support your argument?

>Why are not calling it "PKIX certificate" to avoid confusion?

Because it isn't?  At most it's an "X.509 certificate", but "certificate"
pretty much implies that anyway.

Peter.