Subject: [dane] Questions about the current draft (14)

From: Pieter Lexis <[email-masked]>
Date: Thu, 19 Jan 2012 15:04:54 +0100

Hi,

I'm doing a small(4 week) academic research project for my Msc education
Systems and Network Engineering at the University of Amsterdam[0]. I
want to implement a TLSA record creator and a TLSA validator.

The creator is 'done' and generates records naively (i.e. does not check
the CN when Usage 1 is specified etc.)

This validator will:
1. Look up the TLSA record
2. Verify the fields have the correct values
3. Download the certificate(chain) from the host and validate it

I have a few question about the specification, as some things are
unclear to me. I have no extensive knowledge on PKIX/X.509, so these
could stem from ignorance. The questions deal with the creation of the
resource records.

About the Usage field. When the spec talks about '.. chain through to a
CA certificate ..' (usage 0) Does this mean that the CA certificate has
'X509v3 Basic Constraints - CA' and 'X509v3 Key Usage: Key Cert Sign'
set to true, whereas Usage 2 means that at least 'X509v3 Key Usage: Key
Cert Sign' is true?

Next Question: The hex'd (hash of the) certificate in that last field,
is this the DER representation?

Now for the validation:
My first question is about the phrase 'Pass PKIX validation'. Does this
mean 'The certificate (or SubjectPublicKeyInfo) must in a valid format'
(e.g. DER encoded X.509 Certificate) or does it mean 'The certificate
chain must be traversed successfully' or something else.

Thanks in advance and best regards,

Pieter Lexis

0 - https://www.os3.nl/2011-2012/info/start

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 08:35:04 -0800

> set to true, whereas Usage 2 means that at least 'X509v3 Key Usage: Key

There is disagreement on the latter assertion. Self-signed, non-CA PKIX certificates were not envisioned in the original X.509 spec, and different people have different opinions about what they mean and so on. The debate has happened on this list and on the PKIX WG list as well.

> is this the DER representation?

The DER representation. In 2.1.4 (the description of the field), it says:
   The field contains the bytes
   to be matched or the hash of the bytes to be matched.
In 2.2 (the presentation format), it says:
   o  The certificate for association field MUST be represented as a
      string of hexadecimal characters.  Whitespace is allowed within
      the string of hexadecimal characters.
Do not mistake the presentation format for the bits on the wire.

> chain must be traversed successfully' or something else.

The chain must be traversed successfully.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 08:59:37 -0800

Martin Rex pointed out that I was maybe sloppy in my answer to one of the questions.

> Do not mistake the presentation format for the bits on the wire.

If it is a full certificate or a SubjectPublicKeyInfo, both are in DER. A hash does not have a DER representation: it is just the raw bytes of the output of the hash function.

--Paul Hoffman

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 19 Jan 2012 19:08:45 +0100

On 01/19/2012 05:35 PM, Paul Hoffman wrote:
> There is disagreement on the latter assertion. Self-signed, non-CA 
> PKIX certificates were not envisioned in the original X.509 spec, and
> different people have different opinions about what they mean and so
> on. The debate has happened on this list and on the PKIX WG list as
> well.

So basically usage 0 and 2 are the same when verifying? Both must have
the CA constraints set? I want to know to do the verification correctly.

> Do not mistake the presentation format for the bits on the wire.

I won't, thanks. It just was unclear to me how the certificate was
encoded before hashing or converting to hex :-).

> The chain must be traversed successfully.

So if this means that chain must be traversed successfully, why is it
also a requirement for usage 1? As traversing would be a waste of time
if the certificate-to-be-matched matches with the TLSA record? See my
comment in the draft pseudo-code below:

// pass PKIX validation and match EE cert from TLSA
if (R.certUsage == 1) {
 for each PKIX validation chain H {
  if (C passes PKIX validation in H) { /* Why traverse the chain if the
if the only thing that matters is the offered cert itself? */
   if (Match(matchingType, Select(selectorType, C), R)) {
    Finish(2)
   }
  }
 }
}

-- Pieter Lexis

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 10:19:19 -0800

On Jan 19, 2012, at 10:08 AM, Pieter Lexis wrote:

> So basically usage 0 and 2 are the same when verifying?

Type 0 is explicitly for CA certs; type 2 can be for certs that are not CAs but are used as trust anchors.

> Both must have
> the CA constraints set?

Nothing that I said above indicates that, I believe.

> I want to know to do the verification correctly.

Can you point to text in the current draft that indicates that a certificate usage of type 2 must have the CA bit set? It would be useful to us to make this clearer.

> also a requirement for usage 1?

Usage 1 lets you specify an end-entity certificate that is not used as a trust anchor and thus must chain to an existing trust anchor; usage 2 lets you specify an end-entity certificate that is used as a trust anchor.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jan 2012 15:08:53 -0500

> Type 0 is explicitly for CA certs; type 2 can be for certs that are not CAs but are used as trust anchors.

Type 0 also requires PKIX validation, in *addition* to matching the TLSA record.

And just to clarify, type 2 can contain either a CA cert or an EE cert.

> Nothing that I said above indicates that, I believe.

In order for a type 0 assertion to pass PKIX validation, all intermediate certificates in a chain MUST have the CA bit set (by definition).
"
      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)
"
<http://tools.ietf.org/html/rfc5280#section-6.1.3>

--Richard