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

[Paul Wouters <[e-mail]>]

On Fri, 31 Oct 2014, Osterweil, Eric wrote:

> 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:

The problem has not gone away though. It would help if you could state
publicly whether any of your suggestions might fall under planned or
actual IPR by Versign? If so, a statement with license conditions
compatible with the IETF process would be useful. Without any such
statements, I'm even feeling uncomfortable reading anything you wrote,
let alone accepting any contributions from members of your company.

So as it stands, I am against any of your suggestions, without having
read them.

Paul

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