Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

From: [email-masked]
Date: Tue, 22 Feb 2011 23:00:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-05.txt
	Pages           : 12
	Date            : 2011-02-22

TLS and DTLS use certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  DNSSEC provides a mechanism for a zone operator to sign DNS
information directly.  This way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate
the DNS.  This document describes how to use secure DNS to associate
the TLS server's certificate with the the intended domain name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 23 Feb 2011 08:06:53 +0100

> 	Filename        : draft-ietf-dane-protocol-05.txt

We've made some updates and clarifications based on input from Scott Schmit and others, and also addressed issue #20.
Diff and full history can be found at http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/.

	jakob

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Feb 2011 11:04:24 +0000

> Diff and full history can be found at http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/.

In this version you define cert types like this:

         1 -- An end-entity certificate in DER encoding

         2 -- A certification authority's certificate in DER encoding

and later say:

   Certificate types 1 and 2 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 certificate types.

Since DER encoding can be applied to anything specified in ASN.1,
perhaps this explicitness should be in the definitions, e.g.:

         1 -- A PKIX end-entity certificate in DER encoding

         2 -- A PKIX certification authority's certificate in DER encoding

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 23 Feb 2011 13:07:37 +0100

>         2 -- A PKIX certification authority's certificate in DER encoding

I agree this is a reasonable clarification.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Feb 2011 15:05:06 +0100 (MET)

> I agree this is a reasonable clarification.

If anything, I would really prefer something like

   1 -- An end-entity X.509 certificate in ASN.1 DER encoding

   2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Feb 2011 08:05:17 -0800

>     2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

X.509 is a standard that does not contain all of the extensions created 
by the PKIX Working Group in the IETF. Using "PKIX" makes it clear that 
we are talking about certificates with the IETF extensions, not 
certificates missing them.

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Feb 2011 17:29:23 +0100 (MET)

> certificates missing them.

"PKIX certificates" looks somewhat undefined to me.

For me, it suggests the rules defined in rfc-5280 for X.509v3 End-entity
and CA path certificates only, but excludes both TrustAnchors and
self-signed X.509v1 certs for use as public key containers.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Feb 2011 08:44:28 -0800

> "PKIX certificates" looks somewhat undefined to me.

Would "PKIX [RFC5280] certificates" define it better?

> self-signed X.509v1 certs for use as public key containers.

Why do you feel that the latter two are excluded? I admit that I may be 
missing something, but I don't see anything in 5280 or in TLS that 
prohibits either. We might need to add text in our document explicitly 
calling them out as OK, but not much more, do we?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 21:08:50 -0500

>    2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

In the IETF, PKIX profiles X.509 for use with IETF security protocols,
so it probably makes sense to stick with the PKIX label here. This is 
certainly true for EE certs. For a self-signed cert used to convey 
trust anchor material, we may need some additional/different text.

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Feb 2011 16:56:46 +1300

Paul Hoffman <[email-masked]> writes:

>X.509 is a standard that does not contain all of the extensions created by 
>the PKIX Working Group in the IETF. Using "PKIX" makes it clear that we are 
>talking about certificates with the IETF extensions, not certificates missing 
>them.

This is just getting excessively pedantic. Everyone knows what an "X.509 
certificate" is, standards have been specifying this for years and 
implementers have been able to work with them without having to say "An X.509 
certificate conformant to the PKIX profile encoded using X.690 ASN.1 DER 
encoding". In any case since conformance to X.509, PKIX, and DER is more or 
less arbitrary, if you truly required strict X.509 + PKIX + DER, hundreds of 
thousands/millions of certs out there would fail to meet the spec. All you 
need to say is "a vaguely certificate-shaped object", which "X.509 cert" does 
admirably.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Thu, 24 Feb 2011 18:27:32 +0100 (MET)

> trust anchor material, we may need some additional/different text.

But this would imply that EE certs will have to be issued by commercial CAs.

I thought that one of the purposes of DANE was to allow server admins
to create their own certificate and distribute it through DNS(SEC) TLSA
records.

Maybe we should distinguish more types:

   3 -- An end-entity PKIX certificate from the TLS X.509 PKI

   4 -- A certification authority's PKIX certificate from the TLS X.509 PKI

For (1), the client would match the server certificate with the TLSA
record and be done with it, for (3), besides matching the server certificate
with the TLSA record, the client is expected to perform a regular
certificate path validation.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2011 13:40:46 -0500

At 6:27 PM +0100 2/24/11, Martin Rex wrote:
>...

no. anyone can be a CA.

>to create their own certificate and distribute it through DNS(SEC) TLSA

see comment above.

>certificate path validation.

as others have pointed out, X.509 vs. PKIX is not generally a 
meaningful distinction in this context, so the wording above is 
confusing, at best.

I plan to work with Paul to generate appropriate text, to match
PKIX standards, while preserving the intent of the DANE docs.

Steve