Subject: [dane] I-D Action: draft-ietf-dane-smime-01.txt

From: [email-masked]
Date: Tue, 19 Mar 2013 10:30:28 -0700

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 S/MIME
	Author(s)       : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-smime-01.txt
	Pages           : 6
	Date            : 2013-03-19

Abstract:
   This document describes how to use secure DNS to associate an S/MIME
   user's certificate with the intended domain name, similar to the way
   that DANE (RFC 6698) does for TLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-01

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

---

From: Scott Rose <[email-masked]>
Date: Wed, 27 Mar 2013 14:19:24 -0400

I support the goal of this draft and want to see it progressed.

I do think it might need a bit more besides just copying the TLSA RR
format, or at least a re-definition of the values since the two uses don't
map 1-to-1.  As a first stab, I'd propose the following:

2.  The SMIMEA Resource Record

   The SMIMEA DNS resource record (RR) is used to associate an end
   entity certificate or public key with the associated email address,
   thus forming a "SMIMEA certificate association".  The semantics of
   how the SMIMEA RR is interpreted are given later in this document.

   The type value for the SMIMEA RR type is defined in Section 5.1.  The
   SMIMEA RR is class independent.  The SMIMEA RR has no special TTL
   requirements.  The SMIMEA wire format and presentation format are the
   same as for the TLSA record.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Key Usage   |   Selector    | Matching Type |               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
      /                                                               /
      /                 Certificate Association Data                  /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.  The Key Usage Field

   The Key Usage field is a one octet bit map where each bit represents
   a declared use of the key contained in the assocaited data.  The bit
   flags for the Key Usage field are the same as the Key Usage field
   defined in Section 4.2.1.3 of [RFC2495]

2.2.  The Selector Field

A one-octet value, called "selector", specifies which part of the TLS
   certificate presented by the server will be matched against the
   association data.  This field uses the same values (and meanings for
   those values) as the Selector field in the TLSA Record [RFC6698].

   AUTHOR'S NOTE: Should this be a separate registry?

2.3.  The Matching Type Field

   A one-octet value, called "matching type", specifies how the
   certificate association is presented.  This field uses the same
   values (and meanings for those values) as the Matching Type field in
   the TLSA Record [RFC6698].

   AUTHOR'S NOTE: Should this be a separate registry?

The idea of having a key usage field is so that those with two different
certs for digital signatures and encryption can have clients quickly
differentiate them.  The other fields may still be useful, but (personally)
not totally comfortable with having two different RR's using the same
registry, no matter how similar the uses are.

Scott

On Tue, Mar 19, 2013 at 1:30 PM, <[email-masked]> wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Mar 2013 10:54:49 -0700

On Mar 27, 2013, at 11:19 AM, Scott Rose <[email-masked]> wrote:

> I do think it might need a bit more besides just copying the TLSA RR format, or at least a re-definition of the values since the two uses don't map 1-to-1. 

The difference you have from TLSA is that the TLSA "certificate usage" field becomes the SMIMEA "key usage" field. In TLSA, certificate usage tells the receiving party how to use the certificate (as a trust anchor or end entity certificate); in your proposal, the key usage field is used to say if the certificate is a signing or encrypting certificate.

This is probably a false dichotomy. Your proposal prevents people from using SMIMEA records for one of the most popular features in TLSA: specifying trust anchors. Further, your stated reason for wanting a key usage field seems unnecessary:

> The idea of having a key usage field is so that those with two different certs for digital signatures and encryption can have clients quickly differentiate them.  

The key usage is contained in the certificate itself, either implicitly or because the key type can only be used for signing or encrypting. If someone has two different certs (which is likely to be common), there would simply be two SMIMEA records.

Is there a strong advantage to having a new field that gives information that is already in the certificate?

BTW, I agree with your suggestions about there being separate registries for the fields. There are definitely things that might be appropriate for TLS that are not appropriate for S/MIME, and vice versa.

--Paul Hoffman