This and following email will be an attempt to break down the requirements in
draft-osterweil-dane-ent-email-reqs-00 into separate threads in an attempt to
make it manageable and keep issues separate. Each thread will handle one (or
two if similar) requirements and may include some strawman text to start
discussion. Most of the text and reqs deal with S/MIME as the target
technology but if it applies or could apply to other technologies, they should
be included.
I'm going to start using earlier text as the starting point. The resulting
text can either be incorporated into the existing SMIMEA draft, or a new draft
if it looks like that is the direction the WG wants to go towards.
REQ 7: The protocol MUST allow for separate management, publication,
and learning of keys that are used for signing versus
encryption.
Strawman text using naming convention:
Domain names are prepared for requests in the following manner.
1. The 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.
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. This fuction
specific label allows for clients to query for a particular certificate
and
keep the DNS response minimal. Having this the left-most label allows
for the use of wildcards if only one certificate is used for both
digital
signing and encryption if that is the policy of the organization.
1. The second left-most label is 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]), as a SHA-224 hash. This does not include the
"@" character that separates the left and right sides
of the email address.
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.
Questions:
1. is this requirement reasonable?
2. (if reasonable): Is the strawman text adequate? Should another method be
used other than a naming convention such as a different RRTYPE or usage field?
Scott
===================================
Scott Rose
NIST
[email protected]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
