On Thu, Jun 8, 2017 at 10:16 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are two important things about self-issued certificates: > > 1) They cannot expand the scope of what is allowed. > Cross-certificates can create alternative paths with different > restrictions. Self-issued certificates do not provide alternative > paths that may have fewer constraints. > > 2) There is no way for a "parent" CA to prevent them from existing. > Even if the only cross-sign has a path length constraint of zero, the > "child" CA can issue self-issued certificates all day long. If they > are self-signed there is no real value in disclosing them, given #1. > > I think that it is reasonable to say that self-signed certificates are > out of scope. >
Right, a self-signed certificate is also self-issued, but a self-issued certificate is not necessarily self-signed (e.g. in the event of key rollover). The question of whether self-signed should be in scope is largely related to the question of trust anchor configuration and expression, and making sure that mozilla::pkix is internally consistent with its evaluation of trust anchors and self-consistent with the policy. That is, consider https://tools.ietf.org/html/rfc5280#section-6.1.1 of RFC 5280 - the trust anchor may be provided in the form of a self-signed certificate, which nominally encompasses the Subject field and subjectPublicKeyInfo, but may also be used to derive additional constraints as the input for 6.1.1. If mozilla::pkix consistently applies the constraints expressed in the root cert (e.g. nameConstraints, as were relied upon with HARICA), then a self-signed certificate is no concern. However, if there is any disconnect - for example, using the merely the Subject/SPKI for purposes of trust anchor evaluation, but then using the certificate supplied as the basis for constraints, then you could bypass constraints imposed via the root store. Note: That would be a (logic) bug in mozilla::pkix, rather than an intrinsic bug in the CAs' operations, and so it's probably easier and more comprehensive to just fix that bug (IF it exists; I am fairly confident Brian considered this scenario when initially writing it) To the question of self-issued, there absolutely are risks to those, and we should make sure they're disclosed. The most obvious case would be key rotation events - that is, you have (Subject A, Key A) as the self-signed (and self-issued) root in the Mozilla Store, and then it self-issues (Subject A, Key B) as a key rotation. You may have an Intermediate, (Intermediate C), which is signed by either Key A or cross-signed by Key B, thus either chain works. However, the reason you want disclosure is that you want to ensure that the creation and operation of Key B has been appropriately audited - that someone isn't relying on a misinterpretation/loophole to somehow consider (Subject A, Key B) as out of scope, since it absolutely participates in the trust evaluation chain. There's a secondary question related to self-signed, in which their disclosure can help detect and remedy configuration issues and/or path building issues, and so it serves a public interest/public good to have those disclosed, but it's unclear whether that public interest/public good is necessary to mandate via policy. That is, consider the following scenario: - "For Root or Intermediate Certificates that are disclosed, CAs are not required to disclose self-signed variations of these certificates. Self-signed shall mean that the Certificate's Subject and Issuer are byte-for-byte identical, that the Certificate's Subject is byte-for-byte identical with a Certificate already disclosed to Mozilla, and the Certificate's subjectPublicKeyInfo is byte-for-byte identical with the same already-disclosed certificate" You can have the following scenarios: - Duplicate serial numbers (would break NSS, since NSS is ... poorly believing in the X.500 DIT in this respect) - Cross-certification paths that confound and/or break clients (such paths were why Red Hat patched in several legacy roots back to NSS in their distribution, due to the behaviours of OpenSSL-and-other-libraries with respect to validation) - Improperly encoding / not adhering to the BRs in the issuance of that self-signed certificate So that would be an arguement for disclosing both self-signed and self-issued certificates, and align with the "Disclose what the key does" mentality. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
