Re: DigiCert OCSP services returns 1 byte

[Andrew Ayer via dev-security-policy]

Hi Wayne,

> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with Mozilla policy for all Precertificates as if
> > the corresponding certificate exists, and (ii) a CA must be able to revoke
> > a Precertificate if revocation of the certificate is required under Mozilla
> > policy and the corresponding certificate doesn’t actually exist and
> > therefore cannot be revoked.
> >
> 
> I will again welcome everyone's constructive feedback on this proposal, and
> when there are no further comments I'll add this to our wiki.

I'm concerned that the last paragraph could be interpreted as requiring
CAs to operate OCSP services for the literal precertificates issued by
dedicated precert signing CAs, rather than the corresponding
certificates. This is not intended or useful, and as Tim Shirley
notes it would double the OCSP signing load for any CA using precert
signing CAs.

I think it's better to frame the language not as operating OCSP
services for precertificates themselves, but for certificates presumed
to exist based on the presence of a precertifiate (even if the
certificate doesn't actually exist).

Here's some suggested wording for the last paragraph:

> This means, for example, that (i) a CA must provide OCSP services
> and responses in accordance with Mozilla policy for all certificates
> presumed to exist based on the presence of a Precertificate, even if the
> certificate does not actually exist, and (ii) a CA must be able to revoke
> a certificate presumed to exist, if revocation of the certificate is required
> under Mozilla policy, even if the certificate does not actually exist.

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

Apple: Precertificates without corresponding certificates return OCSP value of "unknown"

[Apple CA via dev-security-policy]

We’ve been following the discussions regarding how OCSP responders should 
handle Precertificates without corresponding certificates and what the 
appropriate response indicator should be (good, revoked, or unknown). 

Based on the recent clarifications at [1], we want to inform the community that 
Apple’s OCSP responders return a status of “unknown” for Precertificates 
without a corresponding certificate. We have identified one Precertificate that 
did not result in a corresponding certificate for which our OCSP responders are 
returning a status of “unknown” (https://crt.sh/?id=1368484681).

We’ve updated the OCSP responders to respond “good” for that Precertificate and 
a long-term fix is in progress.

We appreciate the efforts being made to amend the Mozilla Root Store Policy to 
explicitly address matters relating to Certificate Transparency.

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/24Fl9kc-AQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trusted Recursive Resolver Policy in India

[Wayne Thayer via dev-security-policy]

Rich: I want to acknowledge your question, which I think is really "what is
the right forum for Mozilla TRR (DNS over HTTPS) policy [1] discussions?" I
don't currently have an answer for you, but will respond when I do.

- Wayne

[1] https://wiki.mozilla.org/Security/DOH-resolver-policy

On Wed, Sep 11, 2019 at 11:39 AM rich.salz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is this list the right place to discuss the TRR policy?
> If so, could the wiki page on the policy be updated to point to it?
> ___
> 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: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:

* Accepted Jeremy's proposed language for the examples in the last
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a certificate exists by changing that sentence to
"Otherwise, Mozilla infers from the existence of a precertificate that a
corresponding certificate has been issued, even when we have no evidence of
the certificate."

The new statement of "required practice" reads:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given Precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every Precertificate exists.
>
> RFC 6962 states “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).”
>
> However, BR 7.1.2.5 state “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.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a Precertificate containing the same serial number as the subsequent
> certificate. Otherwise, Mozilla infers from the existence of a
> Precertificate that a corresponding certificate has been issued, even when
> we have no evidence of the certificate.
>
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with Mozilla policy for all Precertificates as if
> the corresponding certificate exists, and (ii) a CA must be able to revoke
> a Precertificate if revocation of the certificate is required under Mozilla
> policy and the corresponding certificate doesn’t actually exist and
> therefore cannot be revoked.
>

I will again welcome everyone's constructive feedback on this proposal, and
when there are no further comments I'll add this to our wiki.

- Wayne

On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek 
wrote:

> Yes, but I think this clarifies things in the wrong direction.
>
> -Tim
>
> > -Original Message-
> > From: Rob Stradling 
> > Sent: Friday, September 13, 2019 4:22 AM
> > To: Tim Hollebeek ; Jeremy Rowley
> > ; Alex Cohn 
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > 
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > > So, this is something that would be helpfully clarified via either an
> > > IETF draft,
> >
> > There's already a 6962-bis draft [1] in IESG Last Call, which (when we
> finally
> > complete it!) will obsolete RFC6962.  6962-bis redefines precertificates
> so that
> > they're not actually X.509 certificates.
> > Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >
> > Thinking aloud...
> > Does anything need to be clarified in 6962-bis though?
> > A (non-X.509) 6962-bis precertificate contains the serial number that
> will
> > appear in the certificate (if or when that certificate is issued),
> > so: Should the CA be forbidden, permitted or required to operate
> revocation
> > services for that serial number once the 6962-bis precertificate has been
> > produced but before the certificate has been issued?  (And is this a
> technical
> > matter for 6962-bis to address, or a policy matter that's out of scope
> for the
> > 6962-bis document?)
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >
> > > 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 relevant
> sections are
> > blissfully ignorant of CT, and the correct behavior here was
> unfortunately left
> > out of RFC 6962, which should have clarified this.
> > >
> > > Happy to help draft something.  There are some interesting complexities
> > once you dig deeper.
> > >
> > > -Tim
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Jeremy
> > >> Rowley via dev-security-policy
> > >> Sent: Thursday, September 12, 2019 1:46 PM
> > >> To: Alex Cohn 
> > >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > >> 
> > >> Subject: RE: DigiCert OCSP services returns 1 byte
> > >>
> > >> 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 re

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

Yes, but I think this clarifies things in the wrong direction.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Friday, September 13, 2019 4:22 AM
> To: Tim Hollebeek ; Jeremy Rowley
> ; Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
> 
> There's already a 6962-bis draft [1] in IESG Last Call, which (when we finally
> complete it!) will obsolete RFC6962.  6962-bis redefines precertificates so 
> that
> they're not actually X.509 certificates.
> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> 
> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?
> A (non-X.509) 6962-bis precertificate contains the serial number that will
> appear in the certificate (if or when that certificate is issued),
> so: Should the CA be forbidden, permitted or required to operate revocation
> services for that serial number once the 6962-bis precertificate has been
> produced but before the certificate has been issued?  (And is this a technical
> matter for 6962-bis to address, or a policy matter that's out of scope for the
> 6962-bis document?)
> 
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> 
> > 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 relevant sections 
> are
> blissfully ignorant of CT, and the correct behavior here was unfortunately 
> left
> out of RFC 6962, which should have clarified this.
> >
> > Happy to help draft something.  There are some interesting complexities
> once you dig deeper.
> >
> > -Tim
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Jeremy
> >> Rowley via dev-security-policy
> >> Sent: Thursday, September 12, 2019 1:46 PM
> >> To: Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: RE: DigiCert OCSP services returns 1 byte
> >>
> >> 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 as the final cert if the final cert doesn’t exist.
> >>
> >> I believe the intent is that a CT-naïve OCSP checker would work
> >> normally when presented with a precert or a certificate. Afterall, a
> >> precert is really just a certificate with a special extension.
> >>
> >> From: Alex Cohn 
> >> Sent: Thursday, September 12, 2019 9:25 AM
> >> To: Jeremy Rowley 
> >> Cc: Wayne Thayer ; mozilla-dev-security-
> >> pol...@lists.mozilla.org
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
> >> dev-security-policy
> >> mailto:dev-security-
> >> pol...@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 certificate exists and (ii) a CA
> >> must be able to revoke a pre- certificate if revocation of the
> >> certificate is required under the Mozilla policy and the
> >> corresponding certificate doesn't actually exist and therefore cannot be
> revoked.
> >>
> >> Should a CA using a precertificate signing certificate be required to
> >> provide OCSP services for their precertificates? Or is it on the
> >> relying party to calculate the proper OCSP request for the final
> >> certificate and send that instead? In other words, should we expect a
> >> CT-naïve OCSP checker to work normally when presented, e.g., with
> https://crt.sh/?id=1868433277?
> >>
> >> Alex
> >> ___
> >> 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
> 
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
> Bradford, UK
> Office: +441274024707
> Sectigo Limited
> 
> This message and any files associated with it may contain legally privileged,
> confidential, or proprietary information. If you are not the intended 
> recipient,
> you are not permitted to use, copy, or forward it, in whole or in part without
> the express consent of the sender. Please notify the sender by reply email,
> disregard the foregoing messages, and delete it immediately.


s

RE: DigiCert OCSP services returns 1 byte

[Tim Hollebeek via dev-security-policy]

Tim Shirley did a good job of pointing it out.  The relevant OCSP RFCs talk 
about issued certificates, which pre-certificates aren’t.  This isn’t a policy 
matter, it’s a matter of a plain reading of the relevant RFCs, and trying to 
align that with what people want them to say as opposed to what they actually 
say.

 

Whatever the policy is, and I’m actually supportive of Wayne’s policy goals, 
the CT and OCSP RFCs actually have requirements that potentially contradict 
those goals, especially under some interpretations.

 

I’d like to fix the relevant requirements to allow to the policy that there 
seems to be a growing consensus for.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 12, 2019 6:44 PM
To: Tim Hollebeek 
Cc: Jeremy Rowley ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 

Subject: Re: DigiCert OCSP services returns 1 byte

 

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 to try and 
helpfully clarify the BRs with respect to precertificates, so I've come to view 
clarifications as just as much, if not more, risky than the original language.

 

The question about whether and how a pre-certificate is viewed is definitely a 
matter for policy, and so I'm definitely opposed to attempting to address it in 
IETF drafts, and somewhat opposed to clarifying it in the BRs, since really, 
it's a matter of policy.

 

Could you perhaps highlight which "various things in the OCSP RFCs" that might 
be read to conflict or preclude a good response? I think that's probably the 
best way to figure out what, where, is to understand how the interpretation 
came to be. It could be simply that the interpretation overlooked other 
sections, as we've seen in the past (e.g. with IP addresses in dNSName or with 
underscores), and so that seems like the best starting point.

 

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

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 relevant sections 
are blissfully ignorant of CT, and the correct behavior here was unfortunately 
left out of RFC 6962, which should have clarified this.

Happy to help draft something.  There are some interesting complexities once 
you dig deeper.

-Tim

> -Original Message-
> From: dev-security-policy   > On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn mailto:a...@alexcohn.com> >
> Cc: mozilla-dev-security-pol...@lists.mozilla.org 
>  ; Wayne Thayer
> mailto:wtha...@mozilla.com> >
> Subject: RE: DigiCert OCSP services returns 1 byte
> 
> 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 as the final cert if 
> the
> final cert doesn’t exist.
> 
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just 
> a
> certificate with a special extension.
> 
> From: Alex Cohn mailto:a...@alexcohn.com> >
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley   >
> Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; 
> mozilla-dev-security-
> pol...@lists.mozilla.org  
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>     
> pol...@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 certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla 
> policy
> and the corresponding certificate doesn't actually exist and therefore cannot
> be revoked.
> 
> Should a CA using a precertificate signing certificate be required to provide
> OCSP services for their precertificates? Or is it on the relying party to 
> calculate
> the proper 

Re: Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

[Wayne Thayer via dev-security-policy]

Thank you for the report and follow-up Andy. I created
https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue.

- Wayne

On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A quick follow-up to close this out.
>
> The push to fully address the issue was completed globally shortly before
> 16:00 UTC on 2019-09-02.
>
> After additional review, we're confident the only certificates affected
> were these two:
> https://crt.sh/?id=760396354
> https://crt.sh/?id=759833603
>
> Google Trust Services considers this matter fully addressed. We will of
> course continue our ongoing internal review program, but no other work or
> information is outstanding at this point.
>
> --
> Andy Warner
> Google Trust Services
>
> On Friday, August 30, 2019 at 2:39:51 PM UTC-4, Andy Warner wrote:
> > This is an initial report and we expect to provide some additional
> details and the completion timeline after a bit more verification and full
> deployment of in-flight mitigations. We are posting the most complete
> information we have currently to comply with Mozilla reporting timelines
> and will follow-up with additional details soon.
> >
> > 1. How your CA first became aware of the problem and the time and date.
> >
> > While performing an internal review and assessment of the CRL generation
> system for Google Trust Services' GTS CA 1O1 on August 16, 2019, it was
> discovered that the CRL generation service did not include CRL entries of
> expired certificates. The periodic job only considered certificates with
> valid lifetimes. This does not conform to RFC 5280 Section 3.3 which states
> that “An entry MUST NOT be removed from the CRL until it appears on one
> regularly scheduled CRL issued beyond the revoked certificate's validity
> period.”  We expect that few, if any, clients have been impacted.  For a
> client to be impacted they would have to: clock skewed to a time before the
> not-after field of the certificate; and have a CRL published after
> expiration dropping the revoked certificate.
> >
> >
> > 2. A timeline of the actions your CA took in response. A timeline is a
> date-and-time-stamped sequence of all relevant events. This may include
> events before the incident was reported, such as when a particular
> requirement became applicable, or a document changed, or a bug was
> introduced, or an audit was done.
> >
> > August 16, 2019 15:00 UTC - Reviewer realizes that CRL will not publish
> for one update past expiration
> > August 16, 2019 16:00 UTC - Reviewer checks for other issues & talks to
> peers to confirm problem
> > August 16, 2019 17:00 UTC - Bug is filed to fix the issue with a
> proposed design fix
> > August 16, 2019 23:30 UTC - Fix is sent for review
> > August 20, 2019 16:00 UTC - Remediation work is discussed & assigned
> > August  20, 2019 18:00 UTC - Query to inspect revoked certificates is
> created and sent to be run by production team for initial analysis.
> > August 21, 2019 10:40 UTC - Production team runs query and returns result
> > August 21, 2019 15:00 UTC - Reviewer analyzes data
> > August 21, 2019 20:30 UTC - Reviewer asks for a follow up query to
> ascertain if any certificates did not make it onto the CRL
> > August 22, 2019 07:00 UTC - Initial attempt at updating test systems
> with fix.
> > August 22, 2019 09:00 UTC - Updating of test systems aborted due to
> (unrelated) issues.
> > August 22, 2019 07:00 UTC - Production team runs query for CRLs that may
> have missed a certificate
> > August 22, 2019 15:00 UTC - Reviewer ascertains that certificates under
> question were on a CRL
> > August 26, 2019 11:00 UTC - Second attempt at updating test systems with
> fix.
> > August 26, 2019 13:00 UTC - Test systems updated, confirmed integrity of
> fixed software.
> > August 27, 2019 09:00 UTC - Confirmed fix is effective on test systems.
> > August 27, 2019 10:00 UTC - present: Ongoing staged deployment to
> production systems. Should complete fully by September 3, 2019 17:00 UTC
> (slightly extended window due to push policies around holiday weekends. The
> rollout was staged in accordance with Google's standard rollout procedures.)
> >
> >
> > 3. Whether your CA has stopped, or has not yet stopped, issuing
> certificates with the problem.
> >
> > The affected CA software has been patched.  It now populates expired
> certificates in the CRL for 7 days after their expiration to ensure they
> appear in at least one regularly issued CRL update.  Automated testing was
> added as part of the same patch to check that revoked certificates are kept
> in the CRL.  The patch was developed, tested, reviewed and landed within
> the codebase by August 19, 2019.  The CRL entry removal bug has been fully
> remediated.
> >
> >
> > 4. A summary of the problematic certificates. For each problem: number
> of certs, and the date the first and last certs with that problem were
> issued.
> >
> > Investigation began on August

Re: Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

[Andy Warner via dev-security-policy]

A quick follow-up to close this out.

The push to fully address the issue was completed globally shortly before 16:00 
UTC on 2019-09-02.

After additional review, we're confident the only certificates affected were 
these two:
https://crt.sh/?id=760396354
https://crt.sh/?id=759833603

Google Trust Services considers this matter fully addressed. We will of course 
continue our ongoing internal review program, but no other work or information 
is outstanding at this point.

--
Andy Warner
Google Trust Services

On Friday, August 30, 2019 at 2:39:51 PM UTC-4, Andy Warner wrote:
> This is an initial report and we expect to provide some additional details 
> and the completion timeline after a bit more verification and full deployment 
> of in-flight mitigations. We are posting the most complete information we 
> have currently to comply with Mozilla reporting timelines and will follow-up 
> with additional details soon.
> 
> 1. How your CA first became aware of the problem and the time and date.
> 
> While performing an internal review and assessment of the CRL generation 
> system for Google Trust Services' GTS CA 1O1 on August 16, 2019, it was 
> discovered that the CRL generation service did not include CRL entries of 
> expired certificates. The periodic job only considered certificates with 
> valid lifetimes. This does not conform to RFC 5280 Section 3.3 which states 
> that “An entry MUST NOT be removed from the CRL until it appears on one 
> regularly scheduled CRL issued beyond the revoked certificate's validity 
> period.”  We expect that few, if any, clients have been impacted.  For a 
> client to be impacted they would have to: clock skewed to a time before the 
> not-after field of the certificate; and have a CRL published after expiration 
> dropping the revoked certificate.
> 
> 
> 2. A timeline of the actions your CA took in response. A timeline is a 
> date-and-time-stamped sequence of all relevant events. This may include 
> events before the incident was reported, such as when a particular 
> requirement became applicable, or a document changed, or a bug was 
> introduced, or an audit was done.
> 
> August 16, 2019 15:00 UTC - Reviewer realizes that CRL will not publish for 
> one update past expiration
> August 16, 2019 16:00 UTC - Reviewer checks for other issues & talks to peers 
> to confirm problem
> August 16, 2019 17:00 UTC - Bug is filed to fix the issue with a proposed 
> design fix
> August 16, 2019 23:30 UTC - Fix is sent for review
> August 20, 2019 16:00 UTC - Remediation work is discussed & assigned
> August  20, 2019 18:00 UTC - Query to inspect revoked certificates is created 
> and sent to be run by production team for initial analysis.
> August 21, 2019 10:40 UTC - Production team runs query and returns result
> August 21, 2019 15:00 UTC - Reviewer analyzes data
> August 21, 2019 20:30 UTC - Reviewer asks for a follow up query to ascertain 
> if any certificates did not make it onto the CRL 
> August 22, 2019 07:00 UTC - Initial attempt at updating test systems with fix.
> August 22, 2019 09:00 UTC - Updating of test systems aborted due to 
> (unrelated) issues.
> August 22, 2019 07:00 UTC - Production team runs query for CRLs that may have 
> missed a certificate
> August 22, 2019 15:00 UTC - Reviewer ascertains that certificates under 
> question were on a CRL
> August 26, 2019 11:00 UTC - Second attempt at updating test systems with fix.
> August 26, 2019 13:00 UTC - Test systems updated, confirmed integrity of 
> fixed software.
> August 27, 2019 09:00 UTC - Confirmed fix is effective on test systems.
> August 27, 2019 10:00 UTC - present: Ongoing staged deployment to production 
> systems. Should complete fully by September 3, 2019 17:00 UTC (slightly 
> extended window due to push policies around holiday weekends. The rollout was 
> staged in accordance with Google's standard rollout procedures.)
> 
> 
> 3. Whether your CA has stopped, or has not yet stopped, issuing certificates 
> with the problem. 
> 
> The affected CA software has been patched.  It now populates expired 
> certificates in the CRL for 7 days after their expiration to ensure they 
> appear in at least one regularly issued CRL update.  Automated testing was 
> added as part of the same patch to check that revoked certificates are kept 
> in the CRL.  The patch was developed, tested, reviewed and landed within the 
> codebase by August 19, 2019.  The CRL entry removal bug has been fully 
> remediated.
> 
> 
> 4. A summary of the problematic certificates. For each problem: number of 
> certs, and the date the first and last certs with that problem were issued.
> 
> Investigation began on August 20, 2019 to discover the potential impact of 
> the logic bug. The CRL generation had contained the bug since its inception, 
> affecting all issuance under GTS 1O1 since March 2018. There were 200,263 
> revoked certificates during that time window. Almost all certificates were 
> for internal monitoring speci

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> So, this is something that would be helpfully clarified via either an IETF 
> draft,

There's already a 6962-bis draft [1] in IESG Last Call, which (when we 
finally complete it!) will obsolete RFC6962.  6962-bis redefines 
precertificates so that they're not actually X.509 certificates. 
Therefore, I don't think a "clarify RFC6962" draft is necessary.

Thinking aloud...
Does anything need to be clarified in 6962-bis though?
A (non-X.509) 6962-bis precertificate contains the serial number that 
will appear in the certificate (if or when that certificate is issued), 
so: Should the CA be forbidden, permitted or required to operate 
revocation services for that serial number once the 6962-bis 
precertificate has been produced but before the certificate has been 
issued?  (And is this a technical matter for 6962-bis to address, or a 
policy matter that's out of scope for the 6962-bis document?)


[1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

> 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 relevant 
> sections are blissfully ignorant of CT, and the correct behavior here was 
> unfortunately left out of RFC 6962, which should have clarified this.
> 
> Happy to help draft something.  There are some interesting complexities once 
> you dig deeper.
> 
> -Tim
> 
>> -Original Message-
>> From: dev-security-policy  On
>> Behalf Of Jeremy Rowley via dev-security-policy
>> Sent: Thursday, September 12, 2019 1:46 PM
>> To: Alex Cohn 
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>> 
>> Subject: RE: DigiCert OCSP services returns 1 byte
>>
>> 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 as the final cert if 
>> the
>> final cert doesn’t exist.
>>
>> I believe the intent is that a CT-naïve OCSP checker would work normally when
>> presented with a precert or a certificate. Afterall, a precert is really 
>> just a
>> certificate with a special extension.
>>
>> From: Alex Cohn 
>> Sent: Thursday, September 12, 2019 9:25 AM
>> To: Jeremy Rowley 
>> Cc: Wayne Thayer ; mozilla-dev-security-
>> pol...@lists.mozilla.org
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>> mailto:dev-security-
>> pol...@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 certificate exists and (ii) a CA must be able to revoke a pre-
>> certificate if revocation of the certificate is required under the Mozilla 
>> policy
>> and the corresponding certificate doesn't actually exist and therefore cannot
>> be revoked.
>>
>> Should a CA using a precertificate signing certificate be required to provide
>> OCSP services for their precertificates? Or is it on the relying party to 
>> calculate
>> the proper OCSP request for the final certificate and send that instead? In
>> other words, should we expect a CT-naïve OCSP checker to work normally
>> when presented, e.g., with https://crt.sh/?id=1868433277?
>>
>> Alex
>> ___
>> 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

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy