Subject: [dane] use case for naming convention in the DNS for sign/encrypt functionality

From: "Rose, Scott" <[email-masked]>
Date: Thu, 4 Dec 2014 16:14:01 +0000

>From the interim meeting - 

Using a naming convention for designating sign/encrypt becomes useful when CU=3 is used.  If SMIMEA is going to follow the same interpretation as in TLSA, then the client may not be doing any other checks or use any other parts of the cert such as the keyUsage field.  They may not even be present in the cert - just a bare bones X.509 that may not contain much beyond the public key.  So if an enterprise wants to use certs with CU=3 and separation of roles, this functionality becomes useful.

A varient of that could be an enterprise using a local trust anchor (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all domain users), and generating encryption certs and using CU=3 since clients won't be able to perform full PKIX validation to the local trust anchor if they don't have it stored locally.  In a way, the encryption certs could be views as opportunistic S/MIME.  So you have:

*._sign._smimecert.example.com  IN SMIMEA  2 0 1 <blob of local TA>

and for each user that is allowed to accept encrypted mail:
<user>._encr._smimecert.example.com  IN SMIMEA 3 0 0 <blob of local TA (or self) signed cert>

The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert, and what to do if the field is not present in the cert at all.  A lot of this can be done without the naming convention, but it allows more flexibility and allows for easier management for some usage scenarios.  

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Paul Wouters 🔓 <[email-masked]>
Date: Thu, 4 Dec 2014 12:06:37 -0500 (EST)

> Using a naming convention for designating sign/encrypt becomes useful when CU=3 is used.  If SMIMEA is going to follow the same interpretation as in TLSA, then the client may not be doing any other…

But RFC 6698 states:

 	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.

The Certificate Usage that seems appropriate are the ones specifying
it should do "full PKIX validation" (usage 1 or 2, not 3), which would
include the EKU's to know whether the certificate is good for signing
or encrypting.

> <user>._encr._smimecert.example.com  IN SMIMEA 3 0 0 <blob of local TA (or self) signed cert>

What does an SMIMEA DNS record signify?

I thought it meant "you can verify signatures on received email" and
"you can send encrypted email using this encryption key".

I do not think it can mean "this user is allowed to accept encrypted
email". Whether or not to encrypt is a local policy of the sender. If
and only if the sender wants to encrypt it, it will look for the
appropriate encryption key.

I would envision an organisation to either allow individual encryption
keys, or a global encryption key. If you use a global encryption key,
you might still want to have individual signatures of people within
the organisation. So I can see that as a use case.

That use case _could_ also be solved by having two keys:

<user>._smimecert.example.com  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>
<user>._smimecert.example.com  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>

Where one has the signing EKU set and one has the encryption EKU set.

This is much more straight forward and prevents situations where the EKU
and the DNS _prefix disagree and eliminates a lot of corner cases.

> The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert

It should always rely on it for CU=1 and CU=2. And CU=3 should clearly
not be used if there is domain policy covering an individual.

>, and what to do if the field is not present in the cert at all.

I would say PKIX validation determined an SMIME certificate without
signing EKU cannot be used to verify signatures. An SMIME certificate
without encryption EKU cannot be be used for sending encrypted email.
(and if encryption is mandatory according to local policy, no email
should be sent in the clear either)

>  A lot of this can be done without the naming convention, but it allows more flexibility and allows for easier management for some usage scenarios.

In my experience with X.509 and IKE and various EKU's and interop, many
vendors come up with many different EKU's related to the policy of
authentication and encryption. I'd really prefer not to see a zillion
_prefixes and a new RFC whenever a vendor comes up with a new EKU.

Paul
(and yes, I have had to do interop tests by adding 20 non-RFC EKU's to see
if a certain phone vendor would finally use the damn certificate for IKE)

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 5 Dec 2014 10:22:52 -0500

> appropriate encryption key.
It would be up to the org's policy about who can accept encrypted mail, and it wouldn't necessarily be signaled by DANE, just if a client discovers a cert that it can use to send encrypted mail, it could use it.  

> <user>._smimecert.example.com  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>

True, I admit there are several ways to publish the RR's

> not be used if there is domain policy covering an individual.
I was thinking this too, but it isn't in the explicit in the text right now.  The problem I see is when an org decides to use CU 3 and doesn't bother to include a keyUsage or EKU.   If that isn't the case and can be prevented with best common practices, then that is ideal.

> _prefixes and a new RFC whenever a vendor comes up with a new EKU.
I wasn't aware of that - yes that is a problem and a good argument against having DANE signal/confuse things.  

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Dec 2014 06:18:58 +0800

> It would be up to the org's policy about who can accept encrypted mail, and it wouldn't necessarily be signaled by DANE, just if a client discovers a cert that it can use to send encrypted mail, it…

This is a good point, and one that became clearer in the second draft of draft-osterweil-dane-ent-email-reqs: not all requirements need to be met by DANE. A separate set of DNS records could be used to say "I don't care how you got that encryption key for that user: don't send encrypted to them because they will never get it".

> True, I admit there are several ways to publish the RR's

This is one of the dangers of giving a use case that includes proposed on-the-wire solutions. :-)

> I was thinking this too, but it isn't in the explicit in the text right now.  The problem I see is when an org decides to use CU 3 and doesn't bother to include a keyUsage or EKU.   If that isn't t…

This is a topic that came up in the interim meeting that I think is critical for this WG: are the keyUsage and extendedKeyUsage fields in a cert received in an SMIMEA response:
- always paid attention to
- never paid attention to (the key usage will be determined in other ways)
- something squishy in between?

This also ties to the question of the interaction of SMIMEA records with certs received in other ways. If we have rules for keyUsage and extendedKeyUsage that are *different* based on where you got the cert, we can be sure that this will be mis-implemented, and possibly for good policy reasons.

> I wasn't aware of that - yes that is a problem and a good argument against having DANE signal/confuse things.  

Yes, but. Having _prefixes for SMIMEA for SMIME actions (signing and encrypting) might be useful. We need to make it clearer that SMIMEA is a way to get a user's S/MIME credentials; an org that wants to distribute certs for other reasons would need to use a different RRtype. (And this would help deal with the problem of case sensitivity as well...)

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 6 Dec 2014 05:16:57 +0000

On Thu, Dec 04, 2014 at 12:06:37PM -0500, Paul Wouters ? wrote:

> >Using a naming convention for designating sign/encrypt becomes useful
> > when CU=3 is used.  If SMIMEA is going to follow the same interpretation
> > as in TLSA, then the client may not be doing any other checks or use any
> > other parts of the cert such as the keyUsage field.  They may not even be
> > present in the cert - just a bare bones X.509 that may not contain much
> > beyond the public key.  So if an enterprise wants to use certs with CU=3
> > and separation of roles, this functionality becomes useful.
>
> But RFC 6698 states:
> 

Though we should keep in mind that the OPS draft updates 6698 to
specify that usage 3 ignores expiration and name checks:

    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1

but, this says nothing about ignoring keyUsage.  Also we've (as
the DANE WG) have not yet discussed to what extent the OPS draft
updates apply only to DANE TLSA, or to all DANE documents that use
compatible RRDATA formats.

> include the EKU's to know whether the certificate is good for signing

I expect DANE-TA(2) to be a fairly popular certificate usage for
enterprises that want to publish signature only keys, but per the
interim meeting, enterprise certs don't always signal the constraints,
so some additional out of band (not in the certificate) signalling
may in fact be required.

I should also point that when the DANE TLSA RRset for a mailbox
publishes only trust anchors (usage 0 or 2), and/or only digests
of EE keys, the association is at first blush a signature only
association.  This is because for first contact, the user's actual
public key remains unknown and must be obtained by other means.

Only "TLSA [13] ? 0" records provide usable end-entity key material.
And perhaps for SMIME even bare keys are not enough, IIRC one may
need access to the full recipient certificate to construct an SMIME
encrypted message and thus only "TLSA [13] 0 0" are sufficient for
(initial encryption).

So we potentially have the opportunity to declare that anything
other than "1 0 0" or "3 0 0" is a signature-only association, even
after the key is obtained out of band.  This idea may be a dead-end,
but perhaps it is worth mentioning.

> > A variant of that could be an enterprise using a local trust anchor (CU
> > 2) for digital signature certs in a wildcard SMIMEA (to cover all domain
> > users), and generating encryption certs and using CU=3 since clients won't
> > be able to perform full PKIX validation to the local trust anchor if they
> > don't have it stored locally.

Wildcards records are not merged with more specific data published
for the specific "owner name" requested in a query.  Therefore,
one cannot publish a wildcard "CU=2" and also "CU=3" per user,
and have the wildcard apply to all the users.

In any case the CU=3 comment seems to be a misconception.  Just as
in TLS the handshake chain needs to include the TA cert with all
other intermediates even if the TA is self-signed, similarly with
SMIME, the TA will need to be included in the PKCS7 S/MIME message,
along any intermediates and the leaf cert.  Therefore signed SMIME
messages can be verified based on an SMIMEA CU=2 association alone.

> > In a way, the encryption certs could be
> > viewed as opportunistic S/MIME.  So you have:
> >

Which would completely hide the wildcard, so that in fact one would
need:

    <user>._sign._smimecert.example.com  SMIMEA 2 0 1 <digest of TA>
    <user>._encr._smimecert.example.com  SMIMEA 3 0 0 <encryption cert>

which lines up with my observation a paragraph or two back.  Only
"3 0 0" or "1 0 0" yields usable encryption material, and we could
choose to say so.  Obviating the need for the "_sign" and "_encr"
labels.

> not be used if there is domain policy covering an individual.

Perhaps this is too rigid.  There are advantages to "3 0 0"
associations, and because they fully specify the certificate content,
they can signal EKU just like all the other usages can.  Though I
think that perhaps a good case was made for not expecting EKU to
be suitably set in all cases and a likely need for additional signals.

-- 
	Viktor.