On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote:
One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?
Or put another way, would your proposed language force an organization
wanting to run under its own TCSC(s) to obtain two TCSCs, one for their
S/MIME needs and another for their TLS needs?
Yes, it allows a single TCSC that does both. The little three diamond
symbol means parallel, so both legs are evaluated at the same time.
If both get to "Goto B", then it is a single TCSC that can issue both
serverAuth and emailProtection certs.
As Gerv pointed out in previous messages, this issue is described in
https://github.com/mozilla/pkipolicy/issues/26. The current Mozilla
policy does not force separating Intermediate CAs for serverAuth and
emailProtection certs.
Microsoft's Policy
<https://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx>
currently says:
"/New/ intermediate CA certificates under root certificates submitted
for distribution by the Program must separate Server Authentication,
S/MIME, Code Signing and Time Stamping uses. This means that a single
intermediate issuing CA must not be used to issue both server
authentication, S/MIME, and code signing certificates. A separate
intermediate must be used for each use case."
It would be ideal if both policies were aligned to either allow both
serverAuth and emailProtection from the same Intermediate CA, or
separate them. As we are today, CAs that participate in Mozilla and
Microsoft Root program need to comply with the more restrictive policy.
Dimitris.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
