Subject: [dane] #29: Request new Reference Type - Public Key

From: "dane issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2011 23:41:44 -0000

#29: Request new Reference Type - Public Key

 I would like to be able to restrict to a certificate based solely on the
 public key value of the certificate.  This could be used for any of the
 different Certificate Type fields.  EE certificate, Trust Anchor
 certificate and the missing ones for intermediate certificate and pgp
 certificate.

-- 
--------------------------------+-------------------------------------------
 Reporter:  jimsch@…            |       Owner:  draft-ietf-dane-protocol@…             
     Type:  enhancement         |      Status:  new                                    
 Priority:  major               |   Milestone:  milestone1                             
Component:  protocol            |     Version:  1.0                                    
 Severity:  Active WG Document  |    Keywords:                                         
--------------------------------+-------------------------------------------

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Aug 2011 19:42:39 -0700

> certificate and the missing ones for intermediate certificate and pgp

That seems fine. Is there any text in the current draft that prevents you from doing that?

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 20:59:12 -0700

Other than the fact that there is no reference type defined for public key -
no there is no text that would prevent me from doing this.  I could write a
new draft that would define a new reference type of public key and go
forward.

If this proposal is accepted, then the following document changes would need
to be made:

-- Section 2.1.2 would add a new item to the register

      3 -- Public Key expressed as PKIX SubjectPublicKeyInfo
(Note that the format would be under some debate for PGP bit is clear it
would be the best for X.509 and possibly bare keys).

--  A new section (or possibly a set of subsections for Section 2.1.2) would
need to be created to describe how the comparisons to public keys are done.
This would be mostly for completeness and would allow for an easy way of
saying which pairs (if any) are to be considered as valid/invalid.  Positive
statements would be preferred.

-- Throughout the document, all places where it is assumed that the only
reference types are either exact match or hash would need to be updated to
reflect that there are more than two classes of reference types.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Monday, August 15, 2011 7:43 PM
> To: dane issue tracker
> Cc: DANE WG
> Subject: Re: [dane] #29: Request new Reference Type - Public Key
> 
> 
> > I would like to be able to restrict to a certificate based solely on
> > the public key value of the certificate.  This could be used for any
> > of the different Certificate Type fields.  EE certificate, Trust
> > Anchor certificate and the missing ones for intermediate certificate
> > and pgp certificate.
> 
> That seems fine. Is there any text in the current draft that prevents you
from
> doing that?
> 
> --Paul Hoffman
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Aug 2011 20:38:15 -0700

On Aug 15, 2011, at 8:59 PM, Jim Schaad wrote:

> no there is no text that would prevent me from doing this.  

There is no reference type, but there is a certificate type.

Is the problem that 2.1.2 says "certificate" when it means "the value specified by certificate type field"?

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 21:49:48 -0700

No - What I want is exactly what I requested - a reference type of public
key.

This would allow me to say that the EE certificate has a specific public
key, I can then roll the EE certificate over to my heart's content.
Additionally I could say that the Trust anchor has a specific key value
rather than saying this is the certificate for a trust anchor.

It is possible that if this is adopted then the public key certificate type
could be replaced with a "bare public key" certificate type rather than the
current "this is a public key" certificate.  I believe that this would be a
cleaner division of things.

Jim

> Sent: Monday, August 15, 2011 8:38 PM
> To: DANE WG
> Cc: dane issue tracker
> > Other than the fact that there is no reference type defined for public
> > key - no there is no text that would prevent me from doing this.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 10:04:26 -0400

+1

subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a RefType and not a CertType.  (I think I raised this in my earlier review.)  Right now, the draft seems confused about the semantics of the two fields: 

CertType == How to use the certificate
RefType == How certificate is identified/encoded

If it would help to have better names for these things, I would suggest something like "Usage" for the first one.

--Richard

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 16 Aug 2011 19:06:04 +0300

On Tue, Aug 16, 2011 at 10:04:26AM -0400, Richard L. Barnes wrote:
> +1
> 
> subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a RefType
> and not a CertType.  (I think I raised this in my earlier review.) 

What is subjectPublicKeyInfo of OpenPGP certificate?
What is subjectPublicKeyInfo of SECSH key?

Or will the specs for those certTypes have to specify what
subjectPublicKeyInfo means for those types (with option of specifying that
it is nonsense and thus not allowed)?

Yes, neither has DANE certType now, but they might in the future...

-Ilari

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 16 Aug 2011 18:45:56 +0200

> RefType == How certificate is identified/encoded

We've tried to have the same reference types for all cert types (where 0 is the identity encoding and !0 is the different type of hashes).
The cert type is used for the different "stuff" to refer, EE cert, CA cert, EE public key etc.

I agree that we could name "CertType" better, "Usage" might be a good option. Or perhaps "Association Type"?

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 16:04:41 -0400

Argument 1: Not in TLS, thus not in scope right now.  They can always add new refTypes for those protocols.

Argument 2: Why would you bother?  There's not any semantic difference between the three.

From RFC 5280:
   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

From RFC 4880:
     - A one-octet number giving the public-key algorithm used.

     - A string of octets that is the encrypted session key.  This
       string takes up the remainder of the packet, and its contents are
       dependent on the public-key algorithm used.

From RFC 4252:
      string    public key algorithm name
      string    public key blob

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Aug 2011 13:43:08 -0700

It is a data structure which holds a public key.  A I pointed out in the tracker item when I opened it up, there may be a discussion about what format should be used to encode the key.  For a TLS implementation, decoding the public key as an ASN.1 block is relatively easy as it is always going to support ASN.1.  

An OpenPGP certificate does have the equivalent of a a subjectPublicKeyInfo structure - although the exact encoding of the key is going to be different, the information contained is going to be the same and thus is readily compared.

I don't know about SECSH as I don't know if the key is going to be transmitted across the network or just kept locally.  However again, the information is the same it is just a question of what the encoding of the information is going to be.

Jim

> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2011 9:06 AM
> To: Richard L. Barnes
> Cc: Jim Schaad; 'dane issue tracker'; 'Paul Hoffman'; 'DANE WG'
> > subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a
> > RefType and not a CertType.  (I think I raised this in my earlier
> > review.)
> 
> subjectPublicKeyInfo means for those types (with option of specifying that it is
> nonsense and thus not allowed)?
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 16 Aug 2011 22:26:22 +0200

> Argument 1: Not in TLS, thus not in scope right now.  They can always add new refTypes for those protocols.

On that topic - whatever we do for "raw keys" should align with what
woes/joes does in that space. It is perhaps unlikely that they will
be used for TLS but when we get to signing they will absolutely get
used.

	Cheers Leif

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Aug 2011 23:13:14 -0400 (EDT)

> be used for TLS but when we get to signing they will absolutely get

It's being worked on in the TLS group. I did a presentation at the TLS WG on
out of band public keys, and there will be a followup on that. It might end
up being a new "certificate type" holding only a subjectPublidKeyInfo structure.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Aug 2011 20:20:00 -0700

When talking with Jim, we realized that the issue is raising here is a confluence of two things:
- He wants to be able to restrict the role that the cert or public key can be used in (trust anchor, intermediate CA, end entity)
- The current names for the two fields in record don't reflect their actual use

The tentative proposal we came up with also has two parts:

- Instead of just three types:
      1 -- A PKIX certificate that identifies an end entity
      2 -- A PKIX certification authority's certificate
      3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure
There should be six:
n   -- A PKIX certificate that identifies an end entity
n+1 -- A PKIX certification authority's certificate that identifies a trust anchor
n+2 -- A PKIX certification authority's certificate that identifies an intermediate CA
n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure that identifies a trust anchor
n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure that identifies an intermediate CA
n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure that identifies an end entity

- Instead of "Certificate Type" and "Reference Type", we need words that define the fields' roles better. A first guess would be "Restriction Type" and "Matching Type", but there could easily be better words.

--Paul Hoffman

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 17 Aug 2011 11:35:59 +0200

> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure that identifies an end entity

I like this approach and believe it would easier to implement than what we have now.
> - Instead of "Certificate Type" and "Reference Type", we need words that define the fields' roles better. A first guess would be "Restriction Type" and "Matching Type", but there could easily be be…

Works for me.

	jakob

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Aug 2011 14:00:25 -0700

This is not my ideal method of doing it, but it is one that I can live with.

> Sent: Tuesday, August 16, 2011 8:20 PM
> To: dane issue tracker
> Cc: DANE WG
> - He wants to be able to restrict the role that the cert or public key can
be
> used in (trust anchor, intermediate CA, end entity)
There
> should be six:
> n+1 -- A PKIX certification authority's certificate that identifies a
> n+trust anchor
> n+2 -- A PKIX certification authority's certificate that identifies an
> n+intermediate CA
> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure
> n+that identifies a trust anchor
> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure
> n+that identifies an intermediate CA
> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure
> n+that identifies an end entity
> 
> - Instead of "Certificate Type" and "Reference Type", we need words that
> define the fields' roles better. A first guess would be "Restriction Type"
and
> "Matching Type", but there could easily be better words.
> 
> --Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 17 Aug 2011 17:17:09 -0400

Just an admin note: 

We will be calling consensus on Monday on this topic...

W

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 17 Aug 2011 20:57:48 -0400

This suggestion seems to be missing the point.  You're still conflating the identifier for a certificate for how it's used.  Suggest the following taxonomy, which aligns much better with the use cases:

Association Type:
0. Service cert should be accepted ONLY IF matching cert is in cert chain
1. Service cert should be accepted ONLY IF it matches 
2. Service cert should be accepted IF any cert in the chain matches

Reference Type:
0. X.509 certificate (match(cert) = byte-wise equality)
1. SubjectPublicKeyInfo structure (match(cert) = SPKI in cert)
*. Digest of X.509 certificate
*. Digest of SubjectPublicKeyInfo

Of course, one could also argue that the SPKI stuff is out of scope, since there's nothing in the use case document that calls for it.

--Richard

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 18 Aug 2011 08:18:56 +0200

> Of course, one could also argue that the SPKI stuff is out of scope, since there's nothing in the use case document that calls for it.

I find the following exactly the SPKI stuff:

   Simple Key Management:  DANE should have a mode in which the domain
      holder only needs to maintain a single long-lived public/private
      key pair.

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 18 Aug 2011 07:52:30 -0400

Single key pair doesn't imply SPKI.  Single key pair could imply self-signed certificate, or even multiple different certificates with the same key pair.

For example, if you wanted to be really PKIX-friendly and not use a CA cert as your service certificate, you could create a self-signed cert (therefore a CA cert) with your key pair and issue an EE cert under it (your service cert) with the same key pair.

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Aug 2011 14:01:43 +0100

Just one wrinkle on this:

> 1. SubjectPublicKeyInfo structure (match(cert) = SPKI in cert)

There'd need to be a statement about the case where the
cert inherits relevant parameters from a superior cert
that affect the subject public key info. That's a corner
case that could maybe be ruled as not matching for DANE
(perhaps), or else this matching rule gets complex.

Look in 5280 for working_public_key_parameters for
more info. I don't know of any actually useful algorithms
where this is a deal. ECC in 5480 has MUST NOTs for this
kind of inheritance, GOST in 4491 does allow it, but I
don't know if that's a deal for DANE, and there might
be others as well, I dunno.

It could also be that this kind of inheritance also
affects reference type 0 as well, someone probably needs
to consider that.

If some other public key format (pgp, ssh, whatever)
handles algorithm parameters with some other inheritance
mechanism, then that might also cause a problem and
so also needs a bit of consideration. That's yet another
thing I don't know:-)

I don't care how this is solved, so long as its solved.
Not solving this would probably cause nasty security
issues, at least in principle.

S.

PS: I think I mentioned this before at the mic in Prague,
not sure if its covered in the current protocol draft or
was discussed on the list though - if so, sorry for being
redundant:-)

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Aug 2011 15:07:04 +0200 (MEST)

Richard L. Barnes wrote:
> 
> Single key pair doesn't imply SPKI.  Single key pair could imply
> self-signed certificate, or even multiple different certificates
> with the same key pair.
> 
> For example, if you wanted to be really PKIX-friendly and not use
> a CA cert as your service certificate, you could create a self-signed
> cert (therefore a CA cert) with your key pair and issue an EE cert
> under it (your service cert) with the same key pair.

I firmly believe that reusing a "CA keypair" for an end entity key
signed by that CA sounds like a very bad idea.

Ideally, self-signed end-entity certs should be X.509v1 certs.

Very unfortunately, the maintainers of OpenSSL and of Java (as of v1.6)
seemed to have goofed up seriously, because more recent versions of these
softwares seems to no longer create X.509v1 certs, but instead
self-signed non-CA X.509v3 certs -- even when the certs is created
without X.509v3 extensions.

The problem of X.509v3 self-signed no-CA certs is that they're
BOGUS certificates.  Both X.509-2008 and rfc5280 explicitly do *NOT*
apply to self-signed non-CA certs at all.  X.509v1 are at least
covered by older versions of the X.509 standard (e.g. -1988)
and is still fairly well supported by most PKI software.

self-signed X.509v3 non-CA certs, on the other hand, are not only
outside of all standars, they create interop problems, e.g. a
sensible TLS server implementation would not send the subject name
of an X.509v3 non-CA cert in the "certification_authorities"
element of a CertificateRequest handshake message.

A workaround to such interop problems seems to be to include
the Basic Constraint "Allowed to act as CA = TRUE" in the
self-signed cert (making it appear to be a valid RootCA of a 
private PKI), and use it as End-Entity cert in application
protocols.  

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Aug 2011 07:36:01 -0700

> 2. Service cert should be accepted IF any cert in the chain matches

I don't understand this list: they all seem the same. Can you give examples where each is different?

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Aug 2011 10:35:50 -0400

>Ideally, self-signed end-entity certs should be X.509v1 certs.

Since PKIX has deprecated v1 certs for many years, I find it hard to agree
with the term "ideally" :-).

Steve

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Aug 2011 17:00:40 +0200 (MEST)

> with the term "ideally" :-).

On the contrary, it really is "ideally".  The newer PKIX specifications
(X.509-2008 and rfc5280) explicitly do _NOT_ apply to self-signed end-entity
certs, so the deprecation does *NOT* apply to self-signed X.509v1 EE certs.

X.509-2008 is actually clearer on this than rfc5280.

X.509-2008, page 6:

 3.4.61 <b>self-signed certificate:</b> A special case of self-issued
        certificates where the private key used by the CA to sign the
        certificate corresponds to the public key that is certified
        within the certificate. A CA might use a self-signed certificate,
        for example, to advertise their public key or other information
        about their operations.

        NOTE  Use of self-issued certificates and self-signed certificates
        issued by other than CAs are outside the scope of this
        Recommendation | International Standard.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Aug 2011 12:17:46 -0400

At 5:00 PM +0200 8/18/11, Martin Rex wrote:
>...

Self-signed v1 certs are deprecated along with all other v1 certs, period.

The publication of 2459 (in 1999), 3280 (in 2002) and 5280 (2008) all 
provide a profile for v3 certs, and thus deprecate v1 certs.  V1 
certs were profiled for use in the Internet in RFC 1422 (1993).

Also, I anticipate that the 5280 clarifications doc, will have text clarifying
the status of self-signed v3 certs.

Steve

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Aug 2011 19:29:35 +0200 (MEST)

> Self-signed v1 certs are deprecated along with all other v1 certs, period.

I know you do not like self-signed end-entity certs, but exhibiting
ostrich-like behaviour is not going to make them go away.

The ISO X.509 and PKIX inaction seem to have caused a significant fraction
of the installed base to move from X.509v1 self-signed EE certs
to X.509v3 EE certs, and thereby making the situation worse.

The the principal three options for self-signed non-CA certs:

  1.)  self-signed X.509v1   
  2.)  self-signed X.509v3  non-CA
  3.)  self-signed X.509v3  Basic Constraint "allowed to act as CA=TRUE"

(2) is explicitly excluded by X.509-2008 and therefore from any profile
    based on X.509v3, such as PKIX (rfc5280). 

(1) is based on an old X.509 standard and basically still works fine

(3) is indistinguishable from a rootCA by X.509-2008 and PKIX/rfc5280
    with all the ramification this has on trust anchor management.

It would be sensible to use (1) exclusively for self-signed end-entity
certs, because it is fairly simple and straightforward to account for
this in the certificate path validation algorithm and ensure that
X.509v1 are no longer acceptable as signers of _other_ certs.

> certs were profiled for use in the Internet in RFC 1422 (1993).

X.509-2008 makes it very clear that this deprecation does NOT apply
to non-CA issued X.509 certificates, and that is inherited by every
profile of X.509.  So no, there was no such deprecation for
self-signed non-CA certs at all.

> 
> Also, I anticipate that the 5280 clarifications doc, will have text
> clarifying the status of self-signed v3 certs.

I would be much more interested in a specification that describes
what self-signed non-CA X.509 certificates should look like and
how they should be dealt with in specifications -- to make all
those tools that are currently creating such beasts as X.509v3
certs no longer work in an undefined fantasy land.

Since rfc5280 limits itself very explicitly to being a profile
of X.509v3 certs and X.509v2 CRLs, and X.509-2008 completely
and clearly excludes non-CA selfsigned certs, such a change would
require more than a few words of clarification, but a real
document update.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 18 Aug 2011 14:46:40 -0400

Those are precisely the conditions in the use case document, in sections 3.1, 3.2, and 3.3.  (3.4 is a more detailed case covered by the others)  

The major difference is "IF" versus "ONLY IF": The first two cases specify an additional constraint on certificate validation; they do not require the RP to accept a cert.  The third case requires the RP to accept a cert that chains to a matching cert; in effect, a matching cert is regarded as a trust anchor.

The first two differ in that for (0), any cert in the chain can match, while for (1) the service cert *itself* must match.  

Consider two cases:

Well-known CA ---> EE Service Cert
This case would be accepted by types (0), pointing to the CA, and type (1), pointing to the EE cert, as long as the CA is a trust anchor for the RP.   This case would be accepted by type (2), pointing to either cert, regardless of the RP's trust anchor selection.

Private CA ---> EE Service Cert
This case would be rejected by types (0) and (1), since the RP would not have the CA as a trust anchor.  This case would be accepted by type (2), pointing to either cert.

So the distinctions are 
1. Whether PKIX validation and chaining to a trust anchor are done (0,1, not 2)
2. Whether the constraint has to match the service cert itself (not 0, 1, not 2)

--Richard

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 19 Aug 2011 19:06:32 +1200

Martin Rex <[email-masked]> writes:

>The ISO X.509 and PKIX inaction seem to have caused a significant fraction of
>the installed base to move from X.509v1 self-signed EE certs to X.509v3 EE
>certs, and thereby making the situation worse.

I wrote a fairly comprehensive draft to deal with this more than ten years ago:

http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

The WG chair's reaction at the time was "we don't want to turn PKIX into PGP",
so it was never published.  It would be pretty trivial to change the dates on
this and re-publish it as a draft.  I tried doing this at the time by
laundering it through alternative channels to bypass PKIX' resistance to it
but was informed that the IETF would take a rather dim view of someone trying
to do an end-run around a standards committee.

>I would be much more interested in a specification that describes what self-
>signed non-CA X.509 certificates should look like and how they should be
>dealt with in specifications -- to make all those tools that are currently
>creating such beasts as X.509v3 certs no longer work in an undefined fantasy
>land.

It was tried more than a decade ago, but PKIX seems really keen to keep living
in their fantasy land.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Aug 2011 14:12:44 -0400

>ostrich-like behaviour is not going to make them go away.

I was not addressing the broader topic of self-signed EE certs. I was 
addressing the narrower topic of the status of X.509 v1 certs in the 
IETF.

As for self-signed v3 certs, Sean Turner and I discussed this, and he 
agrees that text will be added to the 5280 update/calcifications I-D 
to cover this
topic.

I will suggest that we clarify the status of v1 certs at the same time.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Aug 2011 16:28:08 -0700

> *. Digest of SubjectPublicKeyInfo

After a bit of off-list discussion with Richard, we came up with some rewording for his association types that make them clearer:

==========
Service Certificate: The first certificate in the TLS Server Certificate message, that is, the certificate whose public key is used for TLS key negotiation.

0. The service certificate MUST pass standard PKIX validation (including chaining to a trust anchor), and MUST chain to or through a CA certificate matching the TLSA record

1. The service certificate MUST pass standard PKIX validation (including chaining to a trust anchor), and MUST match the TLSA record

2. The service certificate MUST pass standard PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation
==========

After some thought, I like Richard's proposal very much. It puts the requirements for PKIX validation in the types definition, and makes it clear right there what is being matched.

>> - Instead of "Certificate Type" and "Reference Type", we need words that define the fields' roles better. A first guess would be "Restriction Type" and "Matching Type", but there could easily be b…

So, I guess the question splits into three (or more) possibilities. Keep the current wording, go with my earlier proposed split (based on Jim's suggestion), or go with Richard's very different proposal.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 09:11:28 -0400

Thanks to Paul for summarizing our discussion.  One clarification: Along with the three criteria below, which correspond to "usages" or "cert types", there would still be a set of ways to reference a certificate (RefTypes), of the character described below.  The cert itself, a SubjectPublicKeyInfo structure, digests of these, etc.

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 12:25:49 -0700

> Sent: Monday, August 22, 2011 4:28 PM
> To: DANE WG
> Cc: dane issue tracker
> > This suggestion seems to be missing the point.  You're still conflating
the
> identifier for a certificate for how it's used.  Suggest the following
taxonomy,
> which aligns much better with the use cases:
> >
> > Association Type:
> > 0. Service cert should be accepted ONLY IF matching cert is in cert
> > chain 1. Service cert should be accepted ONLY IF it matches 2. Service
> > cert should be accepted IF any cert in the chain matches
> >
> > Reference Type:
> > 0. X.509 certificate (match(cert) = byte-wise equality) 1.
> > SubjectPublicKeyInfo structure (match(cert) = SPKI in cert) *. Digest
> > of X.509 certificate *. Digest of SubjectPublicKeyInfo
> 
> After a bit of off-list discussion with Richard, we came up with some
> rewording for his association types that make them clearer:
> 
> ==========
> Service Certificate: The first certificate in the TLS Server Certificate
message,
> that is, the certificate whose public key is used for TLS key negotiation.
> 
> 0. The service certificate MUST pass standard PKIX validation (including
> chaining to a trust anchor), and MUST chain to or through a CA certificate
> matching the TLSA record

I have a little bit of an issue with saying that it can chain "to" a CA
certificate.  It would imply that this certificate is at the "root" of the
certificate chain and thus would be a trust anchor.  Is this the intent?

Jim

> 
> 1. The service certificate MUST pass standard PKIX validation (including
> chaining to a trust anchor), and MUST match the TLSA record
> 
> 2. The service certificate MUST pass standard PKIX validation, with any
> certificate matching the TLSA record considered to be a trust anchor for
this
> validation ==========
> 
> After some thought, I like Richard's proposal very much. It puts the
> requirements for PKIX validation in the types definition, and makes it
clear
> right there what is being matched.
> 
> >> - He wants to be able to restrict the role that the cert or public
> >> key can be used in (trust anchor, intermediate CA, end entity)
> >>     3 -- A public key expressed as a PKIX SubjectPublicKeyInfo
> >> structure There should be six:
> >> n+2 -- A PKIX certification authority's certificate that identifies
> >> n+an intermediate CA
> >> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo
> >> n+structure that identifies a trust anchor
> >> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo
> >> n+structure that identifies an intermediate CA
> >> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo
> >> n+structure that identifies an end entity
> >>
and
> So, I guess the question splits into three (or more) possibilities. Keep
the
> current wording, go with my earlier proposed split (based on Jim's
> suggestion), or go with Richard's very different proposal.
> 
> --Paul Hoffman
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 12:26:44 -0700

I am happier with the SubjectPublicKeyInfo being a RefType, but it should be
noted this was not in Paul's original message.  Paul, have you changed your
mind on this issue?

Jim

> Richard L. Barnes
> Sent: Tuesday, August 23, 2011 6:11 AM
> To: Paul Hoffman
> Cc: dane issue tracker; DANE WG
> Thanks to Paul for summarizing our discussion.  One clarification: Along
with
> the three criteria below, which correspond to "usages" or "cert types",
there
> would still be a set of ways to reference a certificate (RefTypes), of the
> character described below.  The cert itself, a SubjectPublicKeyInfo
structure,
> digests of these, etc.
the
taxonomy,
> >> chain 1. Service cert should be accepted ONLY IF it matches 2.
> >> Service cert should be accepted IF any cert in the chain matches
> >>
> >> Reference Type:
> message, that is, the certificate whose public key is used for TLS key
> negotiation.
> >
> > 0. The service certificate MUST pass standard PKIX validation
> > (including chaining to a trust anchor), and MUST chain to or through a
> > CA certificate matching the TLSA record
> >
> > 1. The service certificate MUST pass standard PKIX validation
> > (including chaining to a trust anchor), and MUST match the TLSA record
> >
> > 2. The service certificate MUST pass standard PKIX validation, with
> > any certificate matching the TLSA record considered to be a trust
> > anchor for this validation ==========
> >
clear
> > I note that it is very different than the proposal that I put forward
last
> week:
> >>> n+1 -- A PKIX certification authority's certificate that identifies
> >>> n+a trust anchor
> >>> - Instead of "Certificate Type" and "Reference Type", we need words
> that define the fields' roles better. A first guess would be "Restriction
Type"
> and "Matching Type", but there could easily be better words.
> >>>
> >
the

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Aug 2011 12:39:23 -0700

> certificate chain and thus would be a trust anchor.  Is this the intent?

Saying that something chains to certificate X does not indicate that X is at the root of a tree, nor that X is a trust anchor. For example: TA -> Y -> X -> EE. If the TLSA record of type 0 here was X, X is not a root or a trust anchor.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Aug 2011 12:40:39 -0700

> noted this was not in Paul's original message.  Paul, have you changed your

If we go with Richard's taxonomy for association types, yes: making the SubjectPublicKeyInfo be a reference type makes good sense.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Aug 2011 16:36:51 -0400

In order to help focus the discussions (and provide guidance to our authors), I'm asking the WG to please indicate a preference for text based on:

1: The current wording.

2: The proposed split (based upon Jim's suggestion ( http://www.ietf.org/mail-archive/web/dane/current/msg03223.html ))

3: Richard's "very different" proposal (outlined below).

<no hat>
I personally like #3 -- while it involves the largest amount of change, I view it as the cleanest and (at least for me) easiest to understand, especially from the "I'm just a monkey that operates a server" standpoint....
</no_hat>
W

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 23 Aug 2011 13:41:03 -0700

> 3: Richard's "very different" proposal (outlined below).

3 > 1 > 2

that is, I like Richard's proposal, but find Jim's suggestion more 
confusing than what we have now.

zw

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 15:56:08 -0700

To me that is chains through X - the text is "chain to or through"

Jim

> Sent: Tuesday, August 23, 2011 12:39 PM
> To: DANE WG
> Cc: dane issue tracker
> >> (including chaining to a trust anchor), and MUST chain to or through
> >> a CA certificate matching the TLSA record
> >
> > I have a little bit of an issue with saying that it can chain "to" a
> > CA certificate.  It would imply that this certificate is at the "root"
> > of the certificate chain and thus would be a trust anchor.  Is this the
intent?
> 
> 
> Saying that something chains to certificate X does not indicate that X is
at the
> root of a tree, nor that X is a trust anchor. For example: TA -> Y -> X ->
EE. If
> the TLSA record of type 0 here was X, X is not a root or a trust anchor.
> 
> --Paul Hoffman
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 15:56:33 -0700

#3

> Warren Kumari
> Sent: Tuesday, August 23, 2011 1:37 PM
> To: Paul Hoffman
> In order to help focus the discussions (and provide guidance to our
authors),
> I'm asking the WG to please indicate a preference for text based on:
> 
> 1: The current wording.
> 
> 2: The proposed split (based upon Jim's suggestion (
> http://www.ietf.org/mail-archive/web/dane/current/msg03223.html ))
> 
> I personally like #3 -- while it involves the largest amount of change, I
view it
> as the cleanest and (at least for me) easiest to understand, especially
from
> the "I'm just a monkey that operates a server" standpoint....
> </no_hat>
> W
> 
> 
> 
the
taxonomy,
clear
last
Type"
the

---

From: John Gilmore <[email-masked]>
Date: Tue, 23 Aug 2011 15:57:08 -0700

> 3: Richard's "very different" proposal (outlined below).

It seems to me that you're arguing about the contents of data fields
without clearly specifying what algorithms will be used to process
those data fields.  If we started with a clear description of the
algorithms, it would be a lot more obvious what data needs to exist to
support them.

For example, Richard's revised proposal says things like "The service
certificate MUST pass standard PKIX validation (including chaining to
a trust anchor)".  That seems to beg the entire question, by leaving
"standard PKIX validation" undefined.  Two sentences later it says
that with a different Association Type value, "The service certificate
MUST pass standard PKIX validation" while implying that this means
WITHOUT chaining to a trust anchor.  So does standard PKIX validation
include ... what exactly?  Making sure that the internal length fields
are all valid?  Checking the values of the dozens of fields in a
certificate -- against what validators, exactly?  Checking for the
presence or absence of what fields, exactly?  All unspecified.  Not
very helpful for a committee trying to decide whether this proposal is
what the draft standard should say.

Richard's formulation also seems to explicitly eliminate the ability
to specify the "service certificate" (or its public key) in the TLSA
record and yet not require ANY old-style trust anchors.  But that depends
on the subtleties of his Association Type 2: can the service certificate
itself be treated as a "trust anchor" in his "standard PKIX validation"
algorithm?  Or does a trust anchor need to be a separate key/cert from
the service certificate?  Answer: it doesn't say!

The whole thing seems symptomatic of the unnecessary complexity of the
nested certificate model.  Each TLS session's security is based on
correctly associating a public key with the domain name provided in
the URL that was used to begin the session.  (If you associate the
wrong public key, then your session can be hijacked or MITM'd, or
merely will never connect successfully, DOS'd.)

Both Paul's and Richard's proposals, as well as draft 10, seem to gild
that lily by saying at what level of indirection the TLSA record "is
permitted to" authenticate a key or certificate.  While I'm sure we
can think up an infinite number of possible indirections that would
lead to that public key, each one that we add produces another set of
security challenges to be analyzed and another opportunity to screw it
up.  All the serious cryptographers threw up their hands in trying to
analyze IPSEC/IKE because it had so many options that they could never
complete a security analysis in less than a career.  Do we really want
to define another protocol like that?  Why don't we just specify:

  *  If no TLSA record exists, do what the older RFCs say.

  *  If the public key in the TLSA record is identical to the public
     key that the TLS session is based on (the "service certificate")
     then the protocol deems that public key trustworthy for the 
     purposes of the TLS session.

  *  If a TLSA record exists but its key does not match, break off the
     protocol and do not trust the server-supplied public key.

and be done?

(I also note that the whole draft is written as if it's about
"certificates" and "certificate associations", though it also contains
wording that purports to make plain public keys useful.  There's small
print that giveth plain public keys, but the main flow of text seems
to taketh them away.)

	John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 22:40:06 -0400

Hi John,

Responses inline.

> algorithms, it would be a lot more obvious what data needs to exist to

I actually think we're more or less on the same page here.  The idea of my proposal was to describe the relying party actions that each association type entails, and in particular, how it differs from how a client normally processes a certificate according to RFC 5280.  I think a lot of the differences you mentions below are really just ambiguities that can and will be clarified in eventual text for the document.

> what the draft standard should say.

Sorry, it was understood that "standard PKIX validation" is the process described in RFC 5280:
<http://tools.ietf.org/html/rfc5280#section-6>

> the service certificate?  Answer: it doesn't say!

You cannot validate an X.509 certificate without reference to one or more trust anchors.  (I'm not sure what "old-style" means.)  In Association Type 2, the certificate itself can indeed be used as a trust anchor material, in which case the PKIX validation algorithm will just verify that it is a properly formed self-signed certificate.

> <snip>

That's exactly what [Association Type 2, Reference Type = SPKI] does.  We're not done by doing that because there are other use cases:
<http://tools.ietf.org/html/draft-ietf-dane-use-cases>

> print that giveth plain public keys, but the main flow of text seems

This working group is about supporting TLS.  TLS does not support bare public keys.  So the function of public keys in this context is to identify certificates.  

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 22:41:00 -0400

For the record, I like #3 as a starting point, with clarifications and details to be filled in as it gets incorporated in the text.  

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 21:36:13 -0700

> Sent: Tuesday, August 23, 2011 7:40 PM
> To: John Gilmore
> Cc: dane issue tracker; Paul Hoffman; DANE WG
> authors), I'm asking the WG to please indicate a preference for text based
> on:
> >> 1: The current wording.
> I actually think we're more or less on the same page here.  The idea of my
> proposal was to describe the relying party actions that each association
type
> entails, and in particular, how it differs from how a client normally
processes
> a certificate according to RFC 5280.  I think a lot of the differences you
> mentions below are really just ambiguities that can and will be clarified
in
> eventual text for the document.
> 
> 
> > record and yet not require ANY old-style trust anchors.  But that
> > depends on the subtleties of his Association Type 2: can the service
> > certificate itself be treated as a "trust anchor" in his "standard PKIX
> validation"
> You cannot validate an X.509 certificate without reference to one or more
> trust anchors.  (I'm not sure what "old-style" means.)  In Association
Type 2,
> the certificate itself can indeed be used as a trust anchor material, in
which
> case the PKIX validation algorithm will just verify that it is a properly
formed
> self-signed certificate.

Actually as a trust anchor there is no need for the certificate to be
self-signed.  The key is used without reference to any contents of the
certificate except for the public key information.
> That's exactly what [Association Type 2, Reference Type = SPKI] does.
We're
> not done by doing that because there are other use cases:
> This working group is about supporting TLS.  TLS does not support bare
public
> keys.  So the function of public keys in this context is to identify
certificates.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Aug 2011 00:25:59 -0400 (EDT)

> This working group is about supporting TLS.  TLS does not support bare public keys.  So the function of public keys in this context is to identify certificates.

That's a weak argument. The TLS WG choose to take on this item in the working group,
and some proposals are already floating around on how to implement it.

It seems likely a new CertType of "SubjectPublicKeyInfo" will be used to identify
TLS using bare public keys without certificates.

Postponing this now will just create more bureaucracy in a few months, or your
"identifying a cert by a public key" will simply get overloaded for tls-oob.

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Aug 2011 22:44:21 -0700

In my opinion the fact that the "identifying a cert by a public key" get
overloaded is the correct answer.

We should define a new "cert-type" of bare key, the bare key "cert-type"
(which is what is being recommended by the TLS people) would match if the
public keys match.  I don't think there is any true overloading, just a
question of how the public key reference (or match) type is defined

> Paul Wouters
> Sent: Tuesday, August 23, 2011 9:26 PM
> To: Richard L. Barnes
> Cc: Paul Hoffman; DANE WG; dane issue tracker
> public keys.  So the function of public keys in this context is to
identify
> certificates.
> 
> That's a weak argument. The TLS WG choose to take on this item in the
> working group, and some proposals are already floating around on how to
> implement it.
> 
> It seems likely a new CertType of "SubjectPublicKeyInfo" will be used to
> identify TLS using bare public keys without certificates.
> 
> Postponing this now will just create more bureaucracy in a few months, or
> your "identifying a cert by a public key" will simply get overloaded for
tls-oob.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 24 Aug 2011 10:07:53 +0200

> 3: Richard's "very different" proposal (outlined below).

I like 3, but I also see some problems with this approach. In the current wording, we have a very simple structure where the certificate type (describing what to compare) is independent of the reference type (how to compare it) and I'd recommend that we try to keep this split. In Richards proposal, the reference type is depending on the certificate type. This effectively means that not all reference types are good for a given certificate type, making it more complex to use and implement.

My preference is to go with Rickard's RP-centric certificate/association types, but add separate types where the input to the comparison function (the reference type) is the SubjectPublicKeyInfo.  This would keep the reference type generic (identity comparison or hash comparison) and ease future extensions (e.g. PGP).

- 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
- 3. as (0) but the comparison is done using SubjectPublicKeyInfo
- 4. as (1) but the comparison is done using SubjectPublicKeyInfo
- 5. as (2) but the comparison is done using SubjectPublicKeyInfo

N.B.: an association type of 2 or 5 with a reference type other than 0 wouldn't be very useful unless the TLS server provides a full certificate chain (form the EE to the CA).

	jakob

---

From: John Gilmore <[email-masked]>
Date: Wed, 24 Aug 2011 02:30:59 -0700

Richard, thank you for the clarifications.

> <http://tools.ietf.org/html/rfc5280#section-6>

That's more than 20 pages of pseudocode -- which starts off with a
basic assumption that there is some a-priori set of "trust anchors".
It does provide an algorithm in 6.1 that takes a single trust anchor
and a certificate list and attempts to validate it.  But it is quite
vague (e.g. in section 6.2) about how or whether the algorithm
iterates through these trust anchors, perhaps trying each one, perhaps
not.  RFC 5280 does not provide an algorithm that takes a (possibly
null or unitary, or multiple) vector of trust anchors and validates a
certificate list with respect to that vector.  And it says little or
nothing about where these trust anchors come from.  There's a lot of
arm-waving going on in that RFC.

It's really crufty pseudocode, too, with statements like "For each
P-OID in the user-initial-policy-set that is not the valid_policy of a
node in the valid_policy_node_set, create a child node whose parent is
the node of depth n-1 with the valid_policy anyPolicy.  Set the values
in the child node as follows: set the valid_policy to P-OID, set the
qualifier_set to P-Q, and set the expected_policy_set to {P-OID}."
Has anyone ever formally analyzed it, or even translated it directly
to an executable language so we can see if it crashes or runs?

That pseudocode also requires support for CRLs, and the realtime
fetching of CRLs, which apparently has been all but abandoned in real
life (so I heard on this list).  Do we intend to require CRL
processing for DANE-supported TLS?  If not, we can't reference this
RFC 5280 pseudocode as the master reference for the algorithm our
implementers should follow.

If and when we do choose to invoke that pseudocode, we should
formalize the arguments to it (e.g. when the TLSA record(s) say XXX,
and the set of preconfigured trust anchors is YYY, then the inputs to
the pseudocode in section 6.1 are exactly X, Y, and Z).  And if DANE
requires modifications to that pseudocode, e.g. to interleave TLSA
processing with certificate processing, then we should be extremely
precise about what those mods are.  (Of course, patching "diffs" into
a complex piece of code is likely to make it even more broken than it
was, unless very carefully done.  Especially if you have no way to run
it, no way to debug it, and no automated test cases for it.)

For many reasons, I don't think that DANE should require that
anybody use that 20+ pages of pseudocode.  As Jim Schaad has pointed
out, DANE should allow someone to put a public key (or an unsigned
certificate, i.e. a public key with some syntactic sugar around it)
into the DNS TLSA record, and provide a public key (or an unsigned
certificate) in the TLS handshake, and if the keys match, be done.
Without ever even *invoking* that error-prone PKIX validation
subroutine.

A major impetus for DANE is that enough people on the net don't trust
that whole system of error-prone certificate validation.  We should
not require its use for users who wish to avoid it.  For
straightforward cases, we should specifically *not* dummy-up arguments
to that validation pseudo-algorithm, and then make assumptions about
what results the algorithm would reach when processing those dummy
arguments (like saying "in which case the PKIX validation algorithm
will just verify that it is a properly formed self-signed
certificate").  I know you *think* it'll do that, Richard, but I don't
think you can prove it.

	John

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Aug 2011 22:07:01 +1200

John Gilmore <[email-masked]> writes:

>[...]

Another point is that I suspect whoever came up with that pseudocode probably
hasn't written ten lines of actual code in as many years, or at least has
never tried to implement what's in there, because alongside the obvious
ambiguities you mention it also contradicts both itself and the body text of
the RFC in various places.  You have to implement it to see this, I ended up
with code comments that sometimes ran to two or three *pages* trying to sort
out what interpretation to apply at different points when I was trying to
untangle the mess (in the end I took the body text as definitive, assuming
that the pseudocode would be a buggy attempt to implement the text).  OTOH it
may simply be that the PKIX requirements just can't be expressed/implemented
rigorously, which was the case when some University researchers tried it using
the (far simpler) RFC 2459 version some years ago.

In any case though it seems that virtually nothing actually implements what's
in that RFC, because if you turn on full PKIX-compliant cert processing you'll
end up rejecting, oh, about 90% of all certs in creation [0].  Some years ago
I did a quick test whose results I posted to the PKIX list where I grabbed
cert chains from eleven large public CAs.  Ten of the eleven failed full-PKIX
validation.  Heck, even NIST's own PKI test vectors fail full PKIX validation
in a number of cases.

So it seems unreasonable for DANE to expect people to go through the whole
PKIX silly-walk if almost no-one else is doing it either.  Alternatively, if
anyone wants to require this, perhaps we could require them to go away and
define exactly what's required, unambiguously, in some formal notation.  They
can come back when they're done.

Peter.

[0] Figure pulled out of my *ss and used for demonstration purposes only.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Aug 2011 22:10:51 +1200

John Gilmore <[email-masked]> writes:

>Has anyone ever formally analyzed it, or even translated it directly to an
>executable language so we can see if it crashes or runs?

Argh, sorry, hit ^D too early: We know, from a prior attempt at doing this,
that it *cannot* be formalised or analysed, even in its much, much simpler RFC
2459 form.  See:

  .A State-Based Model for Certificate Management., Chuchang Liu, Maris Ozols,
  Marie Henderson and Tony Cant, Proceedings of the 3rd Workshop on Practice
  and Theory in Public Key Cryptography (PKC.00), Springer-Verlag LNCS
  No.1751, January 2000, p.75.

(Why do you think it's presented as hand-wavy pseudocode rather than any
formal description? :-).

Peter.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 24 Aug 2011 09:00:24 -0400

Right.  If/when TLS comes along, you'll need to update the spec anyway with a new CertType/AssocType.
--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 24 Aug 2011 09:05:48 -0400

I don't think re-visiting the concept of PKIX validation is in scope for this group. For better or worse, that's the starting point for what we're doing.
--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Aug 2011 08:43:33 -0700

> To me that is chains through X - the text is "chain to or through"

OK, then I misunderstood your question. Do you have an issue with the TLSA certificate identifying the trust anchor?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Aug 2011 08:53:48 -0700

I'm happy with #3 and believe that it will be easier to get the wording right with it than with our current text. The other two proposals are also workable, but #3 feels easier to document.

#3 is also much closer than the other two proposals to what this WG has agreed on as the use cases we are aiming at.

I disagree with people who think that this WG can affect how TLS uses PKIX. If you believe that TLS's use of PKIX is wrong, take it to the TLS WG.

I think this WG needs to eventually provide a way to match any standards-track identification used in TLS. We should not try to predict how the TLS WG will standardize non-PKIX keys, but we should not do anything that would make them hard to use in TLSA.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 24 Aug 2011 11:10:34 -0700

> John Gilmore
> Sent: Wednesday, August 24, 2011 2:31 AM
> To: Richard L. Barnes
> Cc: Paul Hoffman; dane issue tracker; DANE WG
> That's more than 20 pages of pseudocode -- which starts off with a basic
> assumption that there is some a-priori set of "trust anchors".
> It does provide an algorithm in 6.1 that takes a single trust anchor and a
> certificate list and attempts to validate it.  But it is quite vague (e.g.
in section
> 6.2) about how or whether the algorithm iterates through these trust
> anchors, perhaps trying each one, perhaps not.  RFC 5280 does not provide
> an algorithm that takes a (possibly null or unitary, or multiple) vector
of trust
> anchors and validates a certificate list with respect to that vector.  And
it says
> little or nothing about where these trust anchors come from.  There's a
lot of
> It's really crufty pseudocode, too, with statements like "For each P-OID
in the
> user-initial-policy-set that is not the valid_policy of a node in the
> valid_policy_node_set, create a child node whose parent is the node of
> depth n-1 with the valid_policy anyPolicy.  Set the values in the child
node as
> follows: set the valid_policy to P-OID, set the qualifier_set to P-Q, and
set
> the expected_policy_set to {P-OID}."
> That pseudocode also requires support for CRLs, and the realtime fetching
of
> CRLs, which apparently has been all but abandoned in real life (so I heard
on
> this list).  Do we intend to require CRL processing for DANE-supported
TLS?  If
> not, we can't reference this RFC 5280 pseudocode as the master reference
> for the algorithm our implementers should follow.
> 
> If and when we do choose to invoke that pseudocode, we should formalize
> the arguments to it (e.g. when the TLSA record(s) say XXX, and the set of
> preconfigured trust anchors is YYY, then the inputs to the pseudocode in
> section 6.1 are exactly X, Y, and Z).  And if DANE requires modifications
to
> that pseudocode, e.g. to interleave TLSA processing with certificate
> processing, then we should be extremely precise about what those mods
> are.  (Of course, patching "diffs" into a complex piece of code is likely
to
> make it even more broken than it was, unless very carefully done.
Especially
> if you have no way to run it, no way to debug it, and no automated test
cases
> for it.)
> 
> For many reasons, I don't think that DANE should require that anybody use
> that 20+ pages of pseudocode.  As Jim Schaad has pointed out, DANE should
> allow someone to put a public key (or an unsigned certificate, i.e. a
public key
> with some syntactic sugar around it) into the DNS TLSA record, and provide
a
> public key (or an unsigned
> Without ever even *invoking* that error-prone PKIX validation subroutine.

Jim Schaad also things that doing standard PKIX validation is a well
understood and doable process.  He has also said that in many circumstances
the  fact that a trust anchor is being advertised in DANE is not a good
reason for accepting it.  So He is not totally on your side in many issues.

> 
> A major impetus for DANE is that enough people on the net don't trust that
> whole system of error-prone certificate validation.  We should not require
its
> use for users who wish to avoid it.  For straightforward cases, we should
> specifically *not* dummy-up arguments to that validation pseudo-algorithm,
> and then make assumptions about what results the algorithm would reach
> when processing those dummy arguments (like saying "in which case the
> PKIX validation algorithm will just verify that it is a properly formed
self-
> signed certificate").  I know you *think* it'll do that, Richard, but I
don't think
> you can prove it.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 24 Aug 2011 11:13:35 -0700

No I think that you can define a trust anchor w/ TLSA - but that would be
item # 3 not item #2.

Jim

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Wednesday, August 24, 2011 8:44 AM
> To: Jim Schaad
> Cc: 'DANE WG'; 'dane issue tracker'
> OK, then I misunderstood your question. Do you have an issue with the TLSA
> certificate identifying the trust anchor?
> 
> --Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 24 Aug 2011 12:48:29 -0700

On Wed, Aug 24, 2011 at 6:05 AM, Richard L. Barnes <[email-masked]> wrote:
> I don't think re-visiting the concept of PKIX validation is in scope for this group.
> For better or worse, that's the starting point for what we're doing.

I see no _technical_ reason why DANE cannot specify that, when
DANE-compliant clients detect TLSA records, they are to follow a novel
certificate matching algorithm specified by DANE rather than the
legacy algorithm used for in-band certificates.

I agree with John and Peter: PKIX validation is a big ball of hair,
it's poorly specified, and actual implementations don't follow the
specification.  If we can offer a tightly specified, easy-to-implement
alternative in DANE that is going to be a selling point.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Aug 2011 13:21:12 -0700

> legacy algorithm used for in-band certificates.

Me neither. The WG has to agree on the mechanism, of course, but we should not prevent such a thing.

> alternative in DANE that is going to be a selling point.

Exact matching of a non-PKIX public key structure from TLS to the same structure (or a hash of it) from TLSA seems about as simple as you can get.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 24 Aug 2011 14:14:13 -0700

> we should not prevent such a thing.

Good to hear.

> Exact matching of a non-PKIX public key structure from TLS to the
 > same structure (or a hash of it) from TLSA seems about as simple
 > as you can get.

There is one wrinkle that I am worried about: it's not quite the same 
thing as what we were talking about here, but I'm informed by Brian 
Smith of Mozilla (cc:ed) that matching TLSA records against entire 
non-end-entity certificates may not be reliable in practice, because of 
the following scenario: Suppose server E presents this chain in its TLS 
handshake

   EE <-- B <-- A

where EE is the end-entity certificate, and B and A are CA certificates, 
A being in the legacy trust-anchor pool.  However, the client has in the 
recent past connected to server F, which presented this chain

   FF <-- B' <-- A

where FF is a completely unrelated end-entity certificate, but B' is a 
*variant* of B that has the same SubjectPublicKeyInfo but different 
ancillary data.  Well, the client may decide to evaluate the TLS chain 
*for E* as if it had been

  EE <-- B' <-- A

At which point, if F's TLSA record was B or hash(B) instead of SPKI(B) 
or hash(SPKI(B)), we get a mismatch which was not intended by the server 
operator.

I personally would be okay with resolving this problem by adding a line 
reading "DANE clients MUST apply [our matching algorithm] to the 
certificate chain presented by the server they are presently talking to, 
not any modification of it based on local information, except that any 
locally-configured certificate blacklist SHOULD be honored" (or words to 
that effect) to the RFC, but I have a suspicion that Brian will say 
that's going to be very hard to implement...?  Failing that, it may be 
that we should specify _only_ SPKI(cert) and hash(SPKI(cert)) records, 
not entire-cert and hash(entire-cert) records.

zw

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 24 Aug 2011 18:08:49 -0700

This is and always has been a potential problem with any system where a
client wants to impose additional restrictions on path construction where
the code being used does not permit any client input into the process.

In this case there are multiple valid paths, at least from the point of view
of the path construction code, and the additional restrictions that need to
be added by the client are not allowed as inputs to the Mozilla code.  The
same thing can be true for enforcement extensions in the path which is not
supported by the base code.  This is one of the reasons why path
construction code needs to either return all paths for later checking by the
client or allow for the client to impose itself in the path construction
code.

I do not consider this to be an issue that DANE needs to solve.

Jim

> Zack Weinberg
> Sent: Wednesday, August 24, 2011 2:14 PM
> To: Paul Hoffman; [email-masked]; [email-masked]
> Subject: [dane] Matching entire non-end-entity certs (was Re: #29: Request
> new Reference Type - Public Key)
> 
> >> DANE-compliant clients detect TLSA records, they are to follow a
> >> novel certificate matching algorithm specified by DANE rather than
> >> the legacy algorithm used for in-band certificates.
> >
> >> specification.  If we can offer a tightly specified,
> >> easy-to-implement alternative in DANE that is going to be a selling
point.
>  > same structure (or a hash of it) from TLSA seems about as simple  > as
you
> can get.
thing as
> what we were talking about here, but I'm informed by Brian Smith of
Mozilla
> (cc:ed) that matching TLSA records against entire non-end-entity
certificates
> may not be reliable in practice, because of the following scenario:
Suppose
> server E presents this chain in its TLS handshake
> 
>    EE <-- B <-- A
> 
> where EE is the end-entity certificate, and B and A are CA certificates, A
being
> in the legacy trust-anchor pool.  However, the client has in the recent
past
> connected to server F, which presented this chain
> 
>    FF <-- B' <-- A
> 
ancillary
> data.  Well, the client may decide to evaluate the TLS chain *for E* as if
it had
> been
> 
>   EE <-- B' <-- A
> 
> At which point, if F's TLSA record was B or hash(B) instead of SPKI(B) or
> hash(SPKI(B)), we get a mismatch which was not intended by the server
> operator.
> 
certificate
> chain presented by the server they are presently talking to, not any
> modification of it based on local information, except that any locally-
> configured certificate blacklist SHOULD be honored" (or words to that
effect)
> to the RFC, but I have a suspicion that Brian will say that's going to be
very
> hard to implement...?  Failing that, it may be that we should specify
_only_
> SPKI(cert) and hash(SPKI(cert)) records, not entire-cert and
hash(entire-cert)
> records.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 24 Aug 2011 21:36:59 -0400

It's not really clear why you need all six.  It seems like (3,4,5) is just (0,1,2) with the SPKI reference type.  With that reference type "match the TLSA record" means that the SPKI in the cert equals the SPKI in the TLSA.

--Richard

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 25 Aug 2011 07:26:04 +0200

> It's not really clear why you need all six.  It seems like (3,4,5) is just (0,1,2) with the SPKI reference type.  With that reference type "match the TLSA record" means that the SPKI in the cert eq…

In the current draft, the matching type is either the identity transformation or a hash transformation on the data indicated by the certificate type. This is simple and is easy to reuse for future certificate types (e.g. PGP). In your proposal - if I understand it correctly - the reference type depends on the certificate type, i.e. it is not only a transformation before comparison as it can also be "extract the SubjectPublicKeyInfo and hash the contents using sha256".

I'd like us to try and keep the simplicity of the old proposal, and I believe it would be wise the keep the hash algorithm separate from the rest of the logic. This can be achieved either by moving the CERT/SPKI selection into certificate type, or by adding a subtype to the certificate type. The former is what I presented in my previous mail:

The latter could be done by having separate RDATA fields for

- certificate type; aka usage (i.e., 0/1/2 in your proposal)
- selector; CERT or SPKI
- matching type; identity or various hash algorithms

In short; I like your proposal but do keep the reference type field to plain identity/hash and the CERT/SPKI selector separate.

	jakob

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Aug 2011 10:33:51 -0400 (EDT)

> I don't think re-visiting the concept of PKIX validation is in scope for this group. For better or worse, that's the starting point for what we're doing.

For a significant group of people, DANE is the method to get OUT of this mess, not to
get in deeper. Or to paraphrase others, "we have 20 years of experience......"

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Aug 2011 10:43:54 -0400 (EDT)

> It's not really clear why you need all six.  It seems like (3,4,5) is just (0,1,2) with the SPKI reference type.  With that reference type "match the TLSA record" means that the SPKI in the cert eq…

Not cert, public key.

We can get creative and add "cert types" to TLS and DANE that are really
SubjectPublicKeyInfo's, and beat around to bush with clever wording,
but in the end DANE (and TLS) has to provide a method for TLS
SubjectPublicKeyInfo identification without certificates, no matter what
those people are left with to use as container.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Aug 2011 10:45:56 -0400 (EDT)

+1

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Aug 2011 08:24:40 -0700

> get in deeper. Or to paraphrase others, "we have 20 years of experience......"

The WG's use cases document covers multiple cases where DANE interacts with TLS in ways that continue to use PKIX validation of end entity certificates. It sounds like you are asking us to re-open the use cases document after both WG Last Call and IETF Last Call. If so, please be more explicit. If not, please consider allowing both "significant groups" of people to get value of DANE instead of just your own group.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Aug 2011 08:27:56 -0700

> those people are left with to use as container.

If by "in the end" you mean "once there is a way in TLS to use keys that are not part of certificates", we fully agree. However, until that time, asking developers to be able to match something from TLSA that does not exist in TLS seems premature.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Aug 2011 08:56:34 -0700

> In short; I like your proposal but do keep the reference type field to plain identity/hash and the CERT/SPKI selector separate.

The problem we are having in agreeing on terms is that we don't agree to the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. The most vocal proponents of providing an SPKI-not-in-a-cert is no PKIX validation, just exact matching with the end entity certificate or SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able to use SPKI-not-in-a-cert for the kinds of matching that will also involve PKIX validation.

My feeling is that the easiest way out of this is to let the SPKI-not-in-a-cert folks have their own usage type that explicitly says "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA record". Using Jakob's three-part taxonomy, there would be a fourth usage type, and any record with that usage type would have to use "SPKI" and otherwise be ignored as bad; the matching type could be either full or hashed. I don't think that adding a usage type that has to have a specific selector type is that dangerous.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Aug 2011 12:05:03 -0400 (EDT)

> The WG's use cases document covers multiple cases where DANE interacts with TLS in ways that continue to use PKIX validation of end entity certificates. It sounds like you are asking us to re-open…

"just your own group"? Where did I state that?

For all I care there is a chocolate fountain option in DANE. Local
client policy can always interpret what they want to use from any DANE
certtype/reftype.

All I am asking for is not closing the option for those people working
actively on using DANE without PKIX. The current thoughts of a TLS
certtype handshake message with cert type of subjectPublicKeyInfo and
a matching DANE certtype/reftype not mandating PKIX CA/EE validation is
all I'm asking for. Anyone who wants to create another 20 years of PKIX
innovation is welcome to do so in my opinion. Was that not clear?

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 25 Aug 2011 09:38:14 -0700

I don't think that Richard has suggested that what you do for a SPKI
reference is to extract and hash.  One could create a match type that does
that but I know that I have not suggested that.  I have just said that SPKI
should be an acceptable match type.  The rules for the SPKI match type would
need to be defined (i.e. is it identity or is it some type of smarter
match), but I have not suggested extract and hash as I don't see that as
being useful.   That is something that would be lost, on the other hand I
don't know that it is useful.

Jim

> Jakob Schlyter
> Sent: Wednesday, August 24, 2011 10:26 PM
> To: Richard L.Barnes
> Cc: Paul Hoffman; DANE WG
> > It's not really clear why you need all six.  It seems like (3,4,5) is
just (0,1,2)
> with the SPKI reference type.  With that reference type "match the TLSA
> record" means that the SPKI in the cert equals the SPKI in the TLSA.
> 
> In the current draft, the matching type is either the identity
transformation
> or a hash transformation on the data indicated by the certificate type.
This is
> simple and is easy to reuse for future certificate types (e.g. PGP). In
your
> proposal - if I understand it correctly - the reference type depends on
the
> certificate type, i.e. it is not only a transformation before comparison
as it can
> also be "extract the SubjectPublicKeyInfo and hash the contents using
> sha256".
> 
> I'd like us to try and keep the simplicity of the old proposal, and I
believe it
> would be wise the keep the hash algorithm separate from the rest of the
> logic. This can be achieved either by moving the CERT/SPKI selection into
> certificate type, or by adding a subtype to the certificate type. The
former is
> what I presented in my previous mail:
> 
> - 2. Certificate MUST pass PKIX validation, with any certificate matching
the
> TLSA record considered to be a trust anchor for this validation
> In short; I like your proposal but do keep the reference type field to
plain
> identity/hash and the CERT/SPKI selector separate.
> 
> 
> 	jakob
>

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 25 Aug 2011 19:57:02 +0200

> The problem we are having in agreeing on terms is that we don't agree to the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. The most vocal proponents of providing an SPKI-not-in-a…

Yes, I forgot about the difference between "require PKIX, match on SPKI" and "ignore PKIX, match on SPKI" - thanks for pointing that out.

> My feeling is that the easiest way out of this is to let the SPKI-not-in-a-cert folks have their own usage type that explicitly says "SPKI-not-in-a-cert from the TLS Certificate message MUST match…

Given Paul's feedback, my proposal would have three fields (in addition to the association data itself):

usage:
- 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
- (future) 3. Ignore PKIX, match the TLSA record

selector:
- 0. Certificate
- 1. SubjectPublicKeyInfo

matching type:
- 0. match on exact selected contents
- 1. sha-256 hash of selected contents
- 2. sha-512 hash of selected contents

	jakob

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Aug 2011 15:25:11 -0400

>alternative in DANE that is going to be a selling point.

Zack,

DANE is free to specify how to validate key and associated data 
obtained through the DNS.

Validation of X.509 certs is the province of the PKIX WG.

Steve

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 25 Aug 2011 20:58:24 -0700

On Thu, Aug 25, 2011 at 12:25 PM, Stephen Kent <[email-masked]> wrote:
> DANE is free to specify how to validate key and associated data obtained through the DNS.
>

That is not a _technical_ reason to do anything.

I am not sure whether or not DANE _needs_ to override or even mention
PKIX validation -- I am more than a little behind wrt the current
state of the spec -- but I think it would be a great shame if the
Right Thing in technical terms were blocked because of IETF politics.

zw

---

From: SM <[email-masked]>
Date: Thu, 25 Aug 2011 23:34:59 -0700

>Right Thing in technical terms were blocked because of IETF politics.

IETF politics is about figuring out the Right Thing is technical terms.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Aug 2011 07:26:51 -0400

> That is not a _technical_ reason to do anything.

This is a political process, not a technical one.

If I want to do technical design I get a review club of four to five people
who are leading experts plus maybe a few bright grad students and we have
some fun. Whatever else it has been, DANE has not been fun.

The CA industry has spent the past five years trying to work out how to get
the browser providers to do hard fail on existing revocation mechanisms.

Proposing a new cause of revocation on the basis of an infrastructure that
is inevitably more incomplete and less dependable in operation than the
existing ones was never going to happen.

> Right Thing in technical terms were blocked because of IETF politics.

No, what you believe to be the right thing and what a clique of ten to
twenty people believe is the right thing. There are two billion users of the
Internet and they did not elect you as commissars.

Consensus was formed in this working group by excluding the stakeholders
that had contrary opinions and interests. That is an expedient way to get to
WG consensus on an Internet Draft but it is totally counterproductive with
respect to IETF consensus.

IETF consensus is the real test to get an RFC and that is in turn only a
proxy for obtaining the industry consensus you need to change the
infrastructure.

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Aug 2011 08:14:01 -0700

> Right Thing in technical terms were blocked because of IETF politics.

To catch up on the spec, you should certainly read draft-ietf-dane-use-cases-05.txt, the spec that the WG agreed to base our work on.

The current protocol spec is still in flux as the WG decides what it wants and how to do it.

My reading of the use cases document is that PKIX validation needs to be dealt with in some cases, but not in all cases. Others may disagree.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Aug 2011 12:04:00 -0700

Just realized I had not responded directly to this...

> - 2. sha-512 hash of selected contents

This seems like the best proposal so far. It makes the three major use cases clear, it allows for people who want to do a self-signed cert to do so now (with usage #2), and it does not impede future proposals from extending the record. Of the "future proposals", I would guess that "spki-not-in-a-cert" would be done as a new usage that would mandate that the selector be #1 and would allow all matching types; I would guess that "OpenPGP assertion" would be done as a new usage that would mandate a selector of #0 (or would add another selector) and would allow all matching types.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Sat, 27 Aug 2011 12:01:48 -0400

>That is not a _technical_ reason to do anything.

it is an IETF procedural reason, and the DANE WG exists in the IETF.

Steve

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Aug 2011 10:43:43 -0400

>> My feeling is that the easiest way out of this is to let the SPKI-not-in-a-cert folks have their own usage type that explicitly says "SPKI-not-in-a-cert from the TLS Certificate message MUST match…

So, from the "Please indicate a preference" mail (http://www.ietf.org/mail-archive/web/dane/current/msg03272.html) the chairs see consensus for option #3 ('Richard's "very different" proposal').

This below suggestions is a small revision to that, and I wanted to confirm with the WG that this 3 fields revision is acceptable (just the 3 fields revision, not the "Ignore PKIX, match the TLSA record" bit).

This feels like a minor cleanup to us, no on has objected on list, and so:
a: silence will be taken as consent
b: we will call this at 16:00GMT on September 2nd.

W

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Aug 2011 15:32:34 -0400 (EDT)

>> - (future) 3. Ignore PKIX, match the TLSA record

This seems awefully close to trying to dictate local policy to the client. I thought a lot of people
objected to that? If you want DANE to be able to say a local policy "MUST pass PKIX", then you also
have to allow dictating a local policy that says "MUST NOT accept PKIX".

I am also not sure that if/when we create a new TLS cert type containing just a subjectPublicKeyInfo,
what "Certificate MUST pass PKIX validation" even means..... So like John, I have problems which
these statements.

If we do go along the suggested "new approach" lines, I would like to propose:

     3 Certificate MUST match TLSA record

That leaves the door open for the TLS client to use or not use PKIX based on whatever
local circumstances or policy. And the statement itself does not depend on any drafts
or other incomplete TLS extensions currently being discussed.

Furthermore, TLSA should be able to pin the TLS client with a "no PKIX", as that is
a valid use case as per dane-use-cases Ssection 4:

 	Minimal Dependencies:  It should be possible for a site to deploy
       DANE without also deploying anything else, except DNSSEC.

With this addition of (3) that is not relegated to some undecided point in the
future, I am okay with this new proposal. Otherwise, I am strongly opposed.

Paul