[dane] draft-ietf-dane-smime

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

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).

If anyone objects, please let us know.

Thanks,

Eric

-------

...

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
    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 unrecognized user names and
    revoked user certificates.  Values in all other RDATA fields MAY
    be ignored but all fields MUST be populated to comply with SMIMEA
    RDATA parsing requirements.

 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.