Re: [dane] draft-ietf-dane-smime

["Osterweil, Eric" <[e-mail]>]

Hey again everyone,

The thread has calmed down a little bit, and I just wanted to add one more attempt to find a middle-ground to this thread: the initial message (below) included suggested text.  Later in the thread, there were some suggested modifications.  Thanks to all of those who spent time thinking about this and offered suggestions!  I’ve taken a couple of minutes to incorporate feedback, and here is some revised suggested text:


On Sep 29, 2014, at 8:26 AM, Osterweil, Eric <[e-mail]> wrote:

> Hey everyone,
> 
> Based on our implementation experience we would like to suggest that the following text (taken from Scott Rose's email: http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be incorporated into the current version of the draft-ietf-dane-smime document.  We are sending text (below), but at a high-level, the text outlines a few useful additions:
> 
> 1 - Usage #4 (reject) is likely to be very important.  This could either emphasize the difference between saying, ``don't use this cert for this operation,'' and ``this cert is universally revoked'' or be used to selectively override an organization-wide TA for certain employees that have left the organization.
> 
> 2 - The certificate access field (Section 2.1.4) would enable alternate discovery mechanisms that could help aid incremental deployment and transition schemes.  For example, while cutting over to a DANE solution, some enterprises may want to transition users from (say) AD to DANE, and this field would enable that.
> 
> 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the management of zone sizes and lookup sizes.  Rather than querying for all keys and then locally selecting from them, I (as an RP) likely already know which of these I want, and I should be able to look them up separately in DANE (and owners should be able to manage them separately in DANE).

. . .

2.1.  SMIMEA RDATA Fields

The RDATA for the SMIMEA RR consists of a one-octet certificate usage
field, a one-octet selector field, a one-octet matching type field, a
one-octet certificate access field, and the certificate association
data field.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cert. Usage  |   Selector    | Matching Type | Cert. Access  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                 Certificate Association Data                  /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




2.1.1.  The Certificate Usage Field

A one-octet value, called "certificate usage", specifies the provided
association that will be used to validate the certificate.  This
value will be defined in a new IANA registry in order to make it
easier to add additional certificate usages in the future.  Four of
the initial usages defined in this document are similar to the first
four TLSA [RFC6698] certificate usages.  The certificate usage values
are:

   0 or PKIX-CA -- PKIX-CA is used to specify a CA certificate, or
   the public key of such a certificate, that MUST be found in any of
   the PKIX certification paths for the user.  This certificate usage
   is sometimes referred to as "CA constraint" because it limits
   which CA can be used to issue certificates for a given user.  The
   presented certificate MUST pass PKIX certification path
   validation, and a CA certificate that matches the SMIMEA record
   MUST be included as part of a valid certification path.  Because
   this certificate usage allows both trust anchors and CA
   certificates, the certificate might or might not have the
   basicConstraints extension present.

   1 or PKIX-EE -- PKIX-EE is used to specify an end entity
   certificate, or the public key of such a certificate, that MUST be
   matched with the end entity certificate for the SMIME user.  This
   certificate usage is sometimes referred to as "user certificate
   constraint" because it limits which end entity certificate can be
   used by a given user.  The target user certificate MUST pass PKIX
   certification path validation and MUST match the SMIMEA record.

   2 or DANE-TA -- DANE-TA is used to specify a certificate, or the
   public key of such a certificate, that MUST be used as the trust
   anchor when validating the SMIME user certificate.  This
   certificate usage is sometimes referred to as "trust anchor
   assertion" and allows a domain name administrator to specify a new
   trust anchor -- for example, if the domain issues its own
   certificates under its own CA that is not expected to be in the
   end users' collection of trust anchors.  The target user
   certificate MUST pass PKIX certification path validation, with any
   certificate matching the SMIMEA record considered to be a trust
   anchor for this certification path validation.

   3 or DANE-EE -- DANE-EE is used to specify a certificate, or the
   public key of such a certificate, that MUST match the SMIME user's
   certificate.  This certificate usage is sometimes referred to as
   "domain-issued certificate" because it allows for a domain name
   administrator to issue certificates for a domain without involving
   a third-party CA.  The target user certificate MUST match the
   SMIMEA record.  The difference between certificate usage 1 and
   certificate usage 3 is that certificate usage 1 requires that the
   certificate pass PKIX validation, but PKIX validation is not
   tested for certificate usage 3.

   4 or REJECT -- REJECT is used by the domain owner to assert that
   at the time of querying the DNS, this user's certificate MUST be 
   considered invalid for the requested function (i.e. signature or encryption).  
   This is a stronger assertion than a failed certificate validation check.
   Possible usage scenarios include de-authorizing stale employee credentials
   by selectively overriding TAs that are used to authorize entire organizations.

The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding [ITU.X690.2002].  If
SMIME allows other formats later, or if extensions to this RR type
are made that accept other formats for certificates, those
certificates will need their own certificate usage values.

2.1.2.  The Selector Field

A one-octet value, called "selector", specifies which part of the
SMIME certificate presented by the server will be matched against the
association data.  This value will be defined in a new IANA registry.
The selectors defined in this document are:

   0 or CERT -- Full certificate: the Certificate binary structure as
   defined in [RFC5280].

   1 or SPKI -- SubjectPublicKeyInfo: DER-encoded binary structure as
   defined in [RFC5280].

(Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DomainKeys Identified Mail
(DKIM) [RFC6376].)

2.1.3.  The Matching Type Field

A one-octet value, called "matching type", specifies how the
certificate association is presented.  This value will be defined in
a new IANA registry.  The types defined in this document are:

   0 or Full -- Exact match on selected content

   1 or SHA2-256 -- SHA-256 hash of selected content [RFC6234]

   2 or SHA2-512 -- SHA-512 hash of selected content [RFC6234]

If the SMIMEA record's matching type is a hash, having the record use
the same hash algorithm that was used in the signature in the
certificate (if possible) will assist clients that support a small
number of hash algorithms.

2.1.4.  Certificate Access Field

This one octet value indicates an alternative method for certificate
discovery.  Some domain owners may not want to publish user
certificates via DNS but may want to use the DNS to advertise the
means to access them.  If full user certificates are not included in
the Certificate Association Data this field MAY be used to indicate
how the user's certificate can be obtained.  The RDATA certificate
association data MUST be used to validate certificates obtained by
the alternative method.

   0 or NO: No alternative method advertised.

   1 or NAPTR : NAPTR record available.  The same domain name used
   for this SMIMEA request MAY be used again with type NAPTR
   [RFC3403] to retrieve the URI for certificate access.

   2 or WF: X.509 certificates available in WebFinger [RFC7033].

2.1.5.  The Certificate Association Data Field

This field specifies the "certificate association data" to be
matched.  These bytes are either raw data (that is, the full
certificate or its SubjectPublicKeyInfo, depending on the selector)
for matching type Full (0), or the hash of the raw data for matching
types SHA2-256 (1) and SHA2-512 (2).  The data refers to the
certificate in the association, not to the ASN.1 Certificate object.
For certificate usage type REJECT (4) at least one byte of data is
REQUIRED but the value MUST be ignored.

2.2.  SMIMEA RR Presentation Format

The presentation format of the RDATA portion (as defined in
[RFC1035]) is as follows:

o  The certificate usage field MUST be represented either as a
   certificate usage mnemonic or an 8-bit unsigned integer.

o  The selector field MUST be represented either as a selector field
   mnemonic or an 8-bit unsigned integer.

o  The matching type field MUST be represented either as a matching
   type mnemonic or an 8-bit unsigned integer.

o  The certificate access field MUST be represented either as a
   certificate access mnemonic or an 8-bit unsigned integer.

o  The certificate association data field MUST be represented as a
   string of hexadecimal characters.  Whitespace is allowed within
   the string of hexadecimal characters, as described in [RFC1035].

Where practical, the mnemonic form SHOULD be used in order to provide
clarity.

2.3.  SMIMEA RR Examples

In the following examples, the domain name is formed using the rules
in Section 3.

An example of a hashed (SHA2-256) association of a Full PKIX-CA
certificate in the PKIX validation path of a certificate used to
validate a signed S/MIME message.  No alternative certificate access
is advertised.

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
      0 0 1 0 d2abde240d7cd3ee6b4b28c54df034b9
              7983a1d16e8a410e4561cb106618e971 )

 Alternatively

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
      PKIX-CA FULL SHA2-256 NO d2abde240d7cd3ee6b4b28c54df034b9
                               7983a1d16e8a410e4561cb106618e971 )

An example resource record providing Full self-signed encryption
certificate:

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._encr._smimecert.example.com. IN SMIMEA (
      DANE-EE Cert Full NO 30820307308201efa003020102020... )

An example of resource record invalidating all digital signatures by
identified user:

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
                         REJECT Cert Full NO 00 )

...

3.  Domain Names for S/MIME Certificate Associations

SMIMEA domain names include function and user labels.  The purpose is
to identify the function specific certificate if a user has multiple
certificates.  Alias MAY be used if a user has a common certificate
for both functions

...


3.1.  Domain Name Preparation

Domain names are prepared for requests in the following manner.

1.  The user name (the "left-hand side" of the email address, called
    the "local-part" in the mail message format definition [RFC5322]
    and the "local part" in the specification for internationalized
    email [RFC6530]), is encoded with Base32 [RFC4648], to become the
    left-most label in the prepared domain name.  This does not
    include the "@" character that separates the left and right sides
    of the email address.

2.  The second left-most label is the function specific label
    segment.  It is selected based on the S/MIME function the MUA is
    performing.  Values are:

       "_encr" for obtaining or validating a certificate or public
       key to be used to encrypt a message.

       "_sign" for certificate validation data to verify a digital
       signature.

    For certificate use cases XXXX-EE (1 and 3) the function specific
    label SHOULD be consistent with the Key Usage field (defined in
    section 4.2.1.3 of [RFC5280]) of the associated certificate.

3.  The string "_smimecert" becomes the third left-most label in the
    prepared domain.  The function specific label segment is separate
    to enable delegation of a single _smimecert zone cut.

4.  The domain name (the "right-hand side" of the email address,
    called the "domain" in [RFC5322]) is appended to the result of
    step 3 to complete the prepared domain name.

...

3.2.  Domain Name Examples

Example 1.  Signature certificate verification: to request an SMIMEA
resource record to verify a signature certificate for a user whose
address is "[e-mail]", you would use:

         "df7f0c341e185f1073a2caef0d37a8b6a11fac62f46beaf459532bb0._sign._smimecert.example.com"

Example 2.  Encryption key discovery: to request an SMIMEA resource
record for encrypting an email to user "[e-mail]" you would
use:

         "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351ac1b7a._encr._smimecert.example.com"

4.  Use of SMIMEA Records in SMIME

SMIMEA records are used to publish user certificates or validate user
certificates acquired by other means.  Typically these use cases are
associated with message encryption and signature validation processes
respectively.  Section 2.1 of this document defines the mandatory
matching rules for the data.  Where possible, consistency with
[RFC6698] is maintained.

4.1.  Usable Certificate Associations

An implementation of this protocol makes a DNS query for SMIMEA
records, validates these records using DNSSEC, and uses the resulting
SMIMEA records and validation to modify S/MIME message processing
behavior.

Determining whether an SMIMEA RRSet can be used MUST be based on the
DNSSEC validation state (as defined in [RFC4035]).

o  An SMIMEA RRSet whose DNSSEC validation state is secure MUST be
   used as a certificate association for S/MIME unless a local policy
   would prohibit the use of the specific certificate association in
   the secure SMIMEA RRSet.

o  If the DNSSEC validation state on the response to the request for
   the SMIMEA RRSet is bogus then the RRSet MUST be disregarded and
   considered unusable.  Additional SMIMEA queries may be initiated.

o  If the DNSSEC validation state is indeterminate or insecure then
   the SMIMEA RRSet MUST be disregarded and considered unusable.

MUAs that rely on another entity to perform the DNSSEC signature
validation SHOULD use a secure mechanism between themselves and the
validator.  Examples of secure transports to other hosts include TSIG
[RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071].  Note that it is
not sufficient to use secure transport to a DNS resolver that does
not do DNSSEC signature validation.

If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the MUA, that certificate
association MUST be considered unusable.  If the comparison data for
a certificate is malformed, the certificate association MUST be
considered unusable.

If a certificate association contains a matching type or certificate
association data that uses a cryptographic algorithm that is
considered too weak for the MUA's local policy, the certificate
association MUST be considered unusable.

If a MUA receives zero usable certificate associations from a DNS
request or from its cache, it processes S/MIME requests in the normal
fashion without any input from the SMIMEA records.

If a MUA performing certificate validation receives one or more
usable certificate associations then it MUST attempt to match each
certificate association with the user's certificate until a
successful match is found.  If no certificate associations match then
the certificate MUST be considered invalid.

If a MUA makes an SMIMEA request for an encryption certificate and
the response includes more than one valid certificate, the
certificate with the most recent "Not Before" data SHOULD be
selected. [ Are there better criteria? ]

...

6.  IANA Considerations

6.1.  SMIMEA RRtype

This document uses a new DNS RR type, SMIMEA, whose value will be
allocated by IANA from the Resource Record (RR) TYPEs subregistry of
the Domain Name System (DNS) Parameters registry.

6.2.  SMIMEA Certificate Usage Registry

This document creates a new registry, "SMIMEA Certificate Usages".
The registry policy is "RFC Required".  The initial entries in the
registry are:

  +-------+----------+--------------------------------+-------------+
  | Value | Mnemonic | Short Description              | Reference   |
  +-------+----------+--------------------------------+-------------+
  |   0   | PKIX-CA  | CA      constraint             | [this doc]  |
  |   1   | PKIX-EE  | Service certificate constraint | [this doc]  |
  |   2   | DANE-TA  | Trust anchor assertion         | [this doc]  |
  |   3   | DANE-EE  | Domain-issued certificate      | [this doc]  |
  |   4   | REJECT   | Invalid Certificate or User    | [this doc]  |
  | 5-254 |          | Unassigned                     |             |
  |  255  | PrivCert | Reserved for Private Use       | [this doc]  |
  +-------+----------+--------------------------------+-------------+


Applications to the registry can request specific values that have
yet to be assigned.

6.3.  SMIMEA Selectors

This document creates a new registry, "TLSA Selectors".  The registry
policy is "Specification Required".  The initial entries in the
registry are:

       +-------+----------+--------------------------+-------------+
       | Value | Mnemonic | Short Description        | Reference   |
       +-------+----------+--------------------------+-------------+
       |   0   | Cert     | Full certificate         | [this doc]  |
       |   1   | SPKI     | SubjectPublicKeyInfo     | [this doc]  |
       | 2-254 |          | Unassigned               |             |
       |  255  | PrivSel  | Reserved for Private Use | [this doc]  |
       +-------+----------+--------------------------+-------------+


Applications to the registry can request specific values that have
yet to be assigned.

6.4.  SMIMEA Matching Types

This document creates a new registry, "SMIMEA Matching Types".  The
registry policy is "Specification Required".  The initial entries in
the registry are:

      +-------+-----------+--------------------------+-------------+
      | Value | Mnemonic  | Short Description        | Reference   |
      +-------+-----------+--------------------------+-------------+
      |   0   | Full      | No hash used             | [this doc]  |
      |   1   | SHA2-256  | 256 bit hash by SHA2     | [this doc]  |
      |   2   | SHA2-512  | 512 bit hash by SHA2     | [this doc]  |
      | 3-254 |           | Unassigned               |             |
      |  255  | PrivMatch | Reserved for Private Use | [this doc]  |
      +-------+-----------+--------------------------+-------------+


Applications to the registry can request specific values that have
yet to be assigned.

6.5.  Certificate Access Field

This document creates a new registry, "SMIMEA Certificate Access".
The registry policy is "Specification Required".  The initial entries
in the registry are:

      +-------+-----------+---------------------------+-------------+
      | Value | Mnemonic  | Short Description         | Reference   |
      +-------+-----------+---------------------------+-------------+
      |   0   | NO        | No Alternative Advertised | [this doc]  |
      |   1   | NAPTR     | NAPTR                     | [this doc]  |
      |   2   | WF        | WebFinger                 | [this doc]  |
      | 3-254 |           | Unassigned                |             |
      |  255  | PrivUse   | Reserved for Private Use  | [this doc]  |
      +-------+-----------+---------------------------+-------------+


Applications to the registry can request specific values that have
yet to be assigned.