Subject: [dane] -12

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 18:56:24 -0700

1. Section 1.1 - This text needs to be updated to reflect other changes in
the document.

Tell me what a certificate association is before you talk about what is
built from.

A certificate association is formed from a piece of information identifying
a certificate with the domain name where the data is found.  The data used
to identify the certificate consists of ...'

2. Section 2.1 - typo - /o one octet/a one octet/

Section 2.1.1 - I think that you need to be clearer about which certificate
needs to pass validation, it is not the certificate that is found from the
association record but rather the one presented by TLS.  This is not clear,
esp in the cases where the word certificate is used twice in the sentence to
refer to different certificates.

3. Section 2.1.4  - I think that the field should be named "The Association
Data Field" as in many cases there is not a certificate in this field
OLD: 
The "certificate for association".  This is the bytes containing the
   full certificate, SubjectPublicKeyInfo or the hash of the associated
   certificate or SubjectPublicKeyInfo.  This is the certificate or the
   hash of the certificate itself, not of the TLS ASN.1 Certificate
   object.

NEW:
The "association data" to be matched.  The field contains the bytes to be
matched or the hash of the bytes to be matched.  The source of the data to
be matched is controlled by the Matching Type field.  The data refers to the
certificate in the association, not to the TLS ASN.1 Certificate object.

4. I am a layman in regards to DNS terminology.  Does the term domain name
refer to leafs as well as nodes, i.e. is www.example.com considered to be a
domain name?  I get confused since registering domain names would not get
you that name but it could be slopping thinking on my part.

5.  A forward reference to section 4 from section 2.1.1 would probably be
helpful so that you know there is more detail later

6.  I think that the text in section 4.3 should be expanded slightly to
identify the self-issued certificate case as well.  I was going to go to the
TLS document and grab the text used there and find that although we have
been assured that a self-issued certificate is allowed in TLS that there not
only is no documentation on it but it says that it MAY be omitted since it
is self-issued.  Perhaps we should get some clarifying terminology from the
TLS group before pursuing this.

7.  I would request that you expand the text in section 5 regarding
combination to the following

Combination --- No support is provided to combine two TLSA certificate
associations in a single operation.  Support exists for having multiple TLSA
certificate associations that are treated independently.

8.  In the code section I might suggest

     // pass PKIX validation using TLSA record as trust anchor
     if (R.certUsage == 2) {
       for each PKIX validation chain H  {
         if (C passes PKIX validation in H) {
	T = the trust anchor in H;
	if (Match(matchingType, Select(selectorType, T), R) {
       	    accept the TLS connection
	}
         }
       }
     }

Jim

---

From: Martin Rex <[email-masked]>
Date: Wed, 5 Oct 2011 03:42:45 +0200 (MEST)

> TLS group before pursuing this.

Nope.  In TLS, the server/end-entity certificate may not be omitted from
the Certificate handshake message.  The "MAY be omitted" applies only
to a self-signed RootCA certificate at the end of the path.

  http://tools.ietf.org/html/rfc2246#page-39

  The sender's certificate must come first in the list.

The semantics of a Certificate handshake message with no Certificates
is "Sender has no certificate" is limited to the client's Certificate
handshake message.

>        	    accept the TLS connection

As I tried to explain in a previous message, this is backwards
to how PKIX validation works and therefore does not compute.

When trying to match for certUsage==2, one has to first search
the certificate chain provided by the server for a match to
the TLSA records, and when a match is found, then
   1) if the TLSA match is on the server cert itself (the first cert from
      the server's Certificate handshake message), then *NO*
      PKIX certificate path validation can be performed.
   2) if the TLSA match is on a later cert from the server's Certificate
      handshake message, then one has to call the PKIX certificate
      path validation function, providing the two required input
      parameters to this function
        - the cert that matched the TLSA record as trust anchor
        - the certs from the Server's Certificate handshake message
          up to (but not including) the cert that matched the TLSA record.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 20:46:30 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Tuesday, October 04, 2011 6:43 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dane] -12
> 
> Jim Schaad wrote:
> >
> > 6.  I think that the text in section 4.3 should be expanded slightly
> > to identify the self-issued certificate case as well.  I was going to
> > go to the TLS document and grab the text used there and find that
> > although we have been assured that a self-issued certificate is
> > allowed in TLS that there not only is no documentation on it but it
> > says that it MAY be omitted since it is self-issued.  Perhaps we
> > should get some clarifying terminology from the TLS group before
pursuing
> this.
the
> Certificate handshake message.  The "MAY be omitted" applies only to a
self-
> signed RootCA certificate at the end of the path.
> 
> The semantics of a Certificate handshake message with no Certificates is
> "Sender has no certificate" is limited to the client's Certificate
handshake
> message.

Actually a better argument is the fact that some bytes are required in the
list - so that the cert could not be omitted anyway.  I had too loose of a
reading of the text - you are correct.

> As I tried to explain in a previous message, this is backwards to how PKIX
> validation works and therefore does not compute.
> 
> When trying to match for certUsage==2, one has to first search the
certificate
> chain provided by the server for a match to the TLSA records, and when a
> match is found, then

How this works depends on what sort of implementation of the code one has.
If one is in a situation where there is only one certificate in the chain
and it is the trust anchor, then it would be more accurate to say that PKIX
validation has undefined behavior so one could define this as either passing
or failing depending on how your code is written.  My PKIX validator says
that if the certificate is the same as a trust anchor the validation code
passes without performing any actions.

I have also ignored the question of how paths are constructed as well since
that is not germane to the issue at hand.

This code is descriptive not proscriptive so anything that gives an
equivalent answer would be considered to be acceptable.

Jim

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 5 Oct 2011 16:21:56 +0200 (MEST)

Jim Schaad wrote:
> 
> Martin Rex wrote:
> > 
> > In TLS, the server/end-entity certificate may not be omitted from the
> > self-signed RootCA certificate at the end of the path.
> > 

The certificate_list in TLSv1.0 can be empty (denoted by the lower boundary
of the vector), but that is limited to the "sender has no certificate"
semantics for the ClientCertificate handshake message that was newly added
to TLSv1.0.

Compare to SSLv3
   http://tools.ietf.org/html/rfc6101#section-5.6.2
where no "empty" Certificate handshake message exists -- in SSLv3
the client signaled "sender has no certificate" with a warning-level
SSL alert "no_certificate" instead.
   http://tools.ietf.org/html/rfc6101#section-5.6.6

> > certificate chain provided by the server for a match to the TLSA
> >records, and when a match is found, then

While this might be what your implementation does, it is not what a
"PKIX validator" (conforming to rfc3280/rfc5280) is specified to do.

> that is not germane to the issue at hand.

In theory, theory and practice are the same, in practice they differ
substantially.

TLS is explicitly specified to convey a well-formed and complete
certificate path through the Certificate handshake message,
so in theory, the only preprocessing that is necessary in order
to call an rfc5280 section 6.1ff. PKIX certificate path validation
for DANE usage type "2" is to chop of certs at the end of the path.

In practice, a lot certificate path validation functions include
the capability to ignore extra/unneded certificates that go beyond
the certificate that is provided as "trust anchor", which is more
than the original "X.509 certificate path validation function"
calls for by specifying that self-signed certs in the path
are ignroed.

> equivalent answer would be considered to be acceptable.

Although I do agree that most implementations of PKI and certificate path
validation functions likely go beyond what rfc3280/rfc5280 section 6.1ff.
specifies, I still believe that all specifications that refer to PKIX
certificate path validation should be consistent with what PKIX
certificate path validation actually specifies (including the required
and exact input parameters to the path validation function).

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Oct 2011 17:20:07 -0700

Sorry for the delay in getting back to you, and thanks for the review. We'll make these changes in the -13, except as noted below.

> you that name but it could be slopping thinking on my part.

"Domain name" means any name in the DNS hierarchy (probably excluding the nameless root).

> TLS group before pursuing this.

The issue of self-issued certificates is being dealt with in the PKIX WG. We need to wait for the conclusion of that discussion.

>      	    accept the TLS connection

I would want to hear from more folks on this. Martin doesn't like the change, and I think our current pseudocode is accurate.

--Paul Hoffman