Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Sorry! It looks like the attachments didn't come through. Here's each chain:

Prio Statistics Facilitator_ XX.chain.pem
-BEGIN CERTIFICATE-
MIIDmTCCAz+gAwIBAgIQVUMIP1vPOWm3Rozjmb8qYzAKBggqhkjOPQQDAjBZMTUw
MwYDVQQDDCxUZXN0IEFwcGxlIEFwcGxpY2F0aW9uIEludGVncmF0aW9uIENBIDYg
LSBHMTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMjAxMTA1
MTc0MTU0WhcNMjExMjA1MTc0MTU0WjBEMSgwJgYDVQQDDB9QcmlvIFN0YXRpc3Rp
Y3MgRmFjaWxpdGF0b3I6IFhYMRgwFgYDVQQKDA9FeHRlcm5hbCBFbnRpdHkwWTAT
BgcqhkjOPQIBBggqhkjOPQMBBwNCAARFcpbRk+3269K4gP+jBR0my2KYnGwDmBY/
ruIvbV/VZkn7qPdh+de+tXMy2s374RBbwtzEcOwiSikCGQW43Y4fo4IB/DCCAfgw
DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSphcEaCuXYec3we0b6me9LYUdzhDBQ
BggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLXVhdC5jb3Jw
LmFwcGxlLmNvbS9vY3NwMDMtdGVzdGFhaWNhNmcxMDIwggEdBgNVHSAEggEUMIIB
EDCCAQwGCSqGSIb3Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBv
biB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFu
Y2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29u
ZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNh
dGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cHM6Ly93
d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5MBQGA1UdJQQNMAsGCSqG
SIb3Y2QEEjAdBgNVHQ4EFgQUQfM6gfYThdT25wd3RxbSmuX9Ic8wDgYDVR0PAQH/
BAQDAgMIMA8GCSqGSIb3Y2QPAgQCBQAwCgYIKoZIzj0EAwIDSAAwRQIgPk1q++Hg
MorAeWyxJrATByoMUCpFGBhgP3/IdCyhv+QCIQC14+ROFCD8fVRSvtJ8IpvxiR21
f3HfQ72hwcH23jEFQg==
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIC7zCCAnWgAwIBAgIITkSG+diMnpkwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV
UzAeFw0yMDA2MjUyMzQxMjdaFw0zNTA2MjIyMzQxMjdaMFkxNTAzBgNVBAMMLFRl
c3QgQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgNiAtIEcxMRMwEQYD
VQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABBPPW0nKWVaSPVxG1XqV5KCwhB5oPiwTsdxOJqxyahGTd+Og429IC5b1
/tW9pbxPdAPxCfO/ww24m2IrwNNKBpWjggESMIIBDjAPBgNVHRMBAf8EBTADAQH/
MB8GA1UdIwQYMBaAFPxG2INsH+by3N+nmReuC0RnFxtGMFMGCCsGAQUFBwEBBEcw
RTBDBggrBgEFBQcwAYY3aHR0cDovL29jc3AtdWF0LmNvcnAuYXBwbGUuY29tL29j
c3AwMy10ZXN0YXBwbGVyb290Y2FnMzBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8v
Y3JsLXVhdC5jb3JwLmFwcGxlLmNvbS90ZXN0YXBwbGVyb290Y2FnMy5jcmwwHQYD
VR0OBBYEFKmFwRoK5dh5zfB7RvqZ70thR3OEMA4GA1UdDwEB/wQEAwIBBjAQBgoq
hkiG92NkBgIaBAIFADAKBggqhkjOPQQDAwNoADBlAjAosWWcj/xO+fMYIfAAt3Yj
V3ixGnEV0O97PK9PxhxNVRZdG5Lel0yI5Iothth5LbUCMQD0vLB44Q71ik+5I9d1
a4gj3e3K0aAnxIbtS4wkImFsVkJf+isQQ/qg6Cewy1/qy/s=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIICTDCCAdOgAwIBAgIIeDYL9LfItrAwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV
UzAeFw0xNTA0MjIwMzE3NDRaFw00MDEyMjYwMzEzMzdaMGwxIDAeBgNVBAMMF1Rl
c3QgQXBwbGUgUm9vdCBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMw
djAQBgcqhkjOPQIBBgUrgQQAIgNiAASpGmM077ymitYqajgi6SWt2iigScVk/l2R
w2z3meS65CpfYdK/O2yoYRG14Gb3IhGGl13DuhttVX/Q+YDg/9kFrVpbvzp6pwlS
GjF/DKLoEPU208jqoFsKKIUwKF+U9pSjQjBAMB0GA1UdDgQWBBT8RtiDbB/m8tzf
p5kXrgtEZxcbRjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAKBggq
hkjOPQQDAwNnADBkAjAaFDgk/7QIy+rJO9rMgvPZDdErbr8fxBUURN+Ym9fduhu+
T58XpNICdZB9dsyTFi8CMALX2gu+3T3t+aMGkKlYvWt8fOXFTg5EopQvtASazZtp
jSrGHVj/4zK22z40/2dw8Q==
-END CERTIFICATE-

Prio Statistics Public Health Authority_ XX.chain.pem
-BEGIN CERTIFICATE-
MIIDpjCCA0ugAwIBAgIQZWCtfLnEJ/nLAn8jf4PvZTAKBggqhkjOPQQDAjBZMTUw
MwYDVQQDDCxUZXN0IEFwcGxlIEFwcGxpY2F0aW9uIEludGVncmF0aW9uIENBIDYg
LSBHMTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMjAxMTA1
MTc0NjMxWhcNMjExMjA1MTc0NjMxWjBQMTQwMgYDVQQDDCtQcmlvIFN0YXRpc3Rp
Y3MgUHVibGljIEhlYWx0aCBBdXRob3JpdHk6IFhYMRgwFgYDVQQKDA9FeHRlcm5h
bCBFbnRpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATz+VjB1rJUlyBpG2GU
zgHDxmPxlU/OUC7h1G0t2eJ+1p6YJAoKjb5StyMr1xG56jXh1hMNO2gIjR4fKLWs
0iLDo4IB/DCCAfgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSphcEaCuXYec3w
e0b6me9LYUdzhDBQBggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAGGNGh0dHA6Ly9v
Y3NwLXVhdC5jb3JwLmFwcGxlLmNvbS9vY3NwMDMtdGVzdGFhaWNhNmcxMDIwggEd
BgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYM
gbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1
bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0
ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBh
bmQgY2VydGlmaWNhdGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcC
ARYqaHR0cHM6Ly93d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5MBQG
A1UdJQQNMAsGCSqGSIb3Y2QEEjAdBgNVHQ4EFgQUtU8ZKOoMjTH7wC/dbwzyADjn
PmcwDgYDVR0PAQH/BAQDAgMIMA8GCSqGSIb3Y2QPAwQCBQAwCgYIKoZIzj0EAwID
SQAwRgIhANujqz+wx8Aoyp3/dZZ1sxEezPzJyA42SC15i46ImRMrAiEAqhOjoDKf
/IAN+Qz0hKmHcIi3SErOWTgR1Fffn5cZVfE=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIC7zCCAnWgAwIBAgIITkSG+diMnpkwCgYIKoZIzj0EAwMwbDEgMB4GA1UEAwwX
VGVzdCBBcHBsZSBSb290IENBIC0gRzMxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJV

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Hi, all,

Thank you for your feedback on this project. In order to address your comments, 
we have adjusted our design and implementation so that publicly-trusted 
certificates are no longer used and have modified our use of Certificate 
Transparency.

All certificates for encrypting data for Prio will be issued by Apple to the 
processors under our “semi-private” roots (i.e. https://crt.sh/?id=1160190 
, https://crt.sh/?id=12727249 
, https://crt.sh/?id=12728973 
). These certificates will have a Key Usage of Key 
Agreement and an Extended Key Usage containing an Apple OID 
(1.2.840.113635.100.4.18). The Common Name will contain an entity name 
(expected to be an ISO 3166 country or region code, but will be defined by 
Apple during configuration of the processor) for the benefit of users reviewing 
the keys and certificates used to encrypt their data.

Attached are certificate chains issued from our test roots under these profiles.


The production certificates will include SCTs from CT logs usable on Apple’s 
platforms. In order to address concerns about the future direction of the CT 
ecosystem, Apple clients will maintain two distinct log lists of qualified logs 
— those that are permitted for TLS only and those that allow other EKUs. These 
new certificates will be qualified against the latter list, while TLS 
certificates will continue to be qualified against the former. Today these 
lists are the same, but we expect them to diverge as the CT ecosystem 
progresses.

Thanks,

Bailey

> On Nov 4, 2020, at 2:12 PM, Jacob Hoffman-Andrews  
> wrote:
> 
> Thanks to all here for the useful feedback. We've decided not to issue
> publicly trusted TLS certificates carrying keys for use in ECIES.
> 
> On Thu, Oct 29, 2020 at 11:06 AM Jacob Hoffman-Andrews 
> wrote:
> 
>> Hi all,
>> 
>> ISRG is working with Apple and Google to deploy Prio, a
>> "privacy-preserving system for the collection of aggregate statistics:"
>> https://crypto.stanford.edu/prio/. Mozilla has previously demonstrated
>> Prio for use with telemetry data:
>> https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with-prio/
>> and
>> https://blog.mozilla.org/security/2019/06/06/next-steps-in-privacy-preserving-telemetry-with-prio.
>> Part of the plan involves using Web PKI certificates in an unusual way, so
>> I wanted to get feedback from the community and root programs.
>> 
>> In Prio, clients (mobile devices in this case) generate "shares" of data
>> to be sent to non-colluding processors. Those processors calculate
>> aggregate statistics without access to the underlying data, and their
>> output is combined to determine the overall statistic - for instance, the
>> number of users who clicked a particular button. The goal is that no party
>> learns the information for any individual user.
>> 
>> As part of this particular deployment, clients encrypt their shares to
>> each processor (offline), and then send the resulting encrypted "packets"
>> of share data via Apple and Google servers to the processors (of which ISRG
>> would be one). The encryption scheme here is ECIES (
>> https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme).
>> 
>> The processors need some way to communicate their public keys to clients.
>> The current plan is this: A processor chooses a unique, public domain name
>> to identify its public key, and proves control of that name to a Web PKI
>> CA. The processor requests issuance of a TLS certificate with
>> SubjectPublicKeyInfo set to the P-256 public key clients will use to
>> encrypt data share packets to that processor. Note that this certificate
>> will never actually be used for TLS.
>> 
>> 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.
>> 
>> The Prio client software on the devices receives both the TLS and non-TLS
>> certificate from their OS vendor, and validates both, checking OCSP and CT
>> requirements, and checking that the public key hash in the non-TLS
>> certificate's special purpose extension matches the SubjectPublicKeyInfo in
>> the TLS certificate. If validation passes, the client software will use
>> that public key to encrypt data share packets.
>> 
>> The main issue I see is that the processor (a Subscriber) is using the TLS

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Hi, Matt,

I'm sorry. I can't speak to the UI design at this time or in this forum, but 
transparency to users and verifiability of the privacy claims were of the 
utmost importance to the engineering teams.

Bailey

On Friday, October 30, 2020 at 1:11:07 PM UTC-7, mhar...@gmail.com wrote:
> On Fri, Oct 30, 2020 at 10:49 AM Bailey Basile via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > 
> > We specifically chose not to issue Apple certificates for these keys 
> > because we did not want users to have to trust only Apple's assertion that 
> > this key is for a third party. 
> > 
> >
> I understand the goal of having an external CA certify the domain name of 
> the data processing participants' certificate (and associated key), but... 
> What UI experience makes any of this relevant to the user? Is there going 
> to be a UI screen in the platform in which the user can view and/or choose 
> what parties (presumably by domain name) they will be submitting data 
> shares to? Will that UI be displaying any of the certificates, key hashes, 
> or public keys involved? 
> 
> I think domain validation for this kind of thing is pretty weak 
> regardless. If Apple wanted to, they could just register 
> super-trusted-data-process-namealike.com, get ISRG to issue a WebPKI cert 
> for that and then incorporate that certificate in this scheme. DNS based 
> validations don't demonstrate that the target is truly independent of Apple.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

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  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: " or "Apple CT Log Assurance for 
> > blinded value statistics server: ". 
> > > 
> > > 3) Is "This certificate is submitted to CT" referring to A) (ISRG cert) 
> > > or 
> > > E) (Apple cert)? 
> > > 
> > > It seems like 

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

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  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: " or "Apple CT Log Assurance for 
blinded value statistics server: ".

> 
> 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

Re: TLS certificates for ECIES keys

[Bailey Basile via dev-security-policy]

Hi, Matt,

We thought hard about the agility concerns for this particular application and 
the impact to the WebPKI and CT ecosystems. First, 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. Second, we are automating the entire process by which partners 
can submit their third-party-issued TLS certificates and the configuration is 
deployed to clients. Furthermore, the clients are able to get updated 
configuration within twenty-four hours. Additionally, as Jacob indicated, we 
consider this a relatively short-term solution in order to provide Public 
Health Authorities necessary statistics to respond to the current public health 
crisis and will be adopting a different solution in a future release. If you 
have specific question or concerns about how the agility of this architecture 
would negatively impact the WebPKI, I am happy to answer those.

We specifically chose not to issue Apple certificates for these keys because we 
did not want users to have to trust only Apple's assertion that this key is for 
a third party.

Bailey

On Thursday, October 29, 2020 at 4:30:19 PM UTC-7, Matt Palmer wrote:
> On Thu, Oct 29, 2020 at 01:56:53PM -0500, Matthew Hardeman via 
> dev-security-policy wrote: 
> > IFF the publicly trusted certificate for the special domain name is 
> > acquired in the normal fashion and is issued from the normal leaf 
> > certificate profile at LE, I don't see how the certificate could be claimed 
> > to be "misused" _by the subscriber_.
> The way I read Jacob's description of the process, the subscriber is 
> "misusing" the certificate because they're not going to present it to TLS 
> clients to validate the identity of a TLS server, but instead they (the 
> subscriber) presents the certificate to Apple (and other OS vendors?) when 
> they know (or should reasonably be expected to know) that the certificate is 
> not going to be used for TLS server identity verification -- specifically, 
> it's instead going to be presented to Prio clients for use in some sort of 
> odd processor identity parallel-verification dance. 
> 
> Certainly, whatever's going on with the certificate, it most definitely 
> *isn't* TLS, and so absent an EKU that accurately describes that other 
> behaviour, 
> I can't see how it doesn't count as "misuse", and since the subscriber has 
> presented the certificate for that purpose, it seems reasonable to describe 
> it as "misuse by the subscriber". 
> 
> Although misuse is problematic, the concerns around agility are probably 
> more concerning, IMO. There's already more than enough examples where 
> someone has done something "clever" with the WebPKI, only to have it come 
> back and bite everyone *else* in the arse down the track -- we don't need to 
> add another candidate at this stage of the game. On that basis alone, I 
> think it's worthwhile to try and squash this thing before it gets any more 
> traction. 
> 
> Given that Apple is issuing another certificate for each processor anyway, I 
> don't understand why they don't just embed the processor's SPKI directly in 
> that certificate, rather than a hash of the SPKI. P-256 public keys (in 
> compressed form) are only one octet longer than a SHA-256 hash. But 
> presumably there's a good reason for not doing that, and this isn't the 
> relevant forum for discussing such things anyway. 
> 
> - Matt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy