There's a problem with this framing, and this was the earlier reference to
Jeremy about Yu-gi-oh!
From that earlier response:
> Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued
But the pre-cert exists and the pre-cert is a cert. I should be able to tell
the status of a pre-cert because it really is a certificate.
-Original Message-
From: dev-security-policy On
Behalf Of Tim Shirley via dev-security-policy
Sent: Thursday, September 12, 2019 6:21 PM
To: r...@sle
Why would a user agent view a pre-certificate as "evidence that an equivalent
certificate exists"? It's evidence that it might exist.. That the CA had the
intent to make it exist at the time they signed the precertificate.. But I
can't find anything in RFC 6962 that suggests to me that if the
Neil's interpretation of my poorly-worded question was correct - thank you
and apologies for the confusion.
On Thu, Sep 12, 2019 at 5:39 PM Ryan Sleevi wrote:
>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Should a CA
Without wanting to be antagonistic, I've come to learn I can count on you
to suggest that X deserves clarification because it's ambiguous, but I've
also learned I have trouble learning where the ambiguity exists or why.
Recall that part of this confusion, regrettably, came from an earnest
attempt t
On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OC
Certainly we (as a CA who uses such precertificate-signing CAs) never
interpreted RFC 6962 or the other requirements as mandating or even suggesting
that, for either of the possible interpretations of Alex's question. As soon
as you hit the precertificate-signing CA in the validation path you'v
So, this is something that would be helpfully clarified via either an IETF
draft, or clarifications in the BRs. There are various things in the OCSP RFCs
and even the BRs that can be read as precluding good OCSP responses for
pre-certificates, although the situation is unclear since the relevan
> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy
> wrote:
>
> The language says you have to provide the response for the cert as if it
> exists, but the reality is that sending a response for the precert is the
> same as calculating the result for the certificate as if it ex
The language says you have to provide the response for the cert as if it
exists, but the reality is that sending a response for the precert is the same
as calculating the result for the certificate as if it exists and sending that.
They are the same thing because the precert is treated the same
On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as
> if corresponding certificat
11 matches
Mail list logo