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