In addition to the comments below, note that I conceded that simple
grandfathering based on requirement dates would probably do the job.
On 16/02/2016 17:16, Steve wrote:
As long as TLS handshake performance concerns keep RFC 6961 from de facto (
https://bugzilla.mozilla.org/show_bug.cgi?id=611836) we'll need to operate
root tier responders with HSM-driven origins, cached responses, and
multiple CDNs.
Yep, still working on RFC6961 implementation code myself.
Further, you're talking about a certificate that is issued by the root
owner on their own behalf. To me, that is within logical inner sanctum,
regardless of how it needs to physically extend itself beyond the
perimeter. By that point, the serial number that the root put into the
responder certificate doesn't matter - the root owner controlled the
responder key and PKCS#10 brought to their root.
I was merely arguing that the counter-arguments about specific BR and
Mozilla requirements for sub-CAs would not alleviate any hypothetical
attacks on other root-issued certs.
In my practice, all root private key exposures face the same procedural
pre-audit, test root issuance, results review, production issuance (and
associated m of n methods), post-audit, and delivery whether a subordinate
CA or a responder certificate.
Good for you (and all your relying parties), doesn't extend to all the
other CAs unless backed by requirements.
Kind regards,
Steve Medin
On Tue, Feb 16, 2016 at 10:03 AM Jakob Bohm <[email protected]> wrote:
A few clarifications:
On 15/02/2016 16:06, Peter Bowen wrote:
I actually agree with Steve, but for a slightly different reason. The
known attacks all required having a submitted subject key with certain
properties. The CA/Browser Forum Baseline Requirements state that all CA
keys (including subordinate CA keys) must be generated on HSMs during a
ceremony witnessed by an independent auditor. Now it is possible that the
HSM will generate an appropriate key, but it would be highly unlikely.
My arguments were not restricted to sub-CA certificates, but included
other root-issued certificates such as OCSP responders (for revocation
checks on root-issued certificates).
Further, Mozilla is requiring disclosure of all CA-certificates. I
don’t know if the discussion ever closed on the timeline, but it should be
quite obvious if someone is attempting to put large numbers of random bytes
in a the subject Name, which is the only other attacker controlled field.
Again, argument not restricted to sub-CA certificates.
That being said, I’m not going to change cablint to remove this warning
message unless the BRs are changed. Certlint and cablint intentionally
follow published standards when such exist. I’ve made a number of changes
since release to be more compliant and that is the path that will continue.
I agree that setting a grandfathering data for making this either an
error or a weak warning would be a simpler solution to co-existing with
the historical practice.
That grandfathering date could be based on when the published standards
introduced the requirement for different kinds of cert (there was a
discussion if the rule in one of the RFCs applied to the root cert
itself, so that one might have a different cut-off date corresponding
to when the current interpretation took effect).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
