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

["Rose, Scott" <[e-mail]>]

>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
[e-mail]
[phone]
Google Voice: [phone]
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================