On Thu, Apr 5, 2018 at 4:58 AM, Doug Beattie <doug.beat...@globalsign.com> wrote:
> > I don’t think you should include #2 because it's a common practice to > issue one certificate for Secure Mail that is used to both sign and > encrypt, and this would preclude CA key generation for those types of > certificates. > > I was attempting to match the existing "forbidden practice" requirement that carves out an exception only for email encryption. I don't know why that exception exists, but I do agree with you that it is uncommon for an S/MIME certificate to support encryption but not signatures. It's a fine line between what enterprises do and what they contract CAs to > do. Based on this requirement, Enterprise customers can generate keys for > any type of certificate but CAs are being specifically called out to be > excluded from this. While CAs strive to provide a complete managed > solution for their customers, this requirement prevents that from > happening. Take for example a CA that has an appliance located in the > enterprise. If that appliance generates keys, is that the "CA" generating > the keys? It gets muddy. > > Good question. I'd argue that it depends on whether or not the system is designed to permit the CA to access the private key. I'd prefer that CAs be permitted to perform key generation for any > certificate with an EKU of id-kp-emailProtection with key usage of > keyEncipherment or dataEncipherment, but perhaps with an acknowledgement > from the enterprise or end users that they acknowledge the fact the CA may > have access to their private keys. > > If we go down this route, I think we should just exempt all email certificates. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
