Ryan, Thank you for the questions. Answers in line.
Bailey On Friday, October 30, 2020 at 8:43:46 AM UTC-7, Ryan Sleevi wrote: > On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via > dev-security-policy <dev-secur...@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. The Apple CA being used is the "Apple Application Integration CA 6 - G1" issued from the Apple Root CA - G3 (https://crt.sh/?id=12728973). The CPS for that CA is here (https://images.apple.com/certificateauthority/pdf/Apple_AAI_Sub-CA_CPS_v6.7.pdf). It is technically TLS-capable (ie. does not contain any EKU constraints that would prevent it from issuing TLS certificates), but it is only trusted by Apple platforms, so is not subject to the BRs or Mozilla requirements. We designed the certificate profile for these leaf certificates to be TLS incapable: 1) It has no TLS Server Auth EKU 2) It has no SANs 3) The common names are of the form: "Apple CT Log Assurance for blinding factors server: <domain name from TLS cert>" or "Apple CT Log Assurance for blinded value statistics server: <domain name from TLS cert>". > > 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. It is both E and A. All certificates in this scheme are verified to be CT-qualified. Yes, we are aware that CT logs may choose to reject such certificates in the future and are working towards improved solutions. > > [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
