Subject: [dane] #37: Additive assertion of server certificate

From: "dane issue tracker" <[email-masked]>
Date: Wed, 28 Sep 2011 03:21:44 -0000

#37: Additive assertion of server certificate

 In the refactoring of the certificate usages in draft-ietf-dane-
 protocol-11, we lost the ability to make an additive assertion of a server
 certificate (as opposed to a PKIX trust anchor).  A significant fraction
 of the community will be up in arms when they realize this.

-- 
----------------------+----------------------------------------
 Reporter:  matt@…    |      Owner:  draft-ietf-dane-protocol@…
     Type:  defect    |     Status:  new
 Priority:  major     |  Milestone:
Component:  protocol  |    Version:
 Severity:  -         |   Keywords:
----------------------+----------------------------------------

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 23:39:52 -0400

This is a non-issue.  Using the cert as a TA means that you accept any chain starting with that cert.  Since a server cert itself is a chain starting with that cert (of length 1), if you put a server cert in a type 2 record, it Just Works.  

--Richard

On Sep 27, 2011, at 11:21 PM, dane issue tracker wrote:

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

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 27 Sep 2011 20:51:11 -0700

On Tue, 2011-09-27 at 23:39 -0400, Richard L. Barnes wrote:
> This is a non-issue.  Using the cert as a TA means that you accept any
> chain starting with that cert.  Since a server cert itself is a chain
> starting with that cert (of length 1), if you put a server cert in a
> type 2 record, it Just Works.

Really?  What happened to "PKIX doesn't support self-signed server
certs"?  And while I don't foresee any attacks based on presenting a
cert that chains to the designated cert rather than the designated cert
itself, I'd venture that I'm one of many server admins who would feel
much better cutting the complexity of PKIX completely out of the TLS
server authentication process.

-- 
Matt

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Sep 2011 00:01:04 -0400

> certs"?  

PKIX support for self-signed server certs is a little hazy.  On the one hand, any cert that has the keyEncipherment and digitalSignature bits set meets the requirements of RFC 5246, regardless of who issued it.  On the other hand, it is standard PKIX practice to use CA certs only for signing certs, not for other purposes.  

Practically speaking, if PKIX libraries didn't support self-signed server certs, we wouldn't be having this discussion.

> And while I don't foresee any attacks based on presenting a
> itself,

If an attacker can issue himself a cert under your self-signed cert, then you're already pwned.  Nothing DANE can do about this case.

> I'd venture that I'm one of many server admins who would feel

In the self-signed case, PKIX validation reduces to equality of certificates, so there's not really any complexity.

And the idea of "cutting the complexity of PKIX completely out of TLS" is kind of illusory, since as other folks have pointed out, there are other reasons for keeping PKIX around.  So by having a non-PKIX path, you're actually *adding* complexity because you have to switch between the two.

--Richard

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 27 Sep 2011 21:28:16 -0700

On Wed, 2011-09-28 at 00:01 -0400, Richard L. Barnes wrote:
> PKIX support for self-signed server certs is a little hazy.  On the
> one hand, any cert that has the keyEncipherment and digitalSignature
> bits set meets the requirements of RFC 5246, regardless of who issued
> it.  On the other hand, it is standard PKIX practice to use CA certs
> only for signing certs, not for other purposes.  
> 
> Practically speaking, if PKIX libraries didn't support self-signed
> server certs, we wouldn't be having this discussion.

You are confusing PKIX and TLS.  Practically, TLS libraries support
extracting the server public key from any cert, self-signed or not. 
But server authentication for self-signed certs is hardly ever achieved
by the code path of "PKIX validation with a trust anchor" to which DANE
cert usage 2 refers, so one cannot claim that this approach is well
tested for use in DANE.  E.g., in Firefox, one would mark the server
cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt that
marking the cert as CERTDB_TRUSTED_CA would work.

> If an attacker can issue himself a cert under your self-signed cert,
> then you're already pwned.  Nothing DANE can do about this case.

Yes, that's what I was thinking, though I wonder if there are edge cases
where an attacker in possession of an old signature of a weak hash could
graft it onto a certificate or something like that.

> In the self-signed case, PKIX validation reduces to equality of
> certificates, so there's not really any complexity.

Don't be silly.  My concern is not about the happy case (though I would
want to be clear that PKIX validity period, subject name, etc. are not
checked), but that PKIX validation may present significant, avoidable
attack surface.

> And the idea of "cutting the complexity of PKIX completely out of TLS"
> is kind of illusory, since as other folks have pointed out, there are
> other reasons for keeping PKIX around.  So by having a non-PKIX path,
> you're actually *adding* complexity because you have to switch between
> the two.

That's a pretty skewed interpretation of the facts.  You would rather
have a complex code path taken 100% of the time than a switch between a
trivially simple path (say) 50% of the time and a complex path the other
50%?

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 27 Sep 2011 21:39:21 -0700

I forgot one point...

On Wed, 2011-09-28 at 00:01 -0400, Richard L. Barnes wrote:
> other reasons for keeping PKIX around.

That's pretty vague.  Of course clients need a PKIX library to process
the cert usages that involve PKIX.  But if clients connect to
https://mattmccutchen.net, which has a TLSA RRset consisting of a single
server cert association that is both additive and restrictive, what
reason is there to involve PKIX in that process?

-- 
Matt

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Sep 2011 07:42:02 -0400

Responses inline.

> marking the cert as CERTDB_TRUSTED_CA would work.

I'm not confusing PKIX and TLS.  The two are intertwined in the notion of a "self-signed server cert".

A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC that mark 

> checked), but that PKIX validation may present significant, avoidable

Unless you can document some details of the attack you're proposing above, I'm not really convinced that there's any additional attack surface here.

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 28 Sep 2011 08:45:48 -0700

> A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC that mark 

Please finish?

> Unless you can document some details of the attack you're proposing
> above, I'm not really convinced that there's any additional attack
> surface here.

The attack was just a thought; Martin Rex would probably have a better
idea if such a thing might be possible.  My greater concern is just
about calling such a large piece of code: it might have memory safety
vulnerabilities, or a bug where some bizarre combination of cert
extensions can trigger a different path construction mode where it uses
the default trust anchor set instead of the one specified for the
operation, or it might simply pull intermediate certs from AIA when you
would rather it didn't make arbitrary HTTP requests during the server
authentication process.

These issues are all unlikely or of secondary importance, but they are
so easy to avoid by adding cert usage 3: "Exact certificate (or
SubjectPublicKeyInfo) asserted to be that of the authentic TLS server".
I would be surprised if WG consensus were against doing this.  Certainly
WG consensus was not established to remove the functionality in
draft-ietf-dane-protocol-11.

-- 
Matt

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Sep 2011 12:40:00 -0400

>> A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC that mark 

Sorry, emailing before coffee.  I was going to say that IIRC, the CERTDB_TRUSTED and CERTDB_TRUSTED_CA marks apply across all domains, so they're not constrained in the same way as a type 2 TLSA record is to apply to a single domain only.  But I might be wrong about that, in which case, it could be very simple for Firefox to implement type 2 certificates by setting CERTDB_TRUSTED_CA with some name constraints. 

> would rather it didn't make arbitrary HTTP requests during the server

You seem to be missing the point that if PKIX libraries are broken, we're all screwed already.  Even though OpenSSL, NSS, and the like have a non-trivial number of bugs, we seem to have gotten by with them for many years now.  The PKIX problems that DANE addresses are all about asserting and limiting CAs, not about software.

Regarding AIA in particular: If you've got a self-signed cert, you can control whether or not there's an AIA extension or not, so that's not an issue.  If you've got a cert signed by a third-party, why would you not expect someone to actually validate it?  If you want to stop normal validation, just use a self-signed cert.

Please be concrete about the risk you're trying to address instead of just waving your hands about complexity.

> Certainly

There is WG consensus on the current approach, in the sense that the usage values in -11 map directly to the use cases in the use case document.

--Richard

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2011 19:27:03 +0200 (MEST)

Matt McCutchen wrote:
> Richard L. Barnes wrote:

Personally, I would prefer if TLSA records were clearly seperated
in whether they are supposed to validate under the existing TLS X.509 PKI,
i.e. verified against existing TAs from the TLS X.509 PKI,

or whether they originate from DNS, and their trust is based only
and entirely on DNSSEC.

Feeding a self-signed server certificate to X.509 certificate path
validation currently results in undefined behaviour with respect to
specifications and implementation defined behaviour with respect to
the installed base.

X.509 specifies, that all self-signed certificates in the (prospective)
certification path processed by the certificate path validation algorithm
are to be (unconditionally) ignored.  Taken literally, there could be
arbitrary numbers of completely unrelated self-signed certificates in
the (prospective) certification path, and path validation conforming
to X.509-2008 would mean that they all get ignored -- with the result
that path validation ends up with an empty path and can not verify
anything at all.

PKIX (rfc3280/5280) is written in a slightly different fashion and
assumes that PKIX certificate path validation is simply not called with
any self-signed certificates still present in the (prospective) certification
path ("deus ex machina") and the PKIX algorithm for processing the
(prospective) certificate path lacks the X.509 provision ignore
self-signed certs.

So neither provides a real answer to the question of how to
process self-signed End Entity certificates.  non-CA self-signed X.509v1
certs and non-CA self-signed X.509v3 certs with BasicConstraints "cA=TRUE"
seem(!) to work with many TLS implementations when passed as both,
trust anchor and within the prospective certification path, usually
because the TA cert can be used to verify the signature on the path
certificate according to the certificate processing rules.

However, non-CA self-signed X.509v3 certs without BasicConstraints
or with empty BasicConstraints (equals to cA=FALSE in ASN.1 DER)
may not work in that usage scenario for some implementations, in case the
PKIX implementation honours (self-imposed) attributes in TA certs
during certificate processing.

-Martin

PS:

(OT)

> idea if such a thing might be possible.

(Ouch.  I probably deserve some level of bad reputation due to my
 occasional bad temper.  ;-)

I really prefer discussions an abstract architecture level, but it turns
out that is difficult (may take a long time) until all participants in 
a discussion are have formed a sufficiently coherent model that one does not
talk past each other at a meta level.  Depicting attacks may sometimes
help to shortcut discussions, but should primarily be seen as indicators
of (potential) problems.  If a specific attack does not, or no longer
work, it does not proof the absence of problems.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Sep 2011 14:01:45 -0400 (EDT)

> draft-ietf-dane-protocol-11.

Plus, the TLS WG suggested to change my draft to use a new cert type
containing just a SubjectPublicKeyInfo, in which case the PKIX cert
contains just the public key, so following the "full PKIX" path
on the client would likely generate all kinds of errors about missing
fields and signatures.

You can't blindly follow the 20 year old path anymore. This new cert type
would also require DNSSEC as it contains no signatures whatsoever.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Sep 2011 11:22:10 -0700

> on the client would likely generate all kinds of errors about missing

Quite true. If you actually move your proposal through the TLS WG or individual submission, and the identifier is just the SubjectPublicKeyInfo, the certificate usage 3 that Matt suggests above would be a completely logical addition.

> would also require DNSSEC as it contains no signatures whatsoever.

Fully agree.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Sep 2011 14:22:43 -0400 (EDT)

> You seem to be missing the point that if PKIX libraries are broken, we're all screwed already.  Even though OpenSSL, NSS, and the like have a non-trivial number of bugs, we seem to have gotten by w…

Can we pleas leave out these kind of arguments. They are just plain wrong.
Because PKIX was broken back in 1995, it lead people to look into
the KEY record which lead to DNSSEC more then 15 years later. Let's put the
myth of "20 years of proven PKIX security" behind us please. It's a really bad
self-sustaining argument. If you really believe this last year saw a "success"
of PKIX, then perhaps we can just agree to disasgree, and all be accomodating
of each other instead of making up arguments about the dangerous "added complexity"
of 1 switch statement in the total PKIX processing code.

RFC-3445 prevented those who were some of the early architects of
DNSSEC to use it as alternative for PKIX, one of the reasons aside from
protecting the DNS to add crypto to DNS. We are now looking at TLSA
records, and it is wrong to again limit people who have no desire for PKIX
in the last 15 years to again be ignored.

> There is WG consensus on the current approach, in the sense that the usage values in -11 map directly to the use cases in the use case document.

And the use-cases document ignored some of our comments and said "deal with those
in the dane protocol document". Make up your mind how to mapping works, don't
change it to suit your needs.

Stop sending the people who want DANE to be usable without PKIX in circles.
We are not telling you to stop using PKIX, so stop telling is we have to
use PKIX.

Or to make it more concrete, define what "PKIX validation" and "PKIX-formatted certificates"
means for a certificate type that just contains a DER encoded subjectPublicKeyInfo, so
that Certificate Usage 2 makes sense and covers the case for using DANE without PKIX
trust anchors.

Is it really that dreadful to give us a single bit you will never want to use?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Sep 2011 11:50:06 -0700

> Is it really that dreadful to give us a single bit you will never want to use?

Some of us *want* to use it, drama aside. My opinion, though, is that it is inappropriate for it to be in the TLSA spec until it can be used in TLS. Until we can say how it is used in TLS in an interoperable fashion, putting it in TLSA is an invitation for confusion and non-interoperable use, probably in an insecure fashion.

FWIW, if TLSA looks like it will be finished before the TLS extension is, I see no problem with the proposed TLS extension document also defining the new TLSA certificate type at the same time. This is sometimes done in other IETF WGs, where one RFC updates multiple IANA registries.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Sep 2011 15:17:30 -0400

> on the client would likely generate all kinds of errors about missing

Note that this would no longer be a "PKIX cert".  It would just be an SPKI.  So since the existing usage types are predicated on certs, you would need new usage types anyway.

--Richard

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 00:22:48 -0700

On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote:
> Some of us *want* to use it, drama aside. My opinion, though, is that
> it is inappropriate for it to be in the TLSA spec until it can be used
> in TLS. Until we can say how it is used in TLS in an interoperable
> fashion, putting it in TLSA is an invitation for confusion and
> non-interoperable use, probably in an insecure fashion.

There are two orthogonal bits; please do not confuse them:

(a) Putative cert usage 3, "exact server credential" additive +
restrictive association.

(b) SubjectPublicKeyInfo selector.

Your objection above is to (b), while ticket #37 is asking for (a).  I
believe Paul Wouters is asking for (a) as well and the mention of
SubjectPublicKeyInfo was incidental.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 00:24:38 -0700

On Wed, 2011-09-28 at 12:40 -0400, Richard L. Barnes wrote:
> Sorry, emailing before coffee.  I was going to say that IIRC, the
> CERTDB_TRUSTED and CERTDB_TRUSTED_CA marks apply across all domains,
> so they're not constrained in the same way as a type 2 TLSA record is
> to apply to a single domain only.

Yes of course, you would need name constraints or (more likely) to use
an alternative set of marks for the single validation operation.  I was
just making the point that CERTDB_TRUSTED and CERTDB_TRUSTED_CA are
different.

-- 
Matt

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 29 Sep 2011 15:49:13 +0200

> SubjectPublicKeyInfo was incidental.

<chair_hat>
I would prefer that you (or Paul) could propose a text to prevent
this kind of confusion and also so WG can vote on the specific
proposal.

This discussion starts to lead nowhere and we are going in circles.
</chair_hat>

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2011 08:50:43 -0700

On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote:

> Your objection above is to (b), while ticket #37 is asking for (a).  

Again: putting words in other people's mouths is really rude. My objection is to (a). (b) is already in the draft, and has been for at least two versions.

> I

That was my impression as well.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 09:39:28 -0700

>>> non-interoperable use, probably in an insecure fashion.
...
>> (a) Putative cert usage 3, "exact server credential" additive +
...
> My objection is to (a).

It is not clear to me what you mean when you say "until [(a)] can be
used in TLS," and therefore I do not understand your objection.  From
my perspective, using (a) in TLS alone is logically impossible,
because there's nowhere to put the constraint that (a) specifies!

Please elaborate.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2011 09:44:49 -0700

> because there's nowhere to put the constraint that (a) specifies!

That's exactly correct. In current TLS, there is no way to use a bare SPKI. Paul Wouters and others have begun work on an extension to TLS that would allow a bare SPKI to be used in TLS as the server's authenticator. When (hopefully not just "if") that extension is standardized, it would make sense for TLSA to have a bare SPKI as a certificate type.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 09:59:04 -0700

On Thu, Sep 29, 2011 at 9:44 AM, Paul Hoffman <[email-masked]> wrote:
> That's exactly correct. In current TLS, there is no way to use a
> bare SPKI. Paul Wouters and others have begun work on an
> extension to TLS that would allow a bare SPKI to be used in
> TLS as the server's authenticator. When (hopefully not just "if")
> that extension is standardized, it would make sense for TLSA
> to have a bare SPKI as a certificate type.

But that's Matt's (b)!  (a) is "accept this end-entity certificate and
no other" in the DANE record, as I understand it, which is independent
of whether bare SPKI is possible, and doesn't make sense to put into
TLS.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2011 10:29:33 -0700

> of whether bare SPKI is possible, and doesn't make sense to put into

I'm not sure what is happening here. (b) is a *matching* rule, not the format of what is in (a). From the draft:

==========
2.1.1.  The Certificate Usage Field

   A one-octet value, called "certificate usage" or just "usage",
   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 usages in the future.  The
   usages defined in this document are:

      0 -- Certificate MUST pass PKIX validation and MUST chain through
      a CA certificate matching the TLSA record

      1 -- Certificate MUST pass PKIX validation and MUST match the TLSA
      record

      2 -- Certificate MUST pass PKIX validation, with any certificate
      matching the TLSA record considered to be a trust anchor for this
      validation

   The three certificate usages defined in this document explicitly only
   apply to PKIX-formatted certificates.  If TLS allows other formats
   later, or if extensions to this protocol are made that accept other
   formats for certificates, those certificates will need their own
   certificate types.

2.1.2.  The Selector Field

   A one-octet value, called "selector", specifying what will be
   matched.  This value is defined in a new IANA registry.  The
   selectors defined in this document are:

      0 -- Full certificate

      1 -- SubjectPublicKeyInfo
==========

In the case of (a), a putative new type 3 might be worded as "<foo> type used as the server's certificate MUST match the TLSA record".

I think I see where some of the confusion may come from. The current text for 2.1.4 says:
==========
2.1.4.  The Certificate for Association Field

   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.
==========
This is incorrect. The second sentence should be "This is the bytes containing the full certificate or the hash of the associated certificate." We'll fix that in the next version of the draft. (And, if Paul's extension to TLS moves faster than TLSA, we can add those back later.)

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Sep 2011 13:55:33 -0400 (EDT)

On Thu, 29 Sep 2011, Paul Hoffman wrote:

[ not sure if my messages are making it to the list, due to mail.ietf.org
insisting on valid reverse for IPv6 ]

>   apply to PKIX-formatted certificates.

I think that "self signed certificates" are "PKIX-formatted certificates",
though I seem some people suggest it is formally not the case. Can
this be clarified in the text? Specifically, if someone is using a self
signed certificate, this part should be clear as to which category such a
certificate falls. This is for those who want a PKIX container for
backwards compatibility, but have no CA for "PKIX validation".

Ideally, I would like to see a new term for "PKIX validation". I think
what is meant is:

a) contains a valid PKIX structure, and
b) contains a valid PKIX signature

Where in case 2) we have for b) "valid self-signed PKIX signature" and in case 0)
we have for b) "valid PKIX signature chain to the CA specified in the TLA record"?

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 11:05:13 -0700

> I'm not sure what is happening here. (b) is a *matching* rule, not the format of what is in (a). From the draft:
[...]

I'm afraid you've only made me more confused.  Part of the problem is
that I don't know what "PKIX validation" is (and this is after
spending an entire day trying to figure it out; I'm not convinced
*anyone* knows what it is), and the other part is that you continue to
appear to be conflating three entirely orthogonal things, only one of
which makes any sense as part of the TLS spec.

Those three things are:-

(x): a TLSA record which restricts the server to precisely one
end-entity public key (using any of the supported reference modes) and
possibly also requires that a DANE-compliant client accept the record
whether or not its in-band signature chain leads to a CA certificate
in the client's trusted root pool.  [This is Matt's (a) as I
understand it, and is not covered by the current draft.]

(y) a TLSA record which matches certificates by their SPKI rather than
their complete contents.  [Matt's (b) aiui, Selector Type 1 in the
current draft.]

(z) an X.509 certificate construct that contains only the
SubjectPublicKeyInfo, not all the rest of the usual gunk. [This is
logically a TLS extension.]

If I understand you at all -- and I'm not sure I do -- you're saying
that DANE can't do (x) without TLS doing (z) first.  But this seems
ridiculous to me: (z) is about the format and contents of the
certificate presented in the TLS handshake, and affects its semantics
only insofar as a (z) cert has no in-band signatures (or does it?);
(x) is purely a question of the semantics *of the TLSA record*, and
can be specified without any reference to the contents or semantics of
the *certificate*.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 11:08:02 -0700

> possibly also requires that a DANE-compliant client accept the record
                                                                 ^^^^^^
I meant to say "accept a matching end-entity certificate" here.

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 21:01:26 +0200 (MEST)

I'm slightly confused about the description of usage (2), because
the description is backwards to how it must be implemented.

In order to call a "PKIX [certificate path] validation" function,
you will need to provide (at least) two input parameters:
   ( I) a (prospective) certification path
   (II) a trust anchor (which may be provide in form of a certificate)

For the PKIX certificate path validation __function__ itself it is
not relevant whether the trust anchor originates from a persistent
local trust anchor store, or whether it has been dynamically determined
--such as through DANE and verified by DNSSEC (or dynamically downloaded
from Microsoft's central trust anchor store, which is what Vista&Win7
will do).

Based on the assumption that Certificate usage (2) above refers to this: 
  http://tools.ietf.org/html/draft-ietf-dane-use-cases-05#section-3.3 
the processing should look like this:

For TLS and the use of DANE for TLS server cert verification,
the TLS client will obtain the server certificate (plus optional
path certificates) from the server's TLS Certificate handshake message.
TLS _requires_ the Server certificate path to be in order (but some
TLS implementations re-sort path certificates on the receiver side
to accomodate occasionally misconfigured servers that use a buggy
TLS implementation which is sending and unordered path.

The DANE client needs search the list/path of certificates conveyed
by the TLS Server in the server's Certificate handshake message
from the end-entity cert (first in the list) to then end of the list
and compare each cert to each of the TLSA records.  When a match
is found and the match is the servers end-entity cert, then no
certificate path validation can be performed for usage (2).

If a match with a TLS record is found on any later certificate in
the list, then this certificate must be provided as "trust anchor"
to the PKIX certificate path validation function, and the server's
certificate path up to, but not including that matching cert,
must be passed as "prospective certification path" input to the
PKIX certificate path validation function.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 29 Sep 2011 23:15:35 -0700

On Thu, 2011-09-29 at 09:44 -0700, Paul Hoffman wrote:
> That's exactly correct. In current TLS, there is no way to use a bare
> SPKI. Paul Wouters and others have begun work on an extension to TLS
> that would allow a bare SPKI to be used in TLS as the server's
> authenticator. When (hopefully not just "if") that extension is
> standardized, it would make sense for TLSA to have a bare SPKI as a
> certificate type.

I don't understand your concern.  (a) is orthogonal to the use of SPKI
for matching.  I will be satisfied if there is some way I can make an
additive and restrictive association of the server credential, like I
have on https://mattmccutchen.net now based on an earlier draft: "accept
the server's X.509 cert if and only if its SHA256 is
D5D73FCEBCBA047528DA062A108DD5A955F9AD8F6F7E1618E5D172DFCB12980E".

-- 
Matt

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Sep 2011 03:53:50 -0400

At 11:05 AM -0700 9/29/11, Zack Weinberg wrote:
>...
>  > I'm not sure what is happening here. (b) is a *matching* rule, 
>not the format of what is in (a). From the draft:
>[...]
>

A reasonable definition for "PKIX validation" is cert path validation
that complies with RFC 5280.

Steve

---

From: Scott Schmit <[email-masked]>
Date: Fri, 30 Sep 2011 07:28:48 -0400

> D5D73FCEBCBA047528DA062A108DD5A955F9AD8F6F7E1618E5D172DFCB12980E".

Why does:

$ORIGIN mattmccutchen.net.
_443._tcp IN TLSA 2 0 1 ( D5D73FCEBCBA047528DA062A108DD5A9
                          55F9AD8F6F7E1618E5D172DFCB12980E )

Not satisfy your statement? Yes, it'll do path validation, but with the
TA set to your EE cert. AIUI, that basically means "accept exactly this
cert, regardless of what other TAs you have." If that's NOT what it
means, that I agree that there's a problem. That said, rereading the
text for usage 2, the wording is wrong:

Which means that if some *other* TA will validate the certificate
recieved, we'll still accept that the association matched. However, in
4.3, it says:

   Certificate usage 2 is used to specify a certificate, or the public
   key of such a certificate, that must be used as a trust anchor when
   validating the end entity certificate given by the server in TLS.
   This usage is sometimes referred to as "domain-issued certificate"
   because it allows for a domain name administrator to issue
   certificates for a domain without involving a third-party CA.

However, "must" isn't in all-caps. I think that certificate usage 2
needs to say this instead, and then all will be ok again (to me):

      2 -- Certificate MUST pass PKIX validation, with any certificate
      matching the TLSA record considered to be the only trust anchor
      to be used for this validation

Hope this helps,

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Sep 2011 08:53:03 -0400

PKIX attempts to maintain a separation between keys that can be used
to sign keys and keys that are not.

This makes a lot of sense, EE keys need to be in environments that are
not well controlled. A cert signing key should not.

Self signed EE certs are not part of the PKIX model. They are part of
the X.509 model but not of PKIX. There is absolutely no point in
checking the signature on a self-signed EE cert. On a CA root the
signature validates the policy constraints (or lack thereof). On a
self-signed EE cert there is no policy.

As a practical matter I much prefer to see a self signed cert NOT have
the cert signing bit enabled. That would be consistent with the
principle of least privilege.

I believe that the reason that PKIX leaves this out is that there was
a consensus to encourage everyone who is managing crypto to divide
their keys between key signing and EE keys.

The administrative realities of Web server management will strongly
favor using a separate self-signed root to create EE keys. That
decouples the Web server crypto management from the DNS side. Doing it
that way will make it harder for people to make mistakes.

But I don't see why folk have this wrapped round their axles as nobody
checks that stuff.

And as for PKIX being 'complex', the world is complex. Don't fool
yourselves into thinking that you are all soo much smarter than the
people who did PKIX. The reason PKIX got complex was that people tried
to make the scheme too simple and then it grew barnacles as necessary
features were retro-fitted.

You are doing exactly the same thing as the PKIX folk did in the same
way and you are completely determined to learn nothing from their
experience.

Designing a PKI is really easy when you start from the assumption that
there is one absolutely trustworthy and incorruptible party who can
provide ground truth and that nobody ever makes administrative
mistakes.

Here we have a process where we are not even allowed to discuss the
real issues that make PKI hard.

The administrative model is precisely the type of thing that you need
to consider now and act on if you want to have a scheme that is
simpler.

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

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 08:43:54 -0700

On Fri, 2011-09-30 at 07:28 -0400, Scott Schmit wrote:
> cert, regardless of what other TAs you have."

Like I said before in this thread, we have to make sure this approach
actually works with the PKIX library, and I would be exposed to any bugs
in the library by which someone could make it think that another cert
chains to mine or any unpleasant effects of the validation process
itself (AIA fetching).

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 23:28:13 -0700

> way and you are completely determined to learn nothing from their

The reason PKIX got complex was that it tried to be everything to
everyone.  There is nothing complex about TLS server authentication: the
domain owner has one or more authentic TLS servers, which may bear equal
or different public keys.  If a list of the public keys (really, their
digests) is published in DNSSEC, then you proceed with the connection if
and only if the public key you were offered is on the list.  Tell me
what I am missing.

> provide ground truth

Yep, and that assumption holds: for IANA DNS names, the IANA hierarchy
is the truth, by definition.  If you don't want to be dependent on that
hierarchy, you need a different namespace.  I'm working on it.

> and that nobody ever makes administrative
> mistakes.

I don't see how DANE is any worse about this than any other system.

-- 
Matt