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
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 par
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 sign
On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2020-10-30 16:29, Rob Stradling wrote:
> >> Perhaps add: "And also include any other certificates sharing the same
> >> private/public key pairs as certificates already included
On 2020-10-30 16:29, Rob Stradling wrote:
Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as certificates already included in the
requirements." (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certi
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
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 progr
> Perhaps add: "And also include any other certificates sharing the same
> private/public key pairs as certificates already included in the
> requirements." (this covers the situation you mentioned where a
> self-signed certificate shares the key pair of a certificate that chains
> to an included
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 i
9 matches
Mail list logo
