TLS certificates for ECIES keys

[Jacob Hoffman-Andrews]

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
certificate for a purpose not indicated by that certificate's EKUs. RFC
5280 says (https://tools.ietf.org/html/rfc5280#section-4.2.1.12):

> 4.2.1.12. Extended Key Usage
> If the extension is present, then the certificate MUST only be used
> for one of the purposes indicated.

The BRs say (
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf):

> 4.9.1.1 Reasons for Revoking a Subscriber Certificate
> The CA SHOULD revoke a certificate within 24 hours and MUST revoke a
Certificate within 5 days if one or more of the following occurs:
> 2. The CA obtains evidence that the Certificate was misused;

"Misused" is not defined here but I think a reasonable interpretation would
be that a Subscriber would trigger the revocation requirement by violating
the EKU MUST from RFC 5280.

I also have a concern about ecosystem impact. The Web PKI and Certificate
Transparency ecosystems have been gradually narrowing their scope - for
instance by requiring single-purpose TLS issuance hierarchies and planning
to restrict CT logs to accepting only certificates with the TLS EKU. New
key distribution systems will find it tempting to reuse the Web PKI by
assigning additional semantics to certificates with the TLS EKU, but this
may make the Web PKI less agile.

I've discussed the plan with Apple, and they're fully aware this is an
unusual and non-ideal use of the Web PKI, and hope to propose a timeline
for a better system soon. One of the constraints operating here is that
Apple has already shipped software implementing the system described above,
and plans to use it in addressing our current, urgent public health crisis.
As far as I know, no publicly trusted Web PKI certificates are currently in
use for this purpose.

So, mdsp folks and root programs: Can a CA or a Subscriber participate in
the above system without violating the relevant requirements?

Thanks,
Jacob

[Jakob Bohm]

Maybe allocate your own OID (within ISRGs own OID space) for this
purpose and put it in the EKU. Something like

iso.org.dod.internet.private.enterprise(1.3.6.1.4.1).isrg(44947).isrg-divisionX(???).priu-processor(1)

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Matthew Hardeman]

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

To the extent that there is misuse in the described use-case, it would be
"misuse" on the part of the relying party software agent (which would be
trusting the certificate with a purpose and role in conflict with the
EKUs), but not misuse on the part of the certificate subscriber.
Publication of a leaf certificate (via various mechanisms) is not unusual
nor cause for alarm or revocation. People public key PIN, though unwise
people also certificate PIN. A key compromise would be different, but
that's not described here.

Would you revoke a properly issued certificate upon proof that some
new-fangled scheme employed by a third-party application acquires a copy of
a TLS Server leaf certificate, chases its validity (save for EKU
impropriety) correctly, and then utilizes the certificate's subject public
key in an unanticipated way? Any competent software developer with basic
PKI understanding and some rules lawyering could get any certificate
revoked at any time in that picture. I would submit that this can not be
the correct analysis, not pragmatically.

The mere fact that a single entity is both the Subscriber and the author of
the Relying Party agent is inconsequential, is it not?

Quite separately, I'm most confused by what kind of aggregate statistics
Prio is purported to be sending and its urgency as a public health matter.
I think I am likely to be unpleased by whatever this thing is, but I
suppose that's not at all germane to the WebPKI question.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matt Palmer]

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

[Matthew Hardeman]

On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

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

To my knowledge, caching/storing a leaf certificate isn't misuse. While
they appear to be presenting it in some manner other than via a TLS
session, I don't believe there's any prohibition against such a thing.
Would it cure the concern if they also actually ran a TLS server that does
effectively nothing at the host name presented in the SAN dnsName?

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

Not all distribution of a leaf certificate is "use", let alone "misuse".
There are applications which certificate PIN rather than key PIN. Is that
misuse?

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

My question is by what rule do you squash this thing that doesn't also
cover a future similar use by a third-party relying party that makes
"additional" use of some subscriber's certificate.

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

Presumably this is so that the data processors can choose a key for the
encryption of their data shards and bind that to a DNS name demonstrated to
be under the data processor's control via a standard CA issuance process
without abstracting the whole thing away to certificates controlled by
Apple and/or Google. To demonstrate that the fractional data shard
holder's domain was externally validated by a party that isn't Apple or
Google.

People scrape and analyze other parties' leaf certificates all the time.
What those third parties do with those certificates (if anything) is up to
those third parties.

If a third party can do things which causes a subscriber's certificate to
be revokable for misuse without having derived or acquired the private key,
I hesitate to call that ridiculous, but it is probably unsustainable.
Extending upon that, if the mere fact that the subscriber and the author of
the relying party validation agent are part of the same corporate hierarchy
changes the decision for the same set of circumstances, that's suspect.

[Nick Lamb]

On Thu, 29 Oct 2020 11:06:43 -0700

Jacob Hoffman-Andrews via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I also have a concern about ecosystem impact. The Web PKI and
> Certificate Transparency ecosystems have been gradually narrowing
> their scope - for instance by requiring single-purpose TLS issuance
> hierarchies and planning to restrict CT logs to accepting only
> certificates with the TLS EKU. New key distribution systems will find
> it tempting to reuse the Web PKI by assigning additional semantics to
> certificates with the TLS EKU, but this may make the Web PKI less
> agile.

This is my main concern too.

I think this is something I would be annoyed to discover some CA has
decided it's allowed to do, even if I wasn't able to come up with a
tortured rationale for why it's prohibited. "It wasn't prohibited" is
not the standard Mozilla asks root programme participants to aim for.
So since I'm being asked, no, I think this is a bad idea.

If we were talking about a subscriber it seems obvious that ISRG needn't
try to police what they get up to, but ISRG itself is different.

> I've discussed the plan with Apple, and they're fully aware this is an
> unusual and non-ideal use of the Web PKI, and hope to propose a
> timeline for a better system soon. One of the constraints operating
> here is that Apple has already shipped software implementing the
> system described above, and plans to use it in addressing our
> current, urgent public health crisis. As far as I know, no publicly
> trusted Web PKI certificates are currently in use for this purpose.

The problem with such timelines is they are too often wishful thinking.
Once the immediate need abates, further action is de-prioritised and
often never happens at all. I suspect we've all experienced this.

ISRG could perhaps avoid that de-prioritization by committing up
front to ceasing the "unusual and non-ideal use" by some specific point
in time agreed with Apple, I don't know whether Apple would be at all
interested in doing that, but it might be enough to ensure that
resources remain properly focused on actually deploying the "better
system" in a timely fashion.


This "urgent public health crisis" is presumably the COVID-19
pandemic. Action in November 2020 or later hardly seems an "urgent"
response to the pandemic and at this point it seems clear that mostly
what matters is political direction rather than IT innovation.

That is to say, I think New Zealand has elimination whereas the USA
has tens of thousands of new cases every day because New Zealand's
political leadership pursued an elimination strategy and the American
government did not, rather than because the NZ COVID Tracer app is
markedly better than similar American software.


Back to the application. I think the desire here is to have
anonymisation because intellectually it seems as though users would be
satisfied that collecting anonymised aggregate statistics is OK where
they'd be trepidatious about any other data collection. Without robust
studies showing this to be true I very much doubt it. Users are not
much impressed by facts, their gut feeling is that collecting data
violates their privacy and the facts won't change that feeling.

> So, mdsp folks and root programs: Can a CA or a Subscriber
> participate in the above system without violating the relevant
> requirements?

I'm not an expert, but I suspect the answer for a CA is that yes, they perhaps can
BUT however they should not.


Nick.

[Jakob Bohm]

Cryptographically, I think the concern is this:

In this scheme, the authenticated server B will use the corresponding
private key in a mathematically complex protocol that is neither TLS nor
CMS. It is conceivable that said protocol may have a weakness that
allows a clever opponent M to exchange traffic with B in order to
discover B's private key.

Thus using a WebPKI "Server Authentication" certificate to bind a public
key used by party A to identify party B in the "prio" protocol creates a
potential risk of creating a family of certificates with easily
compromised keys.

Thus it makes sense for the involved CAs (such as Let's Encrypt) to
issue these certificates with a unique EKU other than the generic
"Server Authentication" traditionally associated with TLS.

[Ryan Sleevi]

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.

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

[Bailey Basile]

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

[Bailey Basile]

Ryan,

Thank you for the questions. Answers in line.

Bailey

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.

[Matthew Hardeman]

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.

[Devon O'Brien]

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

[Bailey Basile]

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

[Bailey Basile]

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

[Matt Palmer]

On Thu, Oct 29, 2020 at 05:04:32PM -0700, Bailey Basile via dev-security-policy 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.

Can you explain how a DV certificate demonstrates that the key in the
certificate is for a third party? Because I can't see how that's possible.

- Matt

[Devon O'Brien]

Hi Jacob,

I’m chiming in in my official capacity as a member of Chrome’s root program and its Certificate Transparency lead.

Over the past several years, the narrowing of scope for both the web PKI and CT has been highly intentional. Great efforts have been made to ensure that use cases outside of TLS do not further ossify a system that often already struggles to meet the agility requirements of its primary use case. For this reason, we are generally opposed to adding external dependencies, such as the ones this feature creates, to both CT and the web PKI. With that being said, the specific requirements applicable to this situation include areas that are underspecified as well as some that are expressed in unclear terms, especially where the requirements involve interplay between the Baseline Requirements (BRs), multiple RFCs, and root program requirements.

Our high-level concerns with this proposal include:
* Adding external (non-TLS) dependencies to CT and the web PKI, which slows both the adoption of ecosystem improvements as well as the deprecation of problematic practices.
* Requiring CAs to knowingly issue publicly-trusted TLS certificates for a definitively non-TLS use, calling into question what “misuse” means in the context of BR section 4.9.1.1.
* Concerns with how the proposed certificate profile, including the semantics for the keyUsage and extendedKeyUsage, fit within the framework of BR section 7.1.2.4, particularly when the CA knowingly issues such certificates.

While we believe that this proposal does not align with the intent of existing requirements, the proposed certificate usage is not unambiguously prohibited. Some of these requirements, such as the BRs, are already in the process of being updated to provide crisper guidance on what is and is not permitted. As maintainers of the Chrome root program and its CT policy, we will similarly work to provide greater clarity going forward by continuing to improve and update our policies.

-Devon

[Jacob Hoffman-Andrews]

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 <js...@letsencrypt.org>

[Bailey Basile]

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=1160190>, https://crt.sh/?id=12727249 <https://crt.sh/?id=12727249>, https://crt.sh/?id=12728973 <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

[Bailey Basile]

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