On 19/05/17 20:40, Matthew Hardeman wrote: > Not speaking as to the status quo, but rather in terms of > updates/changes which might be considered for incorporation into > policy would be to recognize the benefit of name constrained > intermediates and allow a reduction in burden to entities holding and > utilizing name constrained intermediates, both in SSL Server > Authentication, and Email Protection. (Probably also allow that OCSP > signing, client authentication, certain encrypted storage extended > key usages, etc, be allowed).
This is certainly a question worth considering. I think a careful comparative risk analysis is in order, and so thank you for starting that process. The issue with excluding any certificate or group of certificates from the entire scope of the policy is that the issuer would then be free to issue SHA-1 certs, certs with bad or unpermitted algorithms, and so on. Are you suggesting that EE certs issued from such an intermediate be entirely unregulated, or that we should strip down the regulation to merely technical requirements, ignoring requirements on audit, CP/CPS, revocation etc.? >> From a perspective of risk to the broader web PKI, it would appear >> that a properly name constrained intermediate with (for example) >> only the Server and Client TLS authentication ekus with name >> constraints limited to particular validated domains (via dnsName >> constraint along with excluding wildcard IP/netmask for IPv4 and >> IPv6) is really no substantively more risky than a multi-SAN >> wildcard certificate with the same domains. I currently agree this is broadly true, with the exception of the lifetime issue which you raise in a later message. There would be little point in such a TCSC having a max lifetime equal to the max lifetime of an EE cert, because then after day 1, the EE certs it issues couldn't have the max lifetime (because the EE cert can't last longer than the intermediate!). So perhaps max lifetime of EE + 1 year, so the issuing TCSC needs to be replaced once a year in order for the organization to continue issuing max length certs? The sub-subdomain issue is also a difference, but my current view is that it doesn't have much of an effect on the risk profile in practice. > As to disclosure of these name constrained intermediates, I should > think that if they became popular, even among largish enterprises, > there might arise quite a lot of such intermediates. Perhaps rather > than in CCADB, these name constrained intermediates should be > required as a matter of policy to be submitted to CT logs (to an > acceptable number of logs, with an acceptable number of those under > separate administrative control). If we exempt the certs they issue from CP/CPS and audit requirements, the need for such TCSCs to be disclosed in CCADB is much reduced. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
