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 protected]> wrote:
>
> 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/
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
