On Mon, 6 Apr 2015, Doug Montgomery wrote:
Well, this is SMIME and it uses PKIX, so the proper way to express any kind of attributes is via EKU OIDs.Part of the issue here is that we have large enterprise identity management systems that issue credentials for security functions, but independent of application. So while the EKU bits say that a CERT is useful for encryption, it does not say if that is for file encryption, disk encryption, or email encryption. Thus the EKU bits may not be enough to understand if the domain in question supports/allows encrypted email or not.
Do we need the PKIX/SMIME people to write a document to express these? This really seems to be in their domain, and using the DNS to work around not having the right EKUs seems wrong to me.
DANE/SMIMEA offers the potential to clearly express / control key usage per service and at the domain level.
The DANE working group sees regular invasions of other IETF areas whenever that area feels the DNS is trespassing on their domain. I'd prefer not to see another wave. And additionally, I do think it matters that we leak key usage intent into the DNS - especially in the current architecture of a few big resolvers like google dns and opendns seeing many of the queries.
Enterprise identity management systems, business process, and the laws and policies that govern them are the long pole in the tent here. At least on the enterprise side, we are not talking about an individual getting a $5 CERT or running ssh-keygen.
i would expect the enterprise to have a lot more control on the EKU's in the certificates they hand out to their employees than I would have ordering my $5 certificate online from an SMIME CA. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
