Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Ryan Sleevi via dev-security-policy]

On Tue, Sep 3, 2019 at 2:18 PM Santhan via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews
> wrote:
> > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> >
> > On 2019.08.28 we read Apple’s bug report at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s
> OCSP responder returning incorrect results for a precertificate. This
> prompted us to run our own investigation. We found in an initial review
> that for 35 of our precertificates, we were serving incorrect OCSP results
> (“unauthorized” instead of “good”). Like DigiCert, this happened when a
> precertificate was issued, but the corresponding certificate was not issued
> due to an error.
> >
> > We’re taking these additional steps to ensure a robust fix:
> >   - For each precertificate issued according to our audit logs, verify
> that we are serving a corresponding OCSP response (if the precertificate is
> currently valid).
> >   - Configure alerting for the conditions that create this problem, so
> we can fix any instances that arise in the short term.
> >   - Deploy a code change to Boulder to ensure that we serve OCSP even if
> an error occurs after precertificate issuance.
>
> Out of curiosity, what software is checking OCSP for a pre-cert and why?
> Why does any software need the OCSP status of a pre-cert when it doesn't
> have the corresponding final cert?


It's a good question, and worth asking, although when framing, it might be
useful to think/explore why *shouldn't* software be able to do so.

There's no requirement to log the corresponding final certificate to CT
Logs, and some CAs may choose to not do so in order to minimize the rate
limits or the baseline growth rate of CT Logs, especially if those final
certificates are functionally short-lived (e.g. some CAs issuing at 8 hour
intervals).

Yet those examining CT Logs for compliance issues have a reasonable basis
for examining whether or not an associated pre-certificate is revoked,
regardless of its overall compliance status with the requirements. That is,
it's useful not only to know what's bad and is/isn't revoked, but also what
is good, and is/isn't revoked. The latter is useful, for example, when
examining impact to the ecosystem for changes, such as changes in a trust
status for CAs, by examining whether or not the associated certificate(s)
are still valid or have been revoked. Another reason is for revocation
systems that try to comprehensively determine the status of published
certificates, since CRLs are not inherently required to be used (example:
CRLlite)

In terms of process/flow though, my earlier point is that CT Logs define
their incorporation timelines in terms of Maximum Merge Delay, rather than
Minimum. It's entirely possible for a CT Log to incorporate (and publicize)
a pre-cert within seconds, allowing CT Log Monitors to pick it up. If those
Monitors then query the status information, it's possible that they could
cause one or more intermediaries to return that cached information, even
after the 'final' certificate has been issued. This was part of the
operational complexity I was mentioning and mentioned on the associated
bug. By ensuring publication of the 'correct'/'expected' information prior
to the publication of the pre-cert (if pre-certs are used) or the final
cert, this minimizes the risk of getting into an intermittent bad state. Is
it possible to defer publishing and still get the correct result?
Absolutely. It just requires much more care, and given situations like
"Default City" and "Some State" in certificates, perhaps it's better to be
safe by default.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Santhan via dev-security-policy]

On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews wrote:
> Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> 
> On 2019.08.28 we read Apple’s bug report at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
> responder returning incorrect results for a precertificate. This prompted us 
> to run our own investigation. We found in an initial review that for 35 of 
> our precertificates, we were serving incorrect OCSP results (“unauthorized” 
> instead of “good”). Like DigiCert, this happened when a precertificate was 
> issued, but the corresponding certificate was not issued due to an error.
> 
> We’re taking these additional steps to ensure a robust fix:
>   - For each precertificate issued according to our audit logs, verify that 
> we are serving a corresponding OCSP response (if the precertificate is 
> currently valid).
>   - Configure alerting for the conditions that create this problem, so we can 
> fix any instances that arise in the short term.
>   - Deploy a code change to Boulder to ensure that we serve OCSP even if an 
> error occurs after precertificate issuance.

Out of curiosity, what software is checking OCSP for a pre-cert and why? Why 
does any software need the OCSP status of a pre-cert when it doesn't have the 
corresponding final cert?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jakob Bohm via dev-security-policy]

On 03/09/2019 00:54, Ryan Sleevi wrote:
> On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> If an OCSP server supports returning (or always returns) properties of
>>> the actual cert, such as the CT proofs, then it really cannot do its
>>> usual "good" responses until the process of retrieving CT proofs and
>>> creating the final TBScertificate (and possibly signing it) has been
>>> completed.
>>>
>>> Thus as a practical matter, treating a sign-CT-sign-CT in-process state
>>> as "unknown serial, may issue in future" may often be the only practical
>>> solution.
>>>
>>
>> Waiting until CT submission of the final certificate is complete to return
>> "good" OCSP responses is definitely wrong. OCSP should return "good" at the
>> moment the final certificate is issued, which means in practice that there
>> might be a "good" OCSP response that doesn't contain SCTs yet.
>>
>> I don't know if any log does this, but RFC6962 allows logs to check for
>> certificate revocation before issuing a SCT; if the OCSP responder doesn't
>> return "good" the CA might never get the needed SCTs?
> 
> 
> Correct. Which is why I recommend CAs ignore Jakob Bohm’s advice here, as
> it can lead to a host of complications for CAs, Subscribers, and Relying
> Parties.
> 

I was not advising either cause of action, I was trying to explore 
conflicting requirements between the BRs, PKIX and the CT spec, which 
has apparently lead to confusion as to the what OCSP should return for 
soon-to-be-issued and not-yet-issued certificates.

This particular CT requirement contradicted a common Google practice 
across its services, which made me suspect it might be a specification 
oversight rather than intentional.


> 
>>
>> Also, if a CA is signing a precert, getting SCTs for that precert, then
>> embedding the SCTs in the final cert, they are already satisfying the
>> browsers' CT requirements. It would not be necessary for them to
>> additionally embed SCTs for the final cert in their OCSP responses.
>>
>> Now depending on interpretations, I am unsure if returning "revoked" for
>>> the general case of "unknown serial, may issue in future" would violate
>>> the ban on unrevoking certificates.
>>>
>>
>> RFC6960 section 2.2 documents a technique for indicating "unknown serial,
>> may issue in future" that involves returning "revoked" with a revocation
>> date of 1970-1-1 and a reason of certificateHold. I don't know if this
>> technique is used anywhere in practice - IIRC it requires the OCSP signing
>> key to be online and able to sign responses for arbitrary serial numbers in
>> real time.
> 
> 
> The BRs explicitly prohibit this.
> 
> You cannot unrevoke or suspend.
> 

That was my interpretation too.

> (Are any CAs even using the OCSP SCT delivery option? I haven't come across
>> this technique in the wild)
> 
> 
> Yes, several are.
> 


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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > If an OCSP server supports returning (or always returns) properties of
> > the actual cert, such as the CT proofs, then it really cannot do its
> > usual "good" responses until the process of retrieving CT proofs and
> > creating the final TBScertificate (and possibly signing it) has been
> > completed.
> >
> > Thus as a practical matter, treating a sign-CT-sign-CT in-process state
> > as "unknown serial, may issue in future" may often be the only practical
> > solution.
> >
>
> Waiting until CT submission of the final certificate is complete to return
> "good" OCSP responses is definitely wrong. OCSP should return "good" at the
> moment the final certificate is issued, which means in practice that there
> might be a "good" OCSP response that doesn't contain SCTs yet.
>
> I don't know if any log does this, but RFC6962 allows logs to check for
> certificate revocation before issuing a SCT; if the OCSP responder doesn't
> return "good" the CA might never get the needed SCTs?


Correct. Which is why I recommend CAs ignore Jakob Bohm’s advice here, as
it can lead to a host of complications for CAs, Subscribers, and Relying
Parties.


>
> Also, if a CA is signing a precert, getting SCTs for that precert, then
> embedding the SCTs in the final cert, they are already satisfying the
> browsers' CT requirements. It would not be necessary for them to
> additionally embed SCTs for the final cert in their OCSP responses.
>
> Now depending on interpretations, I am unsure if returning "revoked" for
> > the general case of "unknown serial, may issue in future" would violate
> > the ban on unrevoking certificates.
> >
>
> RFC6960 section 2.2 documents a technique for indicating "unknown serial,
> may issue in future" that involves returning "revoked" with a revocation
> date of 1970-1-1 and a reason of certificateHold. I don't know if this
> technique is used anywhere in practice - IIRC it requires the OCSP signing
> key to be online and able to sign responses for arbitrary serial numbers in
> real time.


The BRs explicitly prohibit this.

You cannot unrevoke or suspend.

(Are any CAs even using the OCSP SCT delivery option? I haven't come across
> this technique in the wild)


Yes, several are.

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

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Mon, Sep 2, 2019 at 1:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/09/2019 20:13, Alex Cohn wrote:
> > On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > Waiting until CT submission of the final certificate is complete to
> return
> > "good" OCSP responses is definitely wrong. OCSP should return "good" at
> the
> > moment the final certificate is issued, which means in practice that
> there
> > might be a "good" OCSP response that doesn't contain SCTs yet.
> >
> > I don't know if any log does this, but RFC6962 allows logs to check for
> > certificate revocation before issuing a SCT; if the OCSP responder
> doesn't
> > return "good" the CA might never get the needed SCTs?
> >
>
> This seems to be an unfortunate aspect of the CT spec that wasn't
> thought through properly.  In particular, it should cause unnecessary
> delay if a CA updates its OCSP servers using "eventual consistency"
> principles.  Maybe it should be fixed in the next update of the spec.
>
> The BRs have the following requirements that are best satisfied by
> delayed update of OCSP servers:
>
> BR4.10.2 The OCSP servers must be up 24x7 .  Thus rolling out updates to
> different servers at different times would be a typical best practice.
>
> BR4.9.10 The OCSP servers only need to be updated twice a week (4 days)
> ..  This could only satisfy the CT requirement if issued certificates
> were somehow withheld from the subscriber for up to 4 days.
>

Withholding certificates for four days would be a huge competitive
disadvantage for a CA. If I were a CA relying on OCSP delivery of SCTs, I
would try to make absolutely sure my OCSP responders could be updated with
SCTs in a timely manner after initial issuance. Since this SCT delivery
method relies on OCSP stapling to work, I could even tell my customers to
configure their web servers with a special OCSP server URL (using, e.g.,
nginx's ssl_stapling_responder directive) that would block until a response
with embedded SCTs could be created.


> > RFC6960 section 2.2 documents a technique for indicating "unknown serial,
> > may issue in future" that involves returning "revoked" with a revocation
> > date of 1970-1-1 and a reason of certificateHold. I don't know if this
> > technique is used anywhere in practice - IIRC it requires the OCSP
> signing
> > key to be online and able to sign responses for arbitrary serial numbers
> in
> > real time.
> >
>
> The question was if this technique would be in violation of the BRs, as
> those generally prohibit the use of "certificateHold" .
>

Where is this prohibition in the BRs? The only relevant section I could
find is 4.9.13, which prohibits suspension of certificates. This isn't
suspension of a certificate; the certificate doesn't exist.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jakob Bohm via dev-security-policy]

On 02/09/2019 20:13, Alex Cohn wrote:

On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


If an OCSP server supports returning (or always returns) properties of
the actual cert, such as the CT proofs, then it really cannot do its
usual "good" responses until the process of retrieving CT proofs and
creating the final TBScertificate (and possibly signing it) has been
completed.

Thus as a practical matter, treating a sign-CT-sign-CT in-process state
as "unknown serial, may issue in future" may often be the only practical
solution.



Waiting until CT submission of the final certificate is complete to return
"good" OCSP responses is definitely wrong. OCSP should return "good" at the
moment the final certificate is issued, which means in practice that there
might be a "good" OCSP response that doesn't contain SCTs yet.

I don't know if any log does this, but RFC6962 allows logs to check for
certificate revocation before issuing a SCT; if the OCSP responder doesn't
return "good" the CA might never get the needed SCTs?



This seems to be an unfortunate aspect of the CT spec that wasn't
thought through properly.  In particular, it should cause unnecessary
delay if a CA updates its OCSP servers using "eventual consistency"
principles.  Maybe it should be fixed in the next update of the spec.

The BRs have the following requirements that are best satisfied by
delayed update of OCSP servers:

BR4.10.2 The OCSP servers must be up 24x7 .  Thus rolling out updates to
different servers at different times would be a typical best practice.

BR4.9.10 The OCSP servers only need to be updated twice a week (4 days) 
..  This could only satisfy the CT requirement if issued certificates 
were somehow withheld from the subscriber for up to 4 days.




Also, if a CA is signing a precert, getting SCTs for that precert, then
embedding the SCTs in the final cert, they are already satisfying the
browsers' CT requirements. It would not be necessary for them to
additionally embed SCTs for the final cert in their OCSP responses.

Now depending on interpretations, I am unsure if returning "revoked" for

the general case of "unknown serial, may issue in future" would violate
the ban on unrevoking certificates.



RFC6960 section 2.2 documents a technique for indicating "unknown serial,
may issue in future" that involves returning "revoked" with a revocation
date of 1970-1-1 and a reason of certificateHold. I don't know if this
technique is used anywhere in practice - IIRC it requires the OCSP signing
key to be online and able to sign responses for arbitrary serial numbers in
real time.



The question was if this technique would be in violation of the BRs, as
those generally prohibit the use of "certificateHold" .


(Are any CAs even using the OCSP SCT delivery option? I haven't come across
this technique in the wild)

Alex




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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> If an OCSP server supports returning (or always returns) properties of
> the actual cert, such as the CT proofs, then it really cannot do its
> usual "good" responses until the process of retrieving CT proofs and
> creating the final TBScertificate (and possibly signing it) has been
> completed.
>
> Thus as a practical matter, treating a sign-CT-sign-CT in-process state
> as "unknown serial, may issue in future" may often be the only practical
> solution.
>

Waiting until CT submission of the final certificate is complete to return
"good" OCSP responses is definitely wrong. OCSP should return "good" at the
moment the final certificate is issued, which means in practice that there
might be a "good" OCSP response that doesn't contain SCTs yet.

I don't know if any log does this, but RFC6962 allows logs to check for
certificate revocation before issuing a SCT; if the OCSP responder doesn't
return "good" the CA might never get the needed SCTs?

Also, if a CA is signing a precert, getting SCTs for that precert, then
embedding the SCTs in the final cert, they are already satisfying the
browsers' CT requirements. It would not be necessary for them to
additionally embed SCTs for the final cert in their OCSP responses.

Now depending on interpretations, I am unsure if returning "revoked" for
> the general case of "unknown serial, may issue in future" would violate
> the ban on unrevoking certificates.
>

RFC6960 section 2.2 documents a technique for indicating "unknown serial,
may issue in future" that involves returning "revoked" with a revocation
date of 1970-1-1 and a reason of certificateHold. I don't know if this
technique is used anywhere in practice - IIRC it requires the OCSP signing
key to be online and able to sign responses for arbitrary serial numbers in
real time.

(Are any CAs even using the OCSP SCT delivery option? I haven't come across
this technique in the wild)

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jakob Bohm via dev-security-policy]

If an OCSP server supports returning (or always returns) properties of 
the actual cert, such as the CT proofs, then it really cannot do its 
usual "good" responses until the process of retrieving CT proofs and 
creating the final TBScertificate (and possibly signing it) has been 
completed.

Thus as a practical matter, treating a sign-CT-sign-CT in-process state 
as "unknown serial, may issue in future" may often be the only practical 
solution.

Now depending on interpretations, I am unsure if returning "revoked" for 
the general case of "unknown serial, may issue in future" would violate 
the ban on unrevoking certificates.

On 31/08/2019 17:07, Jeremy Rowley wrote:
> Obviously I think good is the best answer based on my previous posts. A 
> precert is still a cert. But I can see how people could disagree with me.
> 
> From: dev-security-policy  on 
> behalf of Jeremy Rowley via dev-security-policy 
> 
> Sent: Saturday, August 31, 2019 9:05:24 AM
> To: Tomas Gustavsson ; 
> mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
> for Some Precertificates
> 
> I dont recall the cab forum ever contemplating or discussing  ocsp for 
> precertificates. The requirement to provide responses is pretty clear, but 
> what that response should be is a little confusing imo.
> ...


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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Tomas Gustavsson via dev-security-policy]

On Friday, August 30, 2019 at 8:58:17 PM UTC+2, Ryan Sleevi wrote:
> On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <



> Despite all of the writing above, I'm too lazy to copy/paste my comment
> from the Let's Encrypt issue, but I would hope any CA contemplating things
> should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in
> terms of a possible 'ideal' flow, and to share concerns or considerations
> with that. Even better would be CAs that have suggestions on how best to
> codify and memorialize that suggestion, if it's sensible and correct.

I added a comment to the bugzilla. I think there are several ways the process 
can be made safe, depending on the way a CA operates and which technologies are 
used.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Tomas Gustavsson via dev-security-policy]

On Saturday, August 31, 2019 at 5:07:48 PM UTC+2, Jeremy Rowley wrote:
> Obviously I think good is the best answer based on my previous posts. A 
> precert is still a cert. But I can see how people could disagree with me.

I don't see anything fundamentally wrong with either approach. Since BR 4.9.10 
has a four day update window it would typically, within the BR limits, only be 
an internal exercise for the CA. 

BR 4.9.10:
"For the status of Subscriber Certificates:
The CA SHALL update information provided via an Online Certificate Status 
Protocol at least every four days."

> 
> From: dev-security-policy  on 
> behalf of Jeremy Rowley via dev-security-policy 
> 
> Sent: Saturday, August 31, 2019 9:05:24 AM
> To: Tomas Gustavsson ; 
> mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
> for Some Precertificates
> 
> I dont recall the cab forum ever contemplating or discussing  ocsp for 
> precertificates. The requirement to provide responses is pretty clear, but 
> what that response should be is a little confusing imo.
> 
> From: dev-security-policy  on 
> behalf of Tomas Gustavsson via dev-security-policy 
> 
> Sent: Saturday, August 31, 2019 9:00:08 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
> for Some Precertificates
> 
> On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote:
> > >From RFC6962:
> >
> > “As above, the Precertificate submission MUST be accompanied by the 
> > Precertificate Signing Certificate, if used, and all additional 
> > certificates required to verify the chain up to an accepted root 
> > certificate.  The signature on the TBSCertificate indicates the certificate 
> > authority's intent to issue a certificate.  This intent is considered 
> > binding (i.e., misissuance of the Precertificate is considered equal to 
> > misissuance of the final certificate).  Each log verifies the 
> > Precertificate signature chain and issues a Signed Certificate Timestamp on 
> > the corresponding TBSCertificate.”
> >
> > >From 7.1.2.5 of the baseline requirements:
> > “For purposes of clarification, a Precertificate, as described in RFC 6962 
> > – Certificate Transparency, shall not be considered to be a “certificate” 
> > subject to the requirements of RFC 5280 - Internet X.509 Public Key 
> > Infrastructure Certificate and Certificate Revocation List (CRL) Profile 
> > under these Baseline Requirements”
> >
> > >From 6960:
> >The "good" state indicates a positive response to the status inquiry.  
> > At a minimum, this positive response indicates that no certificate with the 
> > requested certificate serial number currently within its validity interval 
> > is revoked.  This state does not necessarily mean that the certificate was 
> > ever issued or that the time at which the response was produced is within 
> > the certificate's validity interval. Response extensions may be used to 
> > convey additional information on assertions made by the responder regarding 
> > the status of the certificate, such as a positive statement about issuance, 
> > validity, etc.
> >
> >The "revoked" state indicates that the certificate has been revoked, 
> > either temporarily (the revocation reason is certificateHold) or 
> > permanently.  This state MAY also be returned if the associated CA has no 
> > record of ever having issued a certificate with the certificate serial 
> > number in the request, using any current or previous issuing key (referred 
> > to as a "non-issued" certificate in this document).
> >
> >The "unknown" state indicates that the responder doesn't know about the 
> > certificate being requested, usually because the request indicates an 
> > unrecognized issuer that is not served by this responder.”
> >
> > Mozilla Policy:
> >
> > 1.  Does not define a precertificate. Instead Mozilla policy covers 
> > everything with serverAuth (1.1)
> >
> > 2.  Requires functioning OCSP if the certificate contains an AIA (5.2)
> >
> > 3.  Must provide revocation information via the AIA for the cert (6)
> >
> > Argument for responding “Good”:
> > A pre-certificate is a certificate and contains an AIA. Per the Mozilla 
> > policy, the CA must provide services. Providing revoked or unknown is 
> > incorrect because the pre-cert did issue. Although the BRs define the 
> > pre-

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

Obviously I think good is the best answer based on my previous posts. A precert 
is still a cert. But I can see how people could disagree with me.

From: dev-security-policy  on 
behalf of Jeremy Rowley via dev-security-policy 

Sent: Saturday, August 31, 2019 9:05:24 AM
To: Tomas Gustavsson ; 
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

I dont recall the cab forum ever contemplating or discussing  ocsp for 
precertificates. The requirement to provide responses is pretty clear, but what 
that response should be is a little confusing imo.

From: dev-security-policy  on 
behalf of Tomas Gustavsson via dev-security-policy 

Sent: Saturday, August 31, 2019 9:00:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote:
> >From RFC6962:
>
> “As above, the Precertificate submission MUST be accompanied by the 
> Precertificate Signing Certificate, if used, and all additional certificates 
> required to verify the chain up to an accepted root certificate.  The 
> signature on the TBSCertificate indicates the certificate authority's intent 
> to issue a certificate.  This intent is considered binding (i.e., misissuance 
> of the Precertificate is considered equal to misissuance of the final 
> certificate).  Each log verifies the Precertificate signature chain and 
> issues a Signed Certificate Timestamp on the corresponding TBSCertificate.”
>
> >From 7.1.2.5 of the baseline requirements:
> “For purposes of clarification, a Precertificate, as described in RFC 6962 – 
> Certificate Transparency, shall not be considered to be a “certificate” 
> subject to the requirements of RFC 5280 - Internet X.509 Public Key 
> Infrastructure Certificate and Certificate Revocation List (CRL) Profile 
> under these Baseline Requirements”
>
> >From 6960:
>The "good" state indicates a positive response to the status inquiry.  At 
> a minimum, this positive response indicates that no certificate with the 
> requested certificate serial number currently within its validity interval is 
> revoked.  This state does not necessarily mean that the certificate was ever 
> issued or that the time at which the response was produced is within the 
> certificate's validity interval. Response extensions may be used to convey 
> additional information on assertions made by the responder regarding the 
> status of the certificate, such as a positive statement about issuance, 
> validity, etc.
>
>The "revoked" state indicates that the certificate has been revoked, 
> either temporarily (the revocation reason is certificateHold) or permanently. 
>  This state MAY also be returned if the associated CA has no record of ever 
> having issued a certificate with the certificate serial number in the 
> request, using any current or previous issuing key (referred to as a 
> "non-issued" certificate in this document).
>
>The "unknown" state indicates that the responder doesn't know about the 
> certificate being requested, usually because the request indicates an 
> unrecognized issuer that is not served by this responder.”
>
> Mozilla Policy:
>
> 1.  Does not define a precertificate. Instead Mozilla policy covers 
> everything with serverAuth (1.1)
>
> 2.  Requires functioning OCSP if the certificate contains an AIA (5.2)
>
> 3.  Must provide revocation information via the AIA for the cert (6)
>
> Argument for responding “Good”:
> A pre-certificate is a certificate and contains an AIA. Per the Mozilla 
> policy, the CA must provide services. Providing revoked or unknown is 
> incorrect because the pre-cert did issue. Although the BRs define the 
> pre-cert as out of scope of the BRs for CRLs and 5280, that just means the 
> serial number can repeat. Responding anything other than good would provide 
> wrong information about the status of the pre-cert.
>
> Argument for responding “Revoked”, “Unknown”, or “Invalid”:
> A pre-certificate is not a cert. The BRs define it as a not a cert as does 
> RFC 6962. A pre-cert is an intent to issue a certificate. RFC6960 
> specifically calls out that the CA may use revoke as a response for 
> certificates without a record of being issued and unknown where there isn’t a 
> status yet. Although the Mozilla policy is silent on the status of whether a 
> pre-cert is a certificate, section 2.3 incorporates the baseline 
> requirements. As such, the Mozilla policy implicitly defines a precertificate 
> as “not a certificate”. Bec

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

I dont recall the cab forum ever contemplating or discussing  ocsp for 
precertificates. The requirement to provide responses is pretty clear, but what 
that response should be is a little confusing imo.

From: dev-security-policy  on 
behalf of Tomas Gustavsson via dev-security-policy 

Sent: Saturday, August 31, 2019 9:00:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote:
> >From RFC6962:
>
> “As above, the Precertificate submission MUST be accompanied by the 
> Precertificate Signing Certificate, if used, and all additional certificates 
> required to verify the chain up to an accepted root certificate.  The 
> signature on the TBSCertificate indicates the certificate authority's intent 
> to issue a certificate.  This intent is considered binding (i.e., misissuance 
> of the Precertificate is considered equal to misissuance of the final 
> certificate).  Each log verifies the Precertificate signature chain and 
> issues a Signed Certificate Timestamp on the corresponding TBSCertificate.”
>
> >From 7.1.2.5 of the baseline requirements:
> “For purposes of clarification, a Precertificate, as described in RFC 6962 – 
> Certificate Transparency, shall not be considered to be a “certificate” 
> subject to the requirements of RFC 5280 - Internet X.509 Public Key 
> Infrastructure Certificate and Certificate Revocation List (CRL) Profile 
> under these Baseline Requirements”
>
> >From 6960:
>The "good" state indicates a positive response to the status inquiry.  At 
> a minimum, this positive response indicates that no certificate with the 
> requested certificate serial number currently within its validity interval is 
> revoked.  This state does not necessarily mean that the certificate was ever 
> issued or that the time at which the response was produced is within the 
> certificate's validity interval. Response extensions may be used to convey 
> additional information on assertions made by the responder regarding the 
> status of the certificate, such as a positive statement about issuance, 
> validity, etc.
>
>The "revoked" state indicates that the certificate has been revoked, 
> either temporarily (the revocation reason is certificateHold) or permanently. 
>  This state MAY also be returned if the associated CA has no record of ever 
> having issued a certificate with the certificate serial number in the 
> request, using any current or previous issuing key (referred to as a 
> "non-issued" certificate in this document).
>
>The "unknown" state indicates that the responder doesn't know about the 
> certificate being requested, usually because the request indicates an 
> unrecognized issuer that is not served by this responder.”
>
> Mozilla Policy:
>
> 1.  Does not define a precertificate. Instead Mozilla policy covers 
> everything with serverAuth (1.1)
>
> 2.  Requires functioning OCSP if the certificate contains an AIA (5.2)
>
> 3.  Must provide revocation information via the AIA for the cert (6)
>
> Argument for responding “Good”:
> A pre-certificate is a certificate and contains an AIA. Per the Mozilla 
> policy, the CA must provide services. Providing revoked or unknown is 
> incorrect because the pre-cert did issue. Although the BRs define the 
> pre-cert as out of scope of the BRs for CRLs and 5280, that just means the 
> serial number can repeat. Responding anything other than good would provide 
> wrong information about the status of the pre-cert.
>
> Argument for responding “Revoked”, “Unknown”, or “Invalid”:
> A pre-certificate is not a cert. The BRs define it as a not a cert as does 
> RFC 6962. A pre-cert is an intent to issue a certificate. RFC6960 
> specifically calls out that the CA may use revoke as a response for 
> certificates without a record of being issued and unknown where there isn’t a 
> status yet. Although the Mozilla policy is silent on the status of whether a 
> pre-cert is a certificate, section 2.3 incorporates the baseline 
> requirements. As such, the Mozilla policy implicitly defines a precertificate 
> as “not a certificate”. Because it’s not a certificate the OCSP service does 
> not know how to respond so any response is okay because there is no 
> certificate with that serial number until the ‘intent to issue’ is fulfilled.
>
> Note that even if you argue that “revoked”, “invalid”, or “unknown” are 
> appropriate, the RFC still permits “good” as a response because no 
> certificates with that serial number are revoked. Good is the safe answer.

Was there not a plan in CABF on al

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Tomas Gustavsson via dev-security-policy]

On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote:
> >From RFC6962:
> 
> “As above, the Precertificate submission MUST be accompanied by the 
> Precertificate Signing Certificate, if used, and all additional certificates 
> required to verify the chain up to an accepted root certificate.  The 
> signature on the TBSCertificate indicates the certificate authority's intent 
> to issue a certificate.  This intent is considered binding (i.e., misissuance 
> of the Precertificate is considered equal to misissuance of the final 
> certificate).  Each log verifies the Precertificate signature chain and 
> issues a Signed Certificate Timestamp on the corresponding TBSCertificate.”
> 
> >From 7.1.2.5 of the baseline requirements:
> “For purposes of clarification, a Precertificate, as described in RFC 6962 – 
> Certificate Transparency, shall not be considered to be a “certificate” 
> subject to the requirements of RFC 5280 - Internet X.509 Public Key 
> Infrastructure Certificate and Certificate Revocation List (CRL) Profile 
> under these Baseline Requirements”
> 
> >From 6960:
>The "good" state indicates a positive response to the status inquiry.  At 
> a minimum, this positive response indicates that no certificate with the 
> requested certificate serial number currently within its validity interval is 
> revoked.  This state does not necessarily mean that the certificate was ever 
> issued or that the time at which the response was produced is within the 
> certificate's validity interval. Response extensions may be used to convey 
> additional information on assertions made by the responder regarding the 
> status of the certificate, such as a positive statement about issuance, 
> validity, etc.
> 
>The "revoked" state indicates that the certificate has been revoked, 
> either temporarily (the revocation reason is certificateHold) or permanently. 
>  This state MAY also be returned if the associated CA has no record of ever 
> having issued a certificate with the certificate serial number in the 
> request, using any current or previous issuing key (referred to as a 
> "non-issued" certificate in this document).
> 
>The "unknown" state indicates that the responder doesn't know about the 
> certificate being requested, usually because the request indicates an 
> unrecognized issuer that is not served by this responder.”
> 
> Mozilla Policy:
> 
> 1.  Does not define a precertificate. Instead Mozilla policy covers 
> everything with serverAuth (1.1)
> 
> 2.  Requires functioning OCSP if the certificate contains an AIA (5.2)
> 
> 3.  Must provide revocation information via the AIA for the cert (6)
> 
> Argument for responding “Good”:
> A pre-certificate is a certificate and contains an AIA. Per the Mozilla 
> policy, the CA must provide services. Providing revoked or unknown is 
> incorrect because the pre-cert did issue. Although the BRs define the 
> pre-cert as out of scope of the BRs for CRLs and 5280, that just means the 
> serial number can repeat. Responding anything other than good would provide 
> wrong information about the status of the pre-cert.
> 
> Argument for responding “Revoked”, “Unknown”, or “Invalid”:
> A pre-certificate is not a cert. The BRs define it as a not a cert as does 
> RFC 6962. A pre-cert is an intent to issue a certificate. RFC6960 
> specifically calls out that the CA may use revoke as a response for 
> certificates without a record of being issued and unknown where there isn’t a 
> status yet. Although the Mozilla policy is silent on the status of whether a 
> pre-cert is a certificate, section 2.3 incorporates the baseline 
> requirements. As such, the Mozilla policy implicitly defines a precertificate 
> as “not a certificate”. Because it’s not a certificate the OCSP service does 
> not know how to respond so any response is okay because there is no 
> certificate with that serial number until the ‘intent to issue’ is fulfilled.
> 
> Note that even if you argue that “revoked”, “invalid”, or “unknown” are 
> appropriate, the RFC still permits “good” as a response because no 
> certificates with that serial number are revoked. Good is the safe answer.

Was there not a plan in CABF on allowing unathorized for "unknown" responses to 
save on private key usage? (I'm unable to find it now)

> 
> ________
> From: dev-security-policy  on 
> behalf of Tomas Gustavsson via dev-security-policy 
> 
> Sent: Saturday, August 31, 2019 5:01:42 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
> for Some Precertificates
> 
> Hi,
> 
> I 

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

You’re right. It could be any of the responses under RFC 6960.

From: Alex Cohn 
Sent: Friday, August 30, 2019 7:22 PM
To: Jeremy Rowley 
Cc: Jacob Hoffman-Andrews ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Is our answer right though? I wasn't sure. I said "Good" because "a promise to 
issue a cert" could be considered the same issued. In that case the BRs say you 
must respond good. However, if "a promise to issue a certificate" is not the 
same as issuance, the BRs don't apply to the OCSP until the certificate issues 
and the correct response is "Revoked" per the RFC.

The BRs apply for sure to the contents, but do they apply to the OCSP responses 
in the time period between when the pre-cert is logged and the cert is signed.

It seems reasonable to me to assume that if the contents of a precertificate 
are in-scope for the BRs, the OCSP responses would be likewise in-scope.

Seems like a nice simple rule is that the promise to issue is issuance 
regardless of what the BRs say and that you should respond good. This was our 
logic and why we decided on "Good".

I agree. A CA cannot prove they didn't issue the final certificate. Given 
existence of a pre-certificate, it is reasonable for a relying party to assume 
that the final certificate exists and therefore that OCSP services will be 
functional. I personally would view arguments such as "we didn't actually issue 
that, so we don't need to provide sane OCSP responses" with a great deal of 
skepticism, especially from CAs that do not automatically CT log their final 
certificates (nudge nudge DigiCert, Amazon, Entrust).

However, a very strict reading of the RFC and BR interaction means you need to 
respond "Revoked" until the cert issues. I don't like that outcome because it's 
complicated and leads to confusion.

Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the 
requirement to respond "revoked" for unknown or non-issued certificates - can 
you explain further? 4.9.10 forbids replying "good" for non-issued 
certificates, but I don't see any stipulations surrounding replying "unknown." 
The certificateHold + 1970-1-1 revocation date method of indicating a 
non-issued certificate in 6960 2.2 might be forbidden by an especially strict 
reading of BRs 4.9.13, but it's not mandated by 6960. In the absence of a 
precertificate signing certificate, OCSP queries for precertificate and 
certificate are identical, so it could be argued that the precertificate itself 
means it's not a "non-issued" certificate?

From a RP's perspective, I can easily envision problems resulting from an OCSP 
response for a given serial number transitioning from revoked to good, 
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate 
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests for 
precertificates from final certificates. How do these CAs handle OCSP for 
precertificates? Trustwave appears to always answer 
"unauthorized<https://crt.sh/?id=1827579322=ocsp>" and NetLock 
"malformed<https://crt.sh/?id=1826448700=ocsp>", which is...curious.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

The best way to codify it is at the CAB forum since the CAB Forum language is 
the one that causes the problem (imo). We made a mistake by defining a 
precertificate as “not a certificate” when the intent was mostly to allow CAs 
to issue precertificates that had serial numbers duplicative with the actual 
certificate. I was thinking we should remove overly broad language and replace 
it with language that is more restrictive – something like all certificates 
must confirm to 5280 except precertificates which must conform to 6962. Needs 
work of course, but that was my initial idea.

From: Ryan Sleevi 
Sent: Friday, August 30, 2019 12:58 PM
To: Jeremy Rowley 
Cc: Jacob Hoffman-Andrews ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates



On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Is our answer right though? I wasn't sure. I said "Good" because "a promise to 
issue a cert" could be considered the same issued. In that case the BRs say you 
must respond good.

Citation needed ;-)

However, if "a promise to issue a certificate" is not the same as issuance, the 
BRs don't apply to the OCSP until the certificate issues and the correct 
response is "Revoked" per the RFC.

That would be... inadvisable, as you'd be unrevoking a certificate, which would 
definitely Be An Issue (e.g. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1532333 )

I definitely want to make sure any confusion is resolved. Can you point to any 
Mozilla policies or comms that use the phrase "promise to issue a certificate" 
so we can clarify? It's unclear to me if it's being used as an unfortunate 
shorthand (and special apologies if I've contributed to that).

RFC 6962, Section 3.1, phrases it as such:
   "The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate. This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate)."

(Some past discussion at 
https://groups.google.com/d/topic/mozilla.dev.security.policy/Hk78klSv8AY/discussion
 )

In various discussions, this has been attempted to be further clarified: If a 
precertificate exists, for all intents and purposes of all policy obligations, 
an equivalent certificate is presumed to exist, as the CA has signaled a 
binding intent to do so. As a consequence, regardless of whether or not we 
"see" the certificate, it should be presumed to exist, and the OCSP status and 
any other certificate services, databases, or other should be presumed to exist.

The BRs apply for sure to the contents, but do they apply to the OCSP responses 
in the time period between when the pre-cert is logged and the cert is signed.

Seems like a nice simple rule is that the promise to issue is issuance 
regardless of what the BRs say and that you should respond good. This was our 
logic and why we decided on "Good". However, a very strict reading of the RFC 
and BR interaction means you need to respond "Revoked" until the cert issues. I 
don't like that outcome because it's complicated and leads to confusion.

Agreed that it's nonsense, but I don't see how the strict reading can lead to 
that conclusion. There's more statuses than the binary Good/Revoked, and that's 
extremely relevant (and the BRs Have Opinions on which statuses you can and 
should use for certs you don't know about)

Despite all of the writing above, I'm too lazy to copy/paste my comment from 
the Let's Encrypt issue, but I would hope any CA contemplating things should 
look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in terms of a 
possible 'ideal' flow, and to share concerns or considerations with that. Even 
better would be CAs that have suggestions on how best to codify and memorialize 
that suggestion, if it's sensible and correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

>From RFC6962:

“As above, the Precertificate submission MUST be accompanied by the 
Precertificate Signing Certificate, if used, and all additional certificates 
required to verify the chain up to an accepted root certificate.  The signature 
on the TBSCertificate indicates the certificate authority's intent to issue a 
certificate.  This intent is considered binding (i.e., misissuance of the 
Precertificate is considered equal to misissuance of the final certificate).  
Each log verifies the Precertificate signature chain and issues a Signed 
Certificate Timestamp on the corresponding TBSCertificate.”

>From 7.1.2.5 of the baseline requirements:
“For purposes of clarification, a Precertificate, as described in RFC 6962 – 
Certificate Transparency, shall not be considered to be a “certificate” subject 
to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure 
Certificate and Certificate Revocation List (CRL) Profile under these Baseline 
Requirements”

>From 6960:
   The "good" state indicates a positive response to the status inquiry.  At a 
minimum, this positive response indicates that no certificate with the 
requested certificate serial number currently within its validity interval is 
revoked.  This state does not necessarily mean that the certificate was ever 
issued or that the time at which the response was produced is within the 
certificate's validity interval. Response extensions may be used to convey 
additional information on assertions made by the responder regarding the status 
of the certificate, such as a positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked, either 
temporarily (the revocation reason is certificateHold) or permanently.  This 
state MAY also be returned if the associated CA has no record of ever having 
issued a certificate with the certificate serial number in the request, using 
any current or previous issuing key (referred to as a "non-issued" certificate 
in this document).

   The "unknown" state indicates that the responder doesn't know about the 
certificate being requested, usually because the request indicates an 
unrecognized issuer that is not served by this responder.”

Mozilla Policy:

1.  Does not define a precertificate. Instead Mozilla policy covers everything 
with serverAuth (1.1)

2.  Requires functioning OCSP if the certificate contains an AIA (5.2)

3.  Must provide revocation information via the AIA for the cert (6)

Argument for responding “Good”:
A pre-certificate is a certificate and contains an AIA. Per the Mozilla policy, 
the CA must provide services. Providing revoked or unknown is incorrect because 
the pre-cert did issue. Although the BRs define the pre-cert as out of scope of 
the BRs for CRLs and 5280, that just means the serial number can repeat. 
Responding anything other than good would provide wrong information about the 
status of the pre-cert.

Argument for responding “Revoked”, “Unknown”, or “Invalid”:
A pre-certificate is not a cert. The BRs define it as a not a cert as does RFC 
6962. A pre-cert is an intent to issue a certificate. RFC6960 specifically 
calls out that the CA may use revoke as a response for certificates without a 
record of being issued and unknown where there isn’t a status yet. Although the 
Mozilla policy is silent on the status of whether a pre-cert is a certificate, 
section 2.3 incorporates the baseline requirements. As such, the Mozilla policy 
implicitly defines a precertificate as “not a certificate”. Because it’s not a 
certificate the OCSP service does not know how to respond so any response is 
okay because there is no certificate with that serial number until the ‘intent 
to issue’ is fulfilled.

Note that even if you argue that “revoked”, “invalid”, or “unknown” are 
appropriate, the RFC still permits “good” as a response because no certificates 
with that serial number are revoked. Good is the safe answer.





From: dev-security-policy  on 
behalf of Tomas Gustavsson via dev-security-policy 

Sent: Saturday, August 31, 2019 5:01:42 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

Hi,

I find and hear a few non conclusive, sometimes contradictory, messages about 
OCSP responder handling of pre-certificates without final certificates. Reading 
this thread I don't find a firm conclusion either (albeit I may have missed it).
I'm not saying anything others have not said before, so I don't claim to say 
anything new, just to summarize what I believe to be a safe behavior.

(I'm merely interested in the technical behavior of an OCSP responder)

My position dates back to 2013 during CT implementation. Discussions back then:
https://groups.google.com/forum/m/#!searchin/certificate-transparency/tomas/certificate-trans

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Tomas Gustavsson via dev-security-policy]

Hi,

I find and hear a few non conclusive, sometimes contradictory, messages about 
OCSP responder handling of pre-certificates without final certificates. Reading 
this thread I don't find a firm conclusion either (albeit I may have missed it).
I'm not saying anything others have not said before, so I don't claim to say 
anything new, just to summarize what I believe to be a safe behavior.

(I'm merely interested in the technical behavior of an OCSP responder)

My position dates back to 2013 during CT implementation. Discussions back then:
https://groups.google.com/forum/m/#!searchin/certificate-transparency/tomas/certificate-transparency/1tWzSXKe3gQ
"a Precertificate is arguably not a Certificate".
as well as:
"The precertificate contains a critical extension that no verifier should 
understand, and therefore will not verify."

In combination with RFC6960 (introduction):
"The Online Certificate Status Protocol (OCSP) enables applications to 
determine the (revocation) state of identified certificates."

and Ballot 80:
https://cabforum.org/2012/08/02/ballot-80-response-for-non-issued-certificates/

For an OCSP server a query is neither for a "pre certificate" nor a 
"certificate", the OCSP responder just sees an issuer (hash) and a serial 
number. It's a query for revocation status about the issuer and serial number 
pair passed in the request.

>From this my conclusion was, and still is:
- A pre certificate is not an issued certificate in the Web PKI. As such an 
OCSP responder should answer "anything but good" for this issuer/serialnumber 
combination if a "real" certificate has not been (yet) issued.

>From a RP perspective, any RP that queries OCSP during an attempt, with 
>intent, to use a pre certificate (with poison extension) is broken and the 
>only safe goal is to try to prevent this RP from using the pre certificate. 
>Again my conclusion is that the safe way is to answer "anything but good".

For OCSP there are at least two corner cases here:
1. A pre certificate has been issued, but the real certificate has not and 
never will be
2. There is a time gap period between the issuance of the pre certificate and 
the real certificate

For 1, the "intended to be issued" certificate should be revoked asap in any 
case, so "anything but good" is the proper answer.
For 2, there is a short period where someone monitoring log servers may 
discover the pre certificate and poison any OCSP response cache by querying for 
this issuer/serial (getting a "anything but good" for the not yet issued real 
certificate). After cache expiry the response will be good. The same can happen 
by shotgunning the OCSP responder with random serials, albeit it's hard to hit 
a "real" upcoming serial number in the >64bit random serial number space, or if 
there is a delay between releasing the real certificate and fully distributing 
it to OCSP responders. When direct updates to OCSP is used this periods is 
measured in seconds maximum, and milliseconds optimally.

Making a long story short:
- I belive answering "anything but good" is a proper answer for pre 
certificates (issuer/serialno) where no real certificate was issued or 
distributed.

Did I miss anything?

Regards,
Tomas
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good. However, if "a promise to issue a
> certificate" is not the same as issuance, the BRs don't apply to the OCSP
> until the certificate issues and the correct response is "Revoked" per the
> RFC.
>
> The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.
>

It seems reasonable to me to assume that if the contents of a
precertificate are in-scope for the BRs, the OCSP responses would be
likewise in-scope.


> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good".


I agree. A CA cannot prove they didn't issue the final certificate. Given
existence of a pre-certificate, it is reasonable for a relying party to
assume that the final certificate exists and therefore that OCSP services
will be functional. I personally would view arguments such as "we didn't
actually issue that, so we don't need to provide sane OCSP responses" with
a great deal of skepticism, especially from CAs that do not automatically
CT log their final certificates (nudge nudge DigiCert, Amazon, Entrust).

However, a very strict reading of the RFC and BR interaction means you need
> to respond "Revoked" until the cert issues. I don't like that outcome
> because it's complicated and leads to confusion.


Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the
requirement to respond "revoked" for unknown or non-issued certificates -
can you explain further? 4.9.10 forbids replying "good" for non-issued
certificates, but I don't see any stipulations surrounding replying
"unknown." The certificateHold + 1970-1-1 revocation date method of
indicating a non-issued certificate in 6960 2.2 might be forbidden by an
especially strict reading of BRs 4.9.13, but it's not mandated by 6960. In
the absence of a precertificate signing certificate, OCSP queries for
precertificate and certificate are identical, so it could be argued that
the precertificate itself means it's not a "non-issued" certificate?

>From a RP's perspective, I can easily envision problems resulting from an
OCSP response for a given serial number transitioning from revoked to good,
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests
for precertificates from final certificates. How do these CAs handle OCSP
for precertificates? Trustwave appears to always answer "unauthorized
" and NetLock "malformed
", which is...curious.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good.


Citation needed ;-)


> However, if "a promise to issue a certificate" is not the same as
> issuance, the BRs don't apply to the OCSP until the certificate issues and
> the correct response is "Revoked" per the RFC.
>

That would be... inadvisable, as you'd be unrevoking a certificate, which
would definitely Be An Issue (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1532333 )

I definitely want to make sure any confusion is resolved. Can you point to
any Mozilla policies or comms that use the phrase "promise to issue a
certificate" so we can clarify? It's unclear to me if it's being used as an
unfortunate shorthand (and special apologies if I've contributed to that).

RFC 6962, Section 3.1, phrases it as such:
   "The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate. This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate)."

(Some past discussion at
https://groups.google.com/d/topic/mozilla.dev.security.policy/Hk78klSv8AY/discussion
)

In various discussions, this has been attempted to be further clarified: If
a precertificate exists, for all intents and purposes of all policy
obligations, an equivalent certificate is presumed to exist, as the CA has
signaled a binding intent to do so. As a consequence, regardless of whether
or not we "see" the certificate, it should be presumed to exist, and the
OCSP status and any other certificate services, databases, or other should
be presumed to exist.

The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.
>
> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good". However, a very strict reading of
> the RFC and BR interaction means you need to respond "Revoked" until the
> cert issues. I don't like that outcome because it's complicated and leads
> to confusion.


Agreed that it's nonsense, but I don't see how the strict reading can lead
to that conclusion. There's more statuses than the binary Good/Revoked, and
that's extremely relevant (and the BRs Have Opinions on which statuses you
can and should use for certs you don't know about)

Despite all of the writing above, I'm too lazy to copy/paste my comment
from the Let's Encrypt issue, but I would hope any CA contemplating things
should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in
terms of a possible 'ideal' flow, and to share concerns or considerations
with that. Even better would be CAs that have suggestions on how best to
codify and memorialize that suggestion, if it's sensible and correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

Is our answer right though? I wasn't sure. I said "Good" because "a promise to 
issue a cert" could be considered the same issued. In that case the BRs say you 
must respond good. However, if "a promise to issue a certificate" is not the 
same as issuance, the BRs don't apply to the OCSP until the certificate issues 
and the correct response is "Revoked" per the RFC. 

The BRs apply for sure to the contents, but do they apply to the OCSP responses 
in the time period between when the pre-cert is logged and the cert is signed. 

Seems like a nice simple rule is that the promise to issue is issuance 
regardless of what the BRs say and that you should respond good. This was our 
logic and why we decided on "Good". However, a very strict reading of the RFC 
and BR interaction means you need to respond "Revoked" until the cert issues. I 
don't like that outcome because it's complicated and leads to confusion. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Jacob Hoffman-Andrews via dev-security-policy
Sent: Thursday, August 29, 2019 5:37 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for 
Some Precertificates

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
  - For each precertificate issued according to our audit logs, verify that we 
are serving a corresponding OCSP response (if the precertificate is currently 
valid).
  - Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
  - Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Kurt Roeckx via dev-security-policy]

On 2019-08-30 12:14, Jakob Bohm wrote:

On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
- For each precertificate issued according to our audit logs, verify that 
we are serving a corresponding OCSP response (if the precertificate is 
currently valid).
- Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
- Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.



For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should
take a look at those error cases and subdivide them into:

1. No intent to actually issue the actual cert.  Best handling is to
   treat as revoked in all revocation protocols and logs, but with audit
   and incident systems reporting that the cert wasn't actually issued.
   ( *Most common case* ).

2. Intent to actually issue later, if/when something happens that just
   takes longer than usual.  Here it makes sense for OCSP and other such
   mechanisms to return "good", due to the ban on reporting "certificate
   hold" or otherwise exiting a revoked state.  It of cause remains
   possible to later revoke such a half-issued cert if there is a reason
   to do so.

3. Intent to issue in a few minutes, somehow OCSP was queried during the
   short processing delay between CT submission and actual issuing of
   cert with embedded CT proofs.  Because inserting the CT proofs in the
   OCSP responses probably awaits the same technical condition as the
   cert issuing, it makes sense to return "unknown" for those few
   minutes, as when delivery of the cert status to the OCSP servers is
   itself delayed by a few minutes (up to whatever limit policies set
   for updating revocation servers with knowledge of new certs).


It's not obvious for me why such cases exist, and I think it would at 
least be useful to have an actual list of why a pre-certificate was 
issued and the real certificate was not.


If the pre-certificate was issued, it means all validation should 
already have happened, and there is no reason not to issue the real 
certificate other than some problems preventing it. But the difference 
between 3) and 1) and 2) seems to be someone manually moved it from 3) 
to one of the other 2.


Examples of reasons for me are things like:
- There is some technical problem with a server, it will be issued when 
the server works again, or it's redirected to some other server. (like 
can't get enough SCTs.)

- You lint the pre certificate and see an issue (and should revoke it)

I think there shouldn't exist pre-certificates that are valid without 
the real certificate, after some delay. For instance, if you can't issue 
the real certificate within 24 hours, revoke the pre-certificate.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jakob Bohm via dev-security-policy]

On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:
> Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> 
> On 2019.08.28 we read Apple’s bug report at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
> responder returning incorrect results for a precertificate. This prompted us 
> to run our own investigation. We found in an initial review that for 35 of 
> our precertificates, we were serving incorrect OCSP results (“unauthorized” 
> instead of “good”). Like DigiCert, this happened when a precertificate was 
> issued, but the corresponding certificate was not issued due to an error.
> 
> We’re taking these additional steps to ensure a robust fix:
>- For each precertificate issued according to our audit logs, verify that 
> we are serving a corresponding OCSP response (if the precertificate is 
> currently valid).
>- Configure alerting for the conditions that create this problem, so we 
> can fix any instances that arise in the short term.
>- Deploy a code change to Boulder to ensure that we serve OCSP even if an 
> error occurs after precertificate issuance.
> 

For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should 
take a look at those error cases and subdivide them into:

1. No intent to actually issue the actual cert.  Best handling is to 
  treat as revoked in all revocation protocols and logs, but with audit 
  and incident systems reporting that the cert wasn't actually issued.
  ( *Most common case* ).

2. Intent to actually issue later, if/when something happens that just 
  takes longer than usual.  Here it makes sense for OCSP and other such 
  mechanisms to return "good", due to the ban on reporting "certificate 
  hold" or otherwise exiting a revoked state.  It of cause remains 
  possible to later revoke such a half-issued cert if there is a reason 
  to do so.

3. Intent to issue in a few minutes, somehow OCSP was queried during the 
  short processing delay between CT submission and actual issuing of 
  cert with embedded CT proofs.  Because inserting the CT proofs in the 
  OCSP responses probably awaits the same technical condition as the 
  cert issuing, it makes sense to return "unknown" for those few 
  minutes, as when delivery of the cert status to the OCSP servers is 
  itself delayed by a few minutes (up to whatever limit policies set 
  for updating revocation servers with knowledge of new certs).

Scenario 2 can be subdivided in two sub-cases for compliance purposes:

2A: Pre-cert (and thus cert) has a "valid from" date equal or near the 
  CT submission time.  Here the CT logged pre-cert provides proof that 
  this is not backdating, even though cert usage won't start until 
  later.

2B: Pre-cert (and thus cert) has a "valid from" date closer to the 
  intended issuing date for the final cert.  Here the CT logged pre-cert 
  provides proof that certain issuance decisions happened earlier, thus 
  affecting when some of the validity time limits are reached.

Note that for some cert types (such as certs for S/MIME SubCAs), it is 
trivially possible for a subscriber to use the validity before the cert 
actually exists, while in other cases it is not possible, except for the 
difficulty in proving that the cert doesn't exist.



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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy