[dane] Enterprise email security reqs breakdown: REQ7 (signing/encryption certs)

"Rose, Scott" <scott.rose@nist.gov> Wed, 03 September 2014 18:05 UTC

From: "Rose, Scott" <scott.rose@nist.gov>
To: dane WG list <dane@ietf.org>
Thread-Topic: Enterprise email security reqs breakdown: REQ7 (signing/encryption certs)
Thread-Index: AQHPx6Gv/dJnikS3MEKt0CG6PuebyQ==
Date: Wed, 03 Sep 2014 18:05:46 +0000
Message-ID: <4ED17ED7-C9CC-40D8-A9B8-F46860A1D831@nist.gov>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F3D3F9A7B4B42D4D8D5D87B9E79FC582@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8Ut_ECvIA-x21qot6JvWcHK7h2U
Subject: [dane] Enterprise email security reqs breakdown: REQ7 (signing/encryption certs)
Precedence: list

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
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

[dane] Enterprise email security reqs breakdown: … Rose, Scott
Re: [dane] Enterprise email security reqs breakdo… Osterweil, Eric