Re: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

I think that's perfectly clear but I wanted to double check in case "perfectly 
clear" was me misreading it. One thing that does come up a lot is whether a CA 
has to revoke a pre-certificate if the certificate doesn't actually issue. I 
think this has been adequately answered on the bug lists but would be good to 
codify.

For the language maybe:

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.



From: Wayne Thayer 
Sent: Wednesday, September 11, 2019 7:22:29 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity 
certificates apply even when a CA has issued a precertificate without issuing a 
corresponding certificate.


Do you have any suggestions for how I can improve/clarify?


On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof 
that a corresponding certificate has been issued" means a CA issuing a precert 
without the final cert must respond "good" unless the pre-cert is revoked? 
Responding unknown means the CA wouldn't know that they issued the cert, which 
means they disagree with the proof that a corresponding cert has been issued.

Jeremy

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, September 11, 2019 7:08 PM
To: 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Mozilla has, to-date, not published policies related to Certificate 
Transparency, but this is a case where a clarification would be helpful. I 
propose adding the following language to our "Required Practices" wiki page
[1]:

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 [2]. Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in a 
future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

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

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org>
 wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a
> signed response for a certificate where a pre-certificate existed by a
> certificate had not issued for whatever reason. The question asked was
> what type of OCSP services are required for a pre-cert if there is no
> other certificate. The answer we came up with is it should respond
> "GOOD" based on the Mozilla policy, not Unknown or any other response.
> Note that this was a bug in the DigiCert system but it lead to a fun internal 
> discussion.
> What I'm sharing is the outcome of the internal discuss

Re: Request to Include 4 Microsoft Root CAs

[Wayne Thayer via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1448093.

- Wayne

On Thu, Sep 5, 2019 at 5:16 PM Wayne Thayer  wrote:

> Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.
>
> Unless a CA has an existing EV policy OID associated with root(s) in our
> program, we have been strongly encouraging the use of the CAB Forum OID.
>
> This request is past the 3-week minimum discussion period. If no
> significant comments are posted, I will close it on Tuesday 10-September.
>
> - Wayne
>
> On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Hello,
>>
>> Is there an EV Policy OID assigned? I can't find it.
>>
>> - Daniel
>>
>>
>> Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:
>> > This request is for inclusion of the Microsoft RSA Root Certificate
>> > Authority 2017, Microsoft ECC Root Certificate Authority 2017,
>> Microsoft EV
>> > RSA Root Certificate Authority 2017, and Microsoft EV ECC Root
>> Certificate
>> > Authority 2017 trust anchors as documented in the following bug:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1448093
>> >
>> > * BR Self Assessment is
>> > https://bugzilla.mozilla.org/attachment.cgi?id=8989260
>> >
>> > * Summary of Information Gathered and Verified:
>> >
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275
>> >
>> > * Root Certificate Download URL:
>> > https://www.microsoft.com/pkiops/docs/repository.htm
>> >
>> > * CP/CPS:
>> > ** CP:
>> >
>> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
>> > ** CPS:
>> >
>> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf
>> >
>> > * This request is to include the roots with the websites trust bit
>> enabled,
>> > and with EV treatment.
>> >
>> > * Test Websites
>> > ** Valid: https://actrsaevroot2017.pki.microsoft.com/,
>> > https://actrsaroot2017.pki.microsoft.com/,
>> > https://acteccevroot2017.pki.microsoft.com/,
>> > https://acteccroot2017.pki.microsoft.com/
>> > ** Expired: https://exprsaevroot2017.pki.microsoft.com/,
>> > https://exprsaroot2017.pki.microsoft.com/,
>> > https://expeccevroot2017.pki.microsoft.com/,
>> > https://expeccroot2017.pki.microsoft.com/
>> > ** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
>> > https://rvkrsaroot2017.pki.microsoft.com/,
>> > https://rvkeccevroot2017.pki.microsoft.com/,
>> > https://rvkeccroot2017.pki.microsoft.com/
>> >
>> > * CRL URLs:
>> > ** ECC:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
>> > ** RSA:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
>> > ** EV ECC:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
>> > ** EV RSA:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl
>> >
>> > * OCSP URL:http://ocsp.msocsp.com
>> >
>> > * Audit: Annual audits are performed by BDO according to the WebTrust
>> for
>> > CA, BR, and EV audit criteria.
>> > ** WebTrust for CA:
>> https://bugzilla.mozilla.org/attachment.cgi?id=9083810
>> > ** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
>> > ** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813
>> >
>> > I’ve reviewed the CP, CPS, BR Self Assessment, and related information
>> for
>> > inclusion of the Microsoft roots that are being tracked in this bug and
>> > have the following comments:
>> >
>> > ==Good==
>> > * A root key generation ceremony audit report has been provided [1].
>> >
>> > ==Meh==
>> > * CPS section 3.2.4 stated that OU is not verified, however, BR section
>> > 7.1.4.2.2(i) does place requirements on this field, and the CPS made it
>> > unclear if these requirements are met. This was clarified in the latest
>> > version of the CPS.
>> > * CPS section 3.2.5 stated that Microsoft PKI Services shall verify
>> > authority for all certificate requests, and that for Domain Validated
>> > requests, this is done using one of the methods described in the BRs.
>> > Section 3.2.5 of the BRs only describes validation of authority for OV
>> > certificates using a reliable method of communication. This was
>> clarified
>> > in the latest version of the CPS.
>> > * CPS section 6.1.5 indicated that P-512 keys may be used, which would
>> > violate Mozilla policy. This was corrected in the latest version of the
>> CPS.
>> > * The content-type header in CRL responses is not set to
>> > 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280,
>> section
>> > 4.2.1.13). Microsoft explanation: the reason for the content-type being
>> set
>> > to octet-stream is that we use a content upload service at Microsoft
>> that
>> > hosts different types of content. All of the content in the service is
>> > hosted in Azure’s BLOB storage an

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

Do you have any suggestions for how I can improve/clarify?

On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley 
wrote:

> Hey Wayne - I take it that this "Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued" means a CA issuing
> a precert without the final cert must respond "good" unless the pre-cert is
> revoked? Responding unknown means the CA wouldn't know that they issued the
> cert, which means they disagree with the proof that a corresponding cert
> has been issued.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, September 11, 2019 7:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Mozilla has, to-date, not published policies related to Certificate
> Transparency, but this is a case where a clarification would be helpful. I
> propose adding the following language to our "Required Practices" wiki page
> [1]:
>
> 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 [2]. Mozilla recognizes a precertificate as
> > proof that a corresponding certificate has been issued.
> >
> > This means, for example, that the requirements for OCSP for end-entity
> > certificates apply even when a CA has issued a precertificate without
> > issuing a corresponding certificate.
> >
>
> I plan to add this to the wiki next week. I also plan to include this in
> in a future update to our Root Store Policy.
>
> I will greatly appreciate your constructive feedback on this proposal.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> [2] https://cabforum.org/pipermail/public/2014-January/002694.html
>
> On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Let me try that again since I didn't explain my original post very well.
> > Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
> >
> > What happened at DigiCert is that the OCSP service failed to return a
> > signed response for a certificate where a pre-certificate existed by a
> > certificate had not issued for whatever reason. The question asked was
> > what type of OCSP services are required for a pre-cert if there is no
> > other certificate. The answer we came up with is it should respond
> > "GOOD" based on the Mozilla policy, not Unknown or any other response.
> > Note that this was a bug in the DigiCert system but it lead to a fun
> internal discussion.
> > What I'm sharing is the outcome of the internal discussion - it's only
> > tangentially related to the bug, not the cause or remediation of it.
> >
> > Summary: Pre-certs require a standard OCSP response as if the pre-cert
> > was a normal cert. In fact, it's a mistake to ever think of pre-certs
> > as anything other than TLS certs, even if the poison extension exists.
> >
> > The question comes up because the BRs don't cover pre-certs. However,
> > as Ryan points out, the browsers sort-of cover this as does the
> > Mozilla policy. The browser say this is a promise to issue the cert
> > and mis-issuance of a pre-cert is the same as mis-issuance of a cert.
> > Although this isn't mis-issuance in the traditional profile sense, the
> > lack of OCSP services for the pre-cert is a violation of the Mozilla
> > policy. I couldn't figure out if it's a violation of the Chrome policy
> > since Chrome says it's a promise to issue a cert. If the cert hasn't
> > issued, then I'm not sure where that puts the OCSP service for Chrome.
> > Regardless, according to Mozilla's policy, the require

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof 
that a corresponding certificate has been issued" means a CA issuing a precert 
without the final cert must respond "good" unless the pre-cert is revoked? 
Responding unknown means the CA wouldn't know that they issued the cert, which 
means they disagree with the proof that a corresponding cert has been issued.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, September 11, 2019 7:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Mozilla has, to-date, not published policies related to Certificate 
Transparency, but this is a case where a clarification would be helpful. I 
propose adding the following language to our "Required Practices" wiki page
[1]:

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 [2]. Mozilla recognizes a precertificate as 
> proof that a corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity 
> certificates apply even when a CA has issued a precertificate without 
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in a 
future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

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

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a 
> signed response for a certificate where a pre-certificate existed by a 
> certificate had not issued for whatever reason. The question asked was 
> what type of OCSP services are required for a pre-cert if there is no 
> other certificate. The answer we came up with is it should respond 
> "GOOD" based on the Mozilla policy, not Unknown or any other response. 
> Note that this was a bug in the DigiCert system but it lead to a fun internal 
> discussion.
> What I'm sharing is the outcome of the internal discussion - it's only 
> tangentially related to the bug, not the cause or remediation of it.
>
> Summary: Pre-certs require a standard OCSP response as if the pre-cert 
> was a normal cert. In fact, it's a mistake to ever think of pre-certs 
> as anything other than TLS certs, even if the poison extension exists.
>
> The question comes up because the BRs don't cover pre-certs. However, 
> as Ryan points out, the browsers sort-of cover this as does the 
> Mozilla policy. The browser say this is a promise to issue the cert 
> and mis-issuance of a pre-cert is the same as mis-issuance of a cert. 
> Although this isn't mis-issuance in the traditional profile sense, the 
> lack of OCSP services for the pre-cert is a violation of the Mozilla 
> policy. I couldn't figure out if it's a violation of the Chrome policy 
> since Chrome says it's a promise to issue a cert. If the cert hasn't 
> issued, then I'm not sure where that puts the OCSP service for Chrome. 
> Regardless, according to Mozilla's policy, the requirement is that 
> regardless of how long the cert takes to issue, the CA must provide 
> OCSP services for the pre-cert. The reason is Mozilla requires an OCSP 
> for each end-entity certificate listing an AIA in the certificate. Pre-certs 
> are end-entity certificates.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, August 29, 2019 11:55 AM
> To: Peter Bowen ; Ryan Sleevi 
> Cc: Curt Spann ;
> moz

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Mozilla has, to-date, not published policies related to Certificate
Transparency, but this is a case where a clarification would be helpful. I
propose adding the following language to our "Required Practices" wiki page
[1]:

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 [2]. Mozilla recognizes a precertificate as proof that a
> corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in
a future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

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

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a
> signed response for a certificate where a pre-certificate existed by a
> certificate had not issued for whatever reason. The question asked was what
> type of OCSP services are required for a pre-cert if there is no other
> certificate. The answer we came up with is it should respond "GOOD" based
> on the Mozilla policy, not Unknown or any other response. Note that this
> was a bug in the DigiCert system but it lead to a fun internal discussion.
> What I'm sharing is the outcome of the internal discussion - it's only
> tangentially related to the bug, not the cause or remediation of it.
>
> Summary: Pre-certs require a standard OCSP response as if the pre-cert was
> a normal cert. In fact, it's a mistake to ever think of pre-certs as
> anything other than TLS certs, even if the poison extension exists.
>
> The question comes up because the BRs don't cover pre-certs. However, as
> Ryan points out, the browsers sort-of cover this as does the Mozilla
> policy. The browser say this is a promise to issue the cert and
> mis-issuance of a pre-cert is the same as mis-issuance of a cert. Although
> this isn't mis-issuance in the traditional profile sense, the lack of OCSP
> services for the pre-cert is a violation of the Mozilla policy. I couldn't
> figure out if it's a violation of the Chrome policy since Chrome says it's
> a promise to issue a cert. If the cert hasn't issued, then I'm not sure
> where that puts the OCSP service for Chrome. Regardless, according to
> Mozilla's policy, the requirement is that regardless of how long the cert
> takes to issue, the CA must provide OCSP services for the pre-cert. The
> reason is Mozilla requires an OCSP for each end-entity certificate listing
> an AIA in the certificate. Pre-certs are end-entity certificates.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, August 29, 2019 11:55 AM
> To: Peter Bowen ; Ryan Sleevi 
> Cc: Curt Spann ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Yes. That was the point of my post. There is a requirement fo return an
> ocsp repsonse for a pre cert where the cert hasn't issued because of the
> Mozilla policy. Hence our failure was a Mozilla policy violation even if no
> practical system can use the response because no actual cert (without a
> posion extension) exists.
> 
> From: Peter Bowen 
> Sent: Thursday, August 29, 2019 11:44:11 AM
> To: Ryan Sleevi 
> Cc: Jeremy Rowley ; Curt Spann <
> csp...@apple.com>; mozilla-dev-security-pol...@lists.mozilla.org <
> mozilla-dev-security-pol...@lists.mozilla.org>
> 

Re: EV Jurisdiction of Incorporation

[Ryan Sleevi via dev-security-policy]

Thanks Jeremy,

This is great. I filed https://github.com/mozilla/pkipolicy/issues/188
because this seems like something that can be reused and perhaps even
required by policy.

On Wed, Sep 11, 2019 at 5:59 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Everyone,
>
>
>
> One of my goals at DigiCert is provide greater transparency. One of the
> ideas I’ve kicked around is community-drive EV or EV transparency.  To
> start that off, I thought I’d share the sources we use verification of the
> jurisdiction of incorporation/registration here. This list is available
> here https://www.digicert.com/legal-repository/ (direct:
> https://www.digicert.com/wp-content/uploads/2019/09/DigiCert-Approved-Incorporating-Agencies.xlsx).
> Sharing this was suggested from the community and the digicert leadership
> team thought it was a great idea. Not only does it get community feedback
> on the sources we use (or shouldn’t use), but it may identify sources that
> other CAs could use to do the verification. The idea is we could build a
> definitive master list that the CAB forum could use for verification of EV.
> This would further standardize EV. If we start including a reference to the
> source, then someone could easily verify the accuracy of the information
> and the identity of an organization.  This would solve a major headache
> I’ve had with EV – you can’t see where the JOI information originates.
>
>
>
> For reference, section 8.5.2 requires a CA to verify the legal existence
> of an entity through “a filing with (or an act of) the Incorporating or
> Registration Agency in its Jurisdiction of Incorporation or Registration
> (e.g., by issuance of a certificate of incorporation, registration number,
> etc.) or created or recognized by a Government Agency (e.g. under a
> charter, treaty, convention, or equivalent recognition instrument)”. This
> is far broader than an incorporating agency, but we use incorporating
> agencies as the primary source, and we’re working to eliminate sources like
> SEC.   This source list combines information from primary and secondary
> sources (both incorporating and registration sources).
>
>
>
> Sharing this kind of information helps us get to the end-goal of a more
> transparent EV ecosystem and builds a more community-driven EV practice.
> I’m looking forward to your feedback. Also, let me know if this is
> interesting, and what else you’d like to see.
>
>
>
> Thanks!
>
>
>
> Jeremy
>
>
>
>
>
> ___
> 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

EV Jurisdiction of Incorporation

[Jeremy Rowley via dev-security-policy]

Hi Everyone,



One of my goals at DigiCert is provide greater transparency. One of the ideas 
I’ve kicked around is community-drive EV or EV transparency.  To start that 
off, I thought I’d share the sources we use verification of the jurisdiction of 
incorporation/registration here. This list is available here 
https://www.digicert.com/legal-repository/ (direct: 
https://www.digicert.com/wp-content/uploads/2019/09/DigiCert-Approved-Incorporating-Agencies.xlsx).
  Sharing this was suggested from the community and the digicert leadership 
team thought it was a great idea. Not only does it get community feedback on 
the sources we use (or shouldn’t use), but it may identify sources that other 
CAs could use to do the verification. The idea is we could build a definitive 
master list that the CAB forum could use for verification of EV. This would 
further standardize EV. If we start including a reference to the source, then 
someone could easily verify the accuracy of the information and the identity of 
an organization.  This would solve a major headache I’ve had with EV – you 
can’t see where the JOI information originates.



For reference, section 8.5.2 requires a CA to verify the legal existence of an 
entity through “a filing with (or an act of) the Incorporating or Registration 
Agency in its Jurisdiction of Incorporation or Registration (e.g., by issuance 
of a certificate of incorporation, registration number, etc.) or created or 
recognized by a Government Agency (e.g. under a charter, treaty, convention, or 
equivalent recognition instrument)”. This is far broader than an incorporating 
agency, but we use incorporating agencies as the primary source, and we’re 
working to eliminate sources like SEC.   This source list combines information 
from primary and secondary sources (both incorporating and registration 
sources).

 

Sharing this kind of information helps us get to the end-goal of a more 
transparent EV ecosystem and builds a more community-driven EV practice. I’m 
looking forward to your feedback. Also, let me know if this is interesting, and 
what else you’d like to see.



Thanks!



Jeremy

 



___
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

[rich.salz--- via dev-security-policy]

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

Re: SSL.com: OCSP Responder returns incorrect status for certificates failing CT submission

[Chris Kemmerer via dev-security-policy]

Copypaste fail, apologies. Correct bug is:

https://bugzilla.mozilla.org/show_bug.cgi?id=1579509


On Wednesday, September 11, 2019 at 11:30:57 AM UTC-5, Christopher Kemmerer 
wrote:
> We have been monitoring the discussions on the m.d.s.p. mailing list 
> and, after the announcements of GlobalSign and Let's Encrypt, found that 
> our OCSP responder is affected by the same issue.
> 
> In particular, whenever a precertificate is generated, but CT submission 
> fails, EJBCA will fail to create the corresponding certificate, and thus 
> reply with the status "Unknown" on OCSP queries.
> 
> We have found out that this affected 52 certificates. None of these 
> certificates have been generated or delivered to clients.
> 
> Examples:
> 
> https://crt.sh/?id=1720920023&opt=ocsp
> https://crt.sh/?id=1677051376&opt=ocsp
> 
> We have opened a bug with PrimeKey to address the EJBCA issue. Until 
> this is corrected by PrimeKey we have mitigated this issue using an 
> in-house patch.
> 
> We have also opened a bug in Bugzilla to track the progress of this 
> issue at:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=15795
> 
> -- 
> Chris Kemmerer
> Manager of Operations
> SSL.com
> 
> ~
> ~ To find the reefs, look
>  for the wrecks.~
> ~

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

SSL.com: OCSP Responder returns incorrect status for certificates failing CT submission

[Christopher Kemmerer via dev-security-policy]

We have been monitoring the discussions on the m.d.s.p. mailing list 
and, after the announcements of GlobalSign and Let's Encrypt, found that 
our OCSP responder is affected by the same issue.


In particular, whenever a precertificate is generated, but CT submission 
fails, EJBCA will fail to create the corresponding certificate, and thus 
reply with the status "Unknown" on OCSP queries.


We have found out that this affected 52 certificates. None of these 
certificates have been generated or delivered to clients.


Examples:

https://crt.sh/?id=1720920023&opt=ocsp
https://crt.sh/?id=1677051376&opt=ocsp

We have opened a bug with PrimeKey to address the EJBCA issue. Until 
this is corrected by PrimeKey we have mitigated this issue using an 
in-house patch.


We have also opened a bug in Bugzilla to track the progress of this 
issue at:


https://bugzilla.mozilla.org/show_bug.cgi?id=15795

--
Chris Kemmerer
Manager of Operations
SSL.com

~
~ To find the reefs, look
 for the wrecks.~
~

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