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
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
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
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
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
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
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
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
On Fri, Oct 30, 2020 at 10:49 AM Bailey Basile via dev-security-policy <
dev-security-policy@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
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
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
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
On 2020-10-30 01:50, Matthew Hardeman wrote:
On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy <
dev-security-policy@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
On Thu, 29 Oct 2020 11:06:43 -0700
Jacob Hoffman-Andrews via dev-security-policy
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
>
On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy <
dev-security-policy@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
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
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
On 2020-10-29 19:06, 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:
18 matches
Mail list logo
