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

[Paul Hoffman <[e-mail]>]

On Dec 5, 2014, at 11:22 PM, Rose, Scott W. <[e-mail]> wrote:
> 
> On Dec 4, 2014, at 12:06 PM, Paul Wouters 🔓 <[e-mail]> wrote:
> 
>> On Thu, 4 Dec 2014, Rose, Scott wrote:
>>> 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>
>> 
>> 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.
>> 
> 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.

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".

>> 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>
>> 
> 
> 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. :-)

>> 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.
>> 
> 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.

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.

>>> , 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.
>> 
> 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