On Thu, Jul 18, 2019 at 11:40 AM Wayne Thayer via dev-security-policy < [email protected]> wrote:
> Andrew Ayer filed two bugs yesterday that might be worthy of a bit > of discussion. They both appear to be in reference to root certificates > included in the Mozilla program that are cross-signed by a different TSP > (CA). In both cases the TSP that signed the cross-certificate has had it > audited, and disclosed it in CCADB as operating under their own CPS. > > For example: > TSP 1 has Root A (subject A, issuer A, public key A) included in the > Mozilla root store > TSP 2 has Root B (subject B, issuer B, public key B) also included in the > Mozilla root store > TSP 2 has signed a cross certificate (subject A, issuer B, public key A) > with Root B. > TSP 2 has disclosed the cross-certificate in CCADB, has it included in > their audit, and asserts that it is operated under their CP/CPS. > > One issue, that I recall having been been previously discussed, is that TSP > 1 has no way of knowing if another TSP has cross-signed one of their CA > certificates, so it makes sense to require disclosure from the TSP that > issued the cross-certificate. > > I think Andrew is asserting that the cross-certificate is really operated > by the root TSP that is in control of the key-pair (TSP 1), and should be > audited and disclosed as such. Should that be our policy? > I think this confusion stems from the fact that the CCADB mixes the concept of trust anchors and certificates (nodes and edges in the trust graph). A certificate is a link between two entities - the issuer and the subject. The creation of a certificate is governed by the issuer's practices but the use of the key that is certified by the issuer is governed by the subject's practices. When it comes to audits, the issuer and subject can each make different auditable assertions. The issuer can assert that the certificate was created in accordance with the issuer's practices and the issuer can describe controls around publishing status and revocation information about the certificate. The subject can describe controls around the generation of the subject key and storage and usage of the private key associated with the certified public key. Unfortunately this nuance is currently not describable in the CCADB. It expects that a certificate hash is included in the audit report but does not allow separate listing of trust anchors. I think that the process should be updated to list CAs (subject, subject public key, subject key identifier), is addition to listing the CA certificates. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
