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, 3 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 attem=
pt 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 targe=
t technology but if it applies or could apply to other technologies, they s=
hould be included. =20

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 d=
raft 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 fu=
ction
       specific label allows for clients to query for a particular certific=
ate and
       keep the DNS response minimal.  Having this the left-most label allo=
ws=20
       for the use of wildcards if only one certificate is used for both di=
gital=20
       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=20
	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=20
      "@" 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? =20

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D