On 29/03/2018 20:46, Wayne Thayer wrote:
Thanks everyone for your input on this topic. I'm hearing consensus that we
should not require a newly issued subordinate CA certificate to appear on
an audit statement prior to being used to sign end-entity certificates.
This is something that could be clarified in our policy with a statement
such as "Newly issued subordinate CA certificates MUST appear on the CAs
next period-of-time audit statements" in section 5.3.2.
It's not yet clear to me if we should require something more than
disclosure of the actual certificate because:
* All end-entity certificates are already required to contain "A Policy
Identifier, defined by the issuing CA, that indicates a Certificate Policy
asserting the issuing CA's adherence to and compliance with these
Requirements" (BR 7.1.2.3). Isn't this enough to assert the controls
applied to the subCA certificate?
* I'm not opposed to explicitly stating that any newly issued subCA
certificate MUST appear in the appropriate CP/CPS before being used, but
isn't that obvious?
While Entrust happens to do this, as a relying party, I dislike frequent
updates to CP/CPS documents just for such formal changes.
This is because the CP/CPS is a lengthy legal document which relying
parties are "supposed to" read and understand. Thus each such needless
change generates a huge wave of millions of relying parties being
supposed to obtain and read through that document, a complete waste of
our time as relying parties.
It is much more reasonable, from a relying party perspective, for such
informational details to be in a parallel document and/or be postponed
until a scheduled annual or rarer document update (Yes I am aware of the
BR that such needless updates be done annually for no reason at all).
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
