On Thu, 4 Dec 2014, Rose, Scott 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:
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.
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.
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)
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
