> -----Original Message----- > From: dane [mailto:[email protected]] On Behalf Of Paul Wouters > Sent: Monday, April 06, 2015 9:08 AM > To: Doug Montgomery > Cc: [email protected] > Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey > > 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.
I have been doing my best to ignore this thread, but I guess I cannot any more. Firstly. EKU is not the correct way to deal with what type of key is in a certificate. EKU is used to say this is an SMIME only certificate (and I don't believe without looking that this was ever done). Key Usage (KU) is used to say this is a signing key or this is an encryption key (by restricting the usages). Yes EKU could say that a certificate is used for a specific type of encryption, however that should not be an issue here as only those targeted for S/MIME should be published in the directory. NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate has been issued. This means that there is nothing that can be done to say - Oh, I have this encryption certificate that is being published but I don't want you to use it. I want you to use a different one. In this case you just stop publishing the first certificate - no problems as long as the second is published at the same time. One can continue to publish signing certificates long after one has stopped using the matching key to perform signature operations. There is more of a problem with a validator that cannot deal with the fact that you have the same public key in two certificates, however good practice says that an EE should not do this. There is nothing that the PKIX/SMIME people should need to write to deal with any of these issues. > > > 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. This I completely agree with. If one is using certificates, that information is totally public. Jim > > > 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
