> Certificates that are capable of being used to issue new certificates MUST
> either be Technically Constrained in line with section 7.1.5 and audited in
> line with section 8.7 only, or Unconstrained and fully audited in line with
> all remaining requirements from this section
>
> Section 8.7 reads:
> During the period in which a Technically Constrained Subordinate CA issues
> Certificates, the CA which signed the Subordinate CA SHALL monitor adherence
> to the CA’s Certificate Policy and the Subordinate CA’s Certification
> Practice Statement. On at least a quarterly basis, against a randomly
> selected sample of the greater of one certificate or at least three percent
> of the Certificates issued by the Subordinate CA, during the period
> commencing immediately after the previous audit sample was taken, the CA
> shall ensure all applicable CP are met.
>
>
> That is, according to the BRs, the issuer of a technically constrained
> subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to
> the BRs and the issuing CA's policies and practices, as well as conduct a
> sampling audit quarterly.
May be I'm missing it, but I don't see 8.7 (or at least the lines quoted above)
requiring TCSC to be compliant with BR. I read it as TCSCs must adhere to the
Issuing CA's CP and their own (TCSC's) CPS, adhereance towards which should be
verified by the Issuing CAs, however it doesn't (explicitly) state TCSC
compliance towards BR.
Is this how you arrived at "TCSC should adhere to BRs", (which to me at least,
personally, sounds fair and logical):
Issuing CA must be BR compliant
-> Issuing CA's CP must be BR compliant (unless the CA gets creative)
-> TCSC's CPS should adhere Issuing CA's CA
-> TCSC's CPS should adhere to BR
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
