On Dec 4, 2014, at 12:06 PM, Paul Wouters 🔓 <[email protected]> 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. > 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 > 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. >> , 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. Scott > 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) =================================== Scott Rose NIST [email protected] +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =================================== _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
