Hi, Devon, The policy that evaluates the publicly-trusted certificates (note that there is no requirement that ISRG be the issuer for these certificates) does require id-kp-serverAuth. Yes, changing to a non-TLS certificate would require a change to the Apple clients and would require an operating system software update.
Bailey On Friday, October 30, 2020 at 1:56:31 PM UTC-7, Devon O'Brien wrote: > Hi Bailey, > > You mention that all certificates involved in this design are checked for > expiration, revocation, and Certificate Transparency using all of the same > logic that verifies TLS certificates on Apple platforms, but notably, the > custom evaluation policy for the Apple-issued certificate can't require a > id-kp-serverAuth EKU since none are present. > > Does the policy that evaluates the ISRG-issued processor certificate require > any particular EKUs, (e.g. id-kp-serverAuth)? > > Would issuing the processor a non-TLS certificate require a change to Apple > clients, and if so, would such a change be a blocker to shipping this > feature? > > -Devon > On Friday, October 30, 2020 at 12:35:15 PM UTC-7, Bailey Basile wrote: > > 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
