Re: DigiCert OCSP services returns 1 byte

[Jakob Bohm via dev-security-policy]

On 17/09/2019 00:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:
> 
>> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
>> 
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
>>
>> However, this is Schrödinger's "certificate that has not been issued",
>> because a Precertificate has been issued that has the same serial number
>> (as the "certificate presumed to exist" that doesn't actually exist).
>>
>> And so at this point ISTM that the OCSP responder is expected to
>> implement two conflicting requirements for the serial number in question:
>> (1) MUST respond "good", because an unrevoked/unexpired
>> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
>> response).
>> (2) SHOULD NOT respond "good" (see BR 4.9.10).
>>
>>
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
> 
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
> 
> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that this is a violation. [1]
> 

In any networked system, delays are inevitable.

If data (in this case replication status data) is to be reliably
replicated, there will be a further delay to ensure that bad data is
not forced onto all mirrors too quickly (Consider earlier incident(s)
where corrupted revocation data was rolled out to all the servers used
by a CA.  Also consider the delay in the recent rollout of incident-
initiated revocations by GTS).

Thus it is technically inevitable that some revocation servers will
respond "unknown" for a freshly issued (as in signed) certificate.

So the real question is which of the various steps in a CT-logged
issuance are allowed to happen while the certificate status is
replicated to all the OCSP and CRL servers operated by a CA.

It is of cause possible to pretend that a signed but not yet submitted
certificate and/or preCertificate doesn't exist, creating a strict
serialization of steps:

  1. Allocate serial number and other content.
  2. Replicate this allocation to survive crashes.
  3. Sign the preCertificate, canned "good" OCSP responses and a fresh
CRL (if the CRL contains extensions describing the valid serial
numbers).
  4. Replicate the preCertificate and OCSP responses to survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature).
  5. Wait for all those OCSP responses and CRLs to reach all mirrors.
  6. Record the completion of this rollout in the replicated dataset.
  7. Submit the preCertificate to CT logs (which unnecessarily check
that the mirrors report "good" instead of "unknown" according to
the strict policy);
  8. Wait for all the CT logs to return SCTs.
  9. Replicate the SCTs to survive crashes.
(failure during this step will require extracting SCTs from the
CT logs or revoking the preCertificate and starting over).
 10. Sign the actual certificate and any further canned OCSP responses
   and CRLs that refer to the contents or signature of the actual
   certificate.
 11. Replicate the actual certificate and any new revocation data to
   survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature,
alternatively revoke and start over).
 12. Wait for any such OCSP responses and CRLs to reach all mirrors.
 13. Record the completion of this rollout in the replicated dataset.
(Failure during this step results in having to check the rollout 
status again).
 14. Submit the actual certificate to CT logs and await acknowledgement.
 15. Finally send the actual certificate to the subscriber.

My alternative 4 paragraph proposal (rest was rationale) was to accept
the existence of delays, aim for eventual consistency, maximize overlap
between the operations by allowing the initial CT submission to happen
before all revocation 

Re: DigiCert OCSP services returns 1 byte

[Kurt Roeckx via dev-security-policy]

On 2019-09-16 14:02, Rob Stradling wrote:


ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
 that has not been issued, then the responder SHOULD NOT respond with
 a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is
"presumed to exist" but the CA has not actually issued it, then to my
mind that's a "certificate that has not been issued"; and therefore, the
OCSP 'responder SHOULD NOT respond with a "good" status'.


The problem of course is that you don't query OCSP about a certificate, 
you query it about a serial number. And that serial number has been 
issued. So maybe the BRs should say serial number instead of certificate?



Kurt
___
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

[Rob Stradling via dev-security-policy]

On 16/09/2019 23:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:

> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in
> question:
>     (1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>     (2) SHOULD NOT respond "good" (see BR 4.9.10).
> 
> If I'm reading BR 4.9.10 correctly, the situation is worse because it 
> goes on to state "Effective 1 August 2013, OCSP responders for CAs which 
> are not Technically Constrained in line with Section 7.1.5 MUST NOT 
> respond with a "good" status for such certificates." (referring to 
> 'certificates that have not been issued' from the prior paragraph)

Thanks Wayne.  You're right.

(I read the "SHOULD NOT" requirement, forgot it had been superseded, and 
didn't read further.  I wonder if it would be reasonable to remove the 
superseded requirement from the BRs now, given that it was superseded 
over 6 years ago?)

> If the desired outcome is for CAs to respond "good" to a precertificate 
> without a corresponding certificate, we could override the BRs in 
> Mozilla policy, but I'd want to get the BRs updated quickly as Rob 
> suggested to avoid audit findings.

+1

> The other piece of this policy that's still unclear to me relates to the 
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA 
> to provide an "unknown" OCSP response for an issued certificate? If not, 
> should it be? The implication here would be that CAs responding 
> "unknown" to precertificates without corresponding certificates are 
> doing the right thing, despite prior precedent indicating that this is a 
> violation. [1]

This is making my brain hurt.

> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> 
> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5
> :
>     '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'
> 
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this
> 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring
> 'MUST
> respond "good"'.
> 
> I can't say I like this conclusion, but nonetheless it is the
> conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
> 
> IDEAS FOR FIXING IT:
> 
> Long-term:
>     - In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
> 
> Short-term:
>     - I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>     - I would also like to see BR 4.9.10 revised to say something
> roughly
> along these lines:
>     'If the OCSP responder receives a status request for a serial number
>      that has not been allocated by the CA, then the responder
> SHOULD NOT
>      respond with a "good" status.'
> 
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the
> corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com 
> 

-- 
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

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:
>
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> > 
> >
> > If a certificate (with embedded SCTs and no CT poison extension) is
> > "presumed to exist" but the CA has not actually issued it, then to my
> > mind that's a "certificate that has not been issued"; and therefore, the
> > OCSP 'responder SHOULD NOT respond with a "good" status'.
> >
> > However, this is Schrödinger's "certificate that has not been issued",
> > because a Precertificate has been issued that has the same serial number
> > (as the "certificate presumed to exist" that doesn't actually exist).
> >
> > And so at this point ISTM that the OCSP responder is expected to
> > implement two conflicting requirements for the serial number in question:
> >(1) MUST respond "good", because an unrevoked/unexpired
> > precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> > response).
> >(2) SHOULD NOT respond "good" (see BR 4.9.10).
> >
> >
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
>
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
>

We've had CAs argue, for better or worse, that they've "revoked" a
certificate by setting a revoked flag within their database, which then
will eventually result in the production of CRLs and signed OCSP responses
to reflect that status, and then distribute those responses to their CDNs
for the distribution points. In this model, the CA is arguing "revoked" is
on the basis of a change within their database, rather than the artifacts
produced from such a change. Some have even had online services (via HTML
forms) where you could check specific serial numbers, with CAPTCHAs, to
compare the database vs the produced/signed artifacts.

Similarly, we've had CAs argue that they've had certificates that were
issued, but were not active, based on a status change in their database,
where 'active' meant that they signed the certificate. This again suggests
a flow where "issued" is the status of committing to the database, rather
than producing the signed artifact.

For better or worse, if we accept that definition, which admittedly opens a
new set of issues to work through, the act of assigning the serial number
and TBSCertificate is the act of issuance, rather than the production of
the signed artifact. For better or worse, the BRs support as much with the
discussion of revocation, because the CAs that argued this highlighted that
the act of distributing OCSP/CRL responses is "publishing" the revocation
(hence the language in 4.9.5 regarding timeframes, and the language in
4.9.7 about publishing CRLs).

Recall that these issues highlighted here were not new or unexpected. If
you dig through the discussion of Ballot 134, you'll find Brian Smith
rightfully flagged these issues, which were the result of somewhat rushed
attempts to get language in the BRs. Much like Qualified Auditors within
Policy, it may be worth treating this as an exception and being deliberate
in how any matters of note or qualifications are treated, while better
language is proposed?

You can find the past discussion at
https://cabforum.org/pipermail/public/2014-September/003930.html . Brian
Smith, formerly of Mozilla, highlighted issues with the attempts to carve
out just duplicate serials, perhaps best in
https://cabforum.org/pipermail/public/2014-September/004006.html

If you look at that past discussion, you can also see debates about the
ASN.1 / SignedData approach being used, and how Precerts-are-not-Certs in
the same way that OCSPResponses-are-not-certs, even if all three used the
SignedData construct, is another interpretation, at which point, this issue
also washes out. You can also find discussions of alternative approaches,
which specified the exact encoding conditions in which a duplicate serial
would be permitted (treating precerts-as-actually-certs, rather than
precerts-as-committments-of-equivalent-certs)


> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that 

CRL for decommissioned CA

[nenyotoso--- via dev-security-policy]

Hi,

While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and is no 
longer in operation [2],
I become aware of CRL endpoint of both the CA and at least one of sub-CA is 
unavailable.

a sub-CA: https://crt.sh/?id=9341006
leaf certificate issued from the sub-CA: https://crt.sh/?id=524524172
(you can browse all issued certificates from the sub-CA with 
https://crt.sh/?Identity=%25=1419)

Both of them was revoked but CRL endpoint is unavailable now with HTTP 404 
error response.
OCSP also fails.

Is it OK to abandon CRL for the decommissioned CA even if there are still 
unexpired certificates?
The certificates was revoked but we have no way to validate it in a PKI-ish 
manner...

Sorry if it is off-topic because the CA has never been approved as Root CA by 
Mozilla.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=870185
[2] https://www.gpki.go.jp/apca2/ (only in Japanese)

Sincerely,

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of September 2019 Audit Reminder Emails
Date: Tue, 17 Sep 2019 19:00:10 + (GMT)


Mozilla: Your root is in danger of being removed
CA Owner: AC Camerfirma, S.A.
Root Certificates:
   Chambers of Commerce Root - 2008**
   Global Chambersign Root - 2008**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995928
Standard Audit Period End Date: 2018-04-13
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930
BR Audit Period End Date: 2018-04-13
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995931
EV Audit Period End Date: 2018-04-13
CA Comments: null

Note: CA requested updated BR and EV audit statements from their auditor 
for these roots.




Mozilla: Audit Reminder
CA Owner: E-Tugra
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf

Standard Audit Period End Date: 2018-08-03
BR Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf

BR Audit Period End Date: 2018-08-03
EV Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2018.pdf

EV Audit Period End Date: 2018-08-03
CA Comments: null



Mozilla: Audit Reminder
CA Owner: IdenTrust Services, LLC
Root Certificates:
   IdenTrust Commercial Root CA 1
   IdenTrust Public Sector Root CA 1
   DST Root CA X3
Standard Audit: 
https://bug1484318.bmoattachments.org/attachment.cgi?id=9006625

Standard Audit Period End Date: 2018-06-30
BR Audit: https://bug1484318.bmoattachments.org/attachment.cgi?id=9006626
BR Audit Period End Date: 2018-06-30
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: SECOM Trust Systems CO., LTD.
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1**
   Security Communication RootCA2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222449

Standard Audit Period End Date: 2018-06-08
BR Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222450

BR Audit Period End Date: 2018-06-08
EV Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222451

EV Audit Period End Date: 2018-06-08
CA Comments: null

Note: Audit Case looks good from Mozilla's perspective.



Mozilla: Audit Reminder
CA Owner: China Financial Certification Authority (CFCA)
Root Certificates:
   CFCA EV ROOT
Standard Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223505

Standard Audit Period End Date: 2018-07-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223506

BR Audit Period End Date: 2018-07-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=223507

EV Audit Period End Date: 2018-07-31
CA Comments: null




___
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

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org 
> > wrote:
> 
>> 
>> 
>>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> Hi Kurt.  I agree, hence why I proposed:
>>> 
>>>  "- I would also like to see BR 4.9.10 revised to say something roughly
>>> along these lines:
>>>   'If the OCSP responder receives a status request for a serial number
>>>that has not been allocated by the CA, then the responder SHOULD NOT
>>>respond with a "good" status.’"
>> 
>> I suppose one issue there is for CAs which allocate the serial number very
>> early on in the issuance workflow - signing a dummy certificate with an
>> untrusted key, for instance, but not committing the CA to actually
>> producing either a pre-certificate or certificate (e.g, because the
>> applicant has insufficient funds to complete the process). It would not
>> seem correct to start answering (affirmatively) OCSP requests where no
>> artefact has been signed by a trusted key.
>> 
> 
> Why does a CA need to sign something to allocate a serial? Could you expand
> a bit more on that?
> 

Yes - on further consideration, I could have been a lot clearer. I didn’t mean 
that a CA _has_ to sign something to allocate a serial in some internal 
database; merely that the allocation of a serial number, in itself, isn’t the 
trigger (in my opinion, of course) for any OCSP server to start responding to 
the (Issuer, Serial Number) request with successful response codes.

What I meant was that some workflows allocate a serial number, sign a dummy 
certificate containing that serial number (with an untrusted key), which then 
flows through with linting checks, and so on. But the decision to sign the said 
certificate with a trusted key has not yet been made (officially). But when any 
object (precertificate, certificate) containing that allocated serial number 
gets signed with a trusted key, it is a reasonable expectation for relying 
parties to be able to query OCSP services and not get a “Never heard of it” 
answer (whether that’s a RFC 6960 4.4.8 response, or an “unauthorized”, or 
whatever).

In other words, Rob’s original language which refers purely to the 
(CA-internal) allocation of the serial number as the triggering event seems not 
to cover all relevant cases. Not that I’ve been able to come up with any better 
language, I should add.

Regards,

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

Re: CRL for decommissioned CA

[Wayne Thayer via dev-security-policy]

On Tue, Sep 17, 2019 at 8:23 AM nenyotoso--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and
> is no longer in operation [2],
> I become aware of CRL endpoint of both the CA and at least one of sub-CA
> is unavailable.
>
> a sub-CA: https://crt.sh/?id=9341006
> leaf certificate issued from the sub-CA: https://crt.sh/?id=524524172
> (you can browse all issued certificates from the sub-CA with
> https://crt.sh/?Identity=%25=1419)
>
> Both of them was revoked but CRL endpoint is unavailable now with HTTP 404
> error response.
> OCSP also fails.
>
> Is it OK to abandon CRL for the decommissioned CA even if there are still
> unexpired certificates?
> The certificates was revoked but we have no way to validate it in a
> PKI-ish manner...
>
>
If there are user agents that continue to trust this root, then this is
certainly a bad thing.

Sorry if it is off-topic because the CA has never been approved as Root CA
> by Mozilla.
>

It appears that Microsoft may still trust this root. I'll inform them.

Thanks,

Wayne
___
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]

Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:

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 states “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 [1]. Otherwise, Mozilla infers from the existence of a
> precertificate that a corresponding certificate has been issued.
>
> This means, for example, that:
>
> * 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
> * 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.
> * If any corresponding certificate with the same serial number and issuer
> exists, and can not be verified to match the precertificate using the
> algorithms in RFC 6962, it will be considered misissued.
> * In examining historical issuance, the CA must consider both final
> certificates and precertificates, even if the precertificate did not
> ultimately result in the issuance of a certificate.
>

I propose adding this language to our "Required Practices" wiki page [2],
then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
serial numbers. That still leaves some uncertainty about the use of the
"unknown" response for precertificates (and in general), although Ryan made
some good points about why using this status beyond the very narrow scope
described in RFC 6960 section 2.2 is a bad idea.

Once again, I will greatly appreciate your feedback on this topic. Since
this is a practice and not official policy, I'll go ahead and update the
wiki when I sense that we're in agreement here.

- Wayne

[1] https://cabforum.org/pipermail/public/2014-January/002694.html
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>> wrote:
> >
> >>
> >>
> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>>
> >>> Hi Kurt.  I agree, hence why I proposed:
> >>>
> >>>  "- I would also like to see BR 4.9.10 revised to say something roughly
> >>> along these lines:
> >>>   'If the OCSP responder receives a status request for a serial number
> >>>that has not been allocated by the CA, then the responder SHOULD NOT
> >>>respond with a "good" status.’"
> >>
> >> I suppose one issue there is for CAs which allocate the serial number
> very
> >> early on in the issuance workflow - signing a dummy certificate with an
> >> untrusted key, for instance, but not committing the CA to actually
> >> producing either a pre-certificate or certificate (e.g, because the
> >> applicant has insufficient funds to complete the process). It would not
> >> seem correct to start answering (affirmatively) OCSP requests where no
> >> artefact has been signed by a trusted key.
> >>
> >
> > Why does a CA need to sign something to allocate a serial? Could you
> expand
> > a bit more on that?
> >
>
> Yes - on further consideration, I could have been a lot clearer. I didn’t
> mean that a CA _has_ to sign something to allocate a serial in some
> internal database; merely that the allocation of a serial number, in
> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
> start responding to the (Issuer, Serial Number) request with successful
> response codes.
>
> What I meant was that some workflows allocate a serial number, sign a
> dummy certificate containing that serial number (with an untrusted key),
> which then 

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Kurt.  I agree, hence why I proposed:
> >
> >   "- I would also like to see BR 4.9.10 revised to say something roughly
> > along these lines:
> >'If the OCSP responder receives a status request for a serial number
> > that has not been allocated by the CA, then the responder SHOULD NOT
> > respond with a "good" status.’"
>
> I suppose one issue there is for CAs which allocate the serial number very
> early on in the issuance workflow - signing a dummy certificate with an
> untrusted key, for instance, but not committing the CA to actually
> producing either a pre-certificate or certificate (e.g, because the
> applicant has insufficient funds to complete the process). It would not
> seem correct to start answering (affirmatively) OCSP requests where no
> artefact has been signed by a trusted key.
>

Why does a CA need to sign something to allocate a serial? Could you expand
a bit more on that?


> It seems to me that the trigger point to start answering OCSP requests for
> a (Issuer, Serial Number) request would be when the serial number has been
> allocated AND an artefact has been signed by an issuer private key.
>
> In other words, a CA might well allocate a serial number, which, if all
> goes well, will find its way into a certificate; but until a publicly
> trusted signature has been made on a TBSCertificate containing that serial
> number, an OCSP responder is behaving properly were it to answer “Never
> heard of that serial number for that Issuer”.
>

I'm not sure I follow why that seems to be?
___
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

[Rob Stradling via dev-security-policy]

On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote:
> On 2019-09-16 14:02, Rob Stradling wrote:
>>
>> ISTM that this "certificate presumed to exist" concept doesn't play
>> nicely with the current wording of BR 4.9.10:
>>     'If the OCSP responder receives a request for status of a certificate
>>  that has not been issued, then the responder SHOULD NOT respond with
>>  a "good" status.'
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
> 
> The problem of course is that you don't query OCSP about a certificate, 
> you query it about a serial number. And that serial number has been 
> issued. So maybe the BRs should say serial number instead of certificate?

Hi Kurt.  I agree, hence why I proposed:

   "- I would also like to see BR 4.9.10 revised to say something roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
 that has not been allocated by the CA, then the responder SHOULD NOT
 respond with a "good" status.'"

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

___
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

[Neil Dunbar via dev-security-policy]

> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy 
>  wrote:
> 
> Hi Kurt.  I agree, hence why I proposed:
> 
>   "- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.’"

I suppose one issue there is for CAs which allocate the serial number very 
early on in the issuance workflow - signing a dummy certificate with an 
untrusted key, for instance, but not committing the CA to actually producing 
either a pre-certificate or certificate (e.g, because the applicant has 
insufficient funds to complete the process). It would not seem correct to start 
answering (affirmatively) OCSP requests where no artefact has been signed by a 
trusted key.

It seems to me that the trigger point to start answering OCSP requests for a 
(Issuer, Serial Number) request would be when the serial number has been 
allocated AND an artefact has been signed by an issuer private key.

In other words, a CA might well allocate a serial number, which, if all goes 
well, will find its way into a certificate; but until a publicly trusted 
signature has been made on a TBSCertificate containing that serial number, an 
OCSP responder is behaving properly were it to answer “Never heard of that 
serial number for that Issuer”.

Regards,

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