On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> The processor sends the resulting TLS certificate to Apple. Apple signs a > second, non-TLS certificate from a semi-private Apple root. This root is > trusted by all Apple devices but is not in other root programs. > Certificates chaining to this root are accepted for submission by most CT > logs. This non-TLS certificate has a CN field containing text that is not a > domain name (i.e. it has spaces). It has no EKUs, and has a special-purpose > extension with an Apple OID, whose value is the hash of the public key from > the TLS certificate (i.e. the public key that will be used by clients to > encrypt data share packets). This certificate is submitted to CT and uses > the precertificate flow to embeds SCTs. Jacob, I'm hoping you could help clarify this, as the "This certificate" remark in the last sentence leaves me a little confused. I understand the flow is: A) "Someone" requests ISRG generate a TLS-capable certificate from a TLS-capable root (whether that someone is ISRG or Apple is, I think, largely inconsequential for this question) B) That TLS-capable certificate is disclosed via CT and has SCTs embedded within it, as ISRG/LE already does C That TLS-capable certificate is then sent to Apple D) Apple generates a second certificate from an Apple-controlled root. E) This second certificate contains an extension with an Apple-specific OID that contains the hash of the ISRG certificate Concretely: 1) Is this Apple-controlled CA TLS capable? 2) Is this Apple-controlled CA subject to the Baseline Requirements? These first two questions are trying to understand why this root is present within CT logs, and whether CT logs are free to remove this Apple root. Apple has, in the past, had issues with inappropriate audits and controls, as a result of being improperly supervised [1]. I'm trying to understand whether it is from these BR-audited and BR-subjected certificates that Apple is proposing issuing, or from one of its other certificates not part of those audits. Most importantly, however, it's necessary to determine whether or not the Apple-controlled CA is trusted for TLS, as that impacts whether or not Apple's use of their CA like this is permitted. 3) Is "This certificate is submitted to CT" referring to A) (ISRG cert) or E) (Apple cert)? It seems like you're describing E), with the expectation CT logs will accept that certificate. However, Apple also recently shared [2] plans to allow CT logs to reject non-TLS certificates. If the answer to 1/2 is "Yes", then this scheme clearly violates the BRs and E) cannot be issued. If the answer to 1/2 is "No", then it would seem like CT logs would be free to reject E) from being logged, and to reject this Apple-operated CA in the first place (and would benefit the security of users and the WebPKI by doing so). Because it seems these are inherently contradictory, I'm hoping the answer to 3 is that "This certificate" is "A", which makes your later questions more relevant and understandable. But, on the whole, I suspect I'm missing something, because it seems that you might mean "E". And if E is meant, then I think it has significant CT implications that need to also be worked out, separate from the BR question here. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575125 [2] https://groups.google.com/a/chromium.org/g/ct-policy/c/JWVVhZTL5RM/m/HVZdSH4hAQAJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
