On Tue, Dec 10, 2013 at 5:48 PM, Jan Schejbal <[email protected]> wrote: > The CA has all three trust bits. We definitely should remove the code > signing trust bit.
I agree. > Will this restriction also apply for S-MIME? If so, I > think we can keep the S-MIME one. What would the name constraint for S-MIME be? I am guessing that it might need to be both a constraint on the email address (restricting to *.gouv.fr) and on the DN (restricting to what, exactly)? I am not quite sure how much harder that would be to implement than the dNSName constraint for SSL, since most of my study of name constraints is specifically for SSL. If someone gives a more specific proposal for the name constraint for S/MIME, I can evaluate the practicality of implementing it. But, first, we should ask ANSSI if they have issued S/MIME certificates to people in *.gouv.fr that are still in active use. Maybe they are not using their S/MIME capability. > If the CA doesn't have a current audit report from an *independent* > party, I don't think we should keep it in the CA store in the long term > in *any* form, not even constrained. I agree, but I think for practical reasons we'd need to have a longer grace period for this than we'd need for constraining the CA to *.gouv.fr. The name constraint to *.gouv.fr is something that could likely be done in the next release or the release after that. >> Based on the list that Rob provided, there may be other domains that we >> might consider including. > > This would basically mean that Mozilla would be performing CA duties - > checking dozens or hundreds of domain names and verifying if it is a > good idea to let the CA manage those. I think this would be excessive. I think the idea is that we'd add the constraint once, and then we'd not modify it. I don't think we should process requests to broaden the constraint after we've imposed the initial one. Like you said, we don't want to get into that business. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
