Transfer of QuoVadis to DigiCert

2019-01-14 Thread Jeremy Rowley via dev-security-policy 
Hey all,

You may have seen that DigiCert is purchasing the QuoVadis PKI from WISeKey, 
including all public root operations. With the closing date drawing closer, I 
wanted to start the discussion and give the Mozilla community the notice 
required under Section 8 of the Mozilla CA policy.

Let me know what questions you have. I'll do my best to answer them, although 
many of the answers will likely have to wait until the official close date.

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

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Matt Palmer via dev-security-policy 
On Mon, Jan 14, 2019 at 05:18:18PM -0700, Wayne Thayer via dev-security-policy 
wrote:
> * Fairly recent misissuance under the currently included Hong Kong Post
> Root CA 1: O and OU fields too long [4]. These certificates have all been
> revoked, but no incident report was ever filed.

I think that, at the very least, all incidents against existing roots should
be resolved to Mozilla's satisfaction before any new roots from the same
organisation are considered for inclusion.

- Matt

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

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Man Ho via dev-security-policy 

On 15-Jan-19 12:31 PM, Ian Carroll via dev-security-policy wrote:
> from looking at [3] I think it should be a
> very negative mark against a CA to have to OneCRL one of their
> intermediates.

[3] was reported and discussed three years ago. When I look at it 
positively today, it does remind me that it's one of the reasons for our 
decision to separate root CAs for SSL certificates and non-SSL 
certificates. As far as I know, browsers and the web PKI community now 
encourage or even require the separation of CAs for different usage of 
certificate, e.g. time stamping, code signing, S/MIME, and SSL 
certificates.  So, if there is a web PKI standard, we are actually glad 
to follow.

--Man Ho


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

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Ian Carroll via dev-security-policy 
I do not usually comment on new CA applications, so take this with whatever
grain of salt you'd like, but from looking at [3] I think it should be a
very negative mark against a CA to have to OneCRL one of their
intermediates. If the CA is not committed to closely following web PKI
standards, it's not clear to me that they should be allowed to be trusted
in the web PKI. Combined with the lack of incident reports, I'd hope the
impact this organization could have in the future is considered.

On Mon, Jan 14, 2019 at 4:19 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This request is for inclusion of the Government of Hong Kong, Hongkong
> Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
> following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306
>
> * BR Self Assessment is here:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480
>
> * Summary of Information Gathered and Verified:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8980482
>
> * CP/CPS:
> CP: there is no CP
> CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf
>
> * This request is to include the root with the websites trust bit enabled
> and EV treatment.
>
> * EV Policy OID: 2.23.140.1.1
>
> * Test Websites
> https://valid-ev.ecert.gov.hk/
> https://expired-ev.hongkongpost.gov.hk
> https://revoked-ev.hongkongpost.gov.hk
>
> * CRL URLs:
> http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
> http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl
>
> * OCSP URL:
> http://ocsp1.hongkongpost.gov.hk
>
> * Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
> according to the WebTrust for CA, BR, and EV audit criteria.
> WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
> BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
> EV:
>
> https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for
> inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
> this bug and have the following comments:
>
> ==Good==
> This root is relatively new, has continuous BR audit coverage, and appears
> to have only signed certificates for the required test websites.
>
> ==Meh==
> * The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
> that EV certificates for the test sites were issued in May 2018, one can
> argue that EVGL section 17.4 required a period-of-time audit to have been
> completed in October rather than December as was the case. However, it has
> been common for CAs to argue that certificates for test websites don’t
> count and I have not yet published clear guidance on this issue.
> * There is no document referenced as a CP. Hongkong Post says that the
> document is a combined CP/CPS.
> * In 2016, it was discovered that Hongkong Post was issuing SHA-1
> certificates with non-random serial numbers that could be used for TLS in
> Firefox [2] [3]. The problem was resolved by adding the problematic
> intermediate certificate to OneCRL.
> * The CPS permits external RAs, but according to Appendix E, there are none
> at present. I would prefer that the CPS clearly state that domain
> validation functions are never delegated.
> * Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
> the bug that differ from the published versions 2 and 3 in their
> repository. The latest version “4” is marked as a “Pre-production CPS”.
> They state that “…we cannot issue EV certificate to customers until
> Mozilla, or at least some other root certificate programs, have granted EV
> treatment to our root certificate. So, we do not yet publish the CPS in
> order to avoid confusion to customers.”
>
> ==Bad==
> * Fairly recent misissuance under the currently included Hong Kong Post
> Root CA 1: O and OU fields too long [4]. These certificates have all been
> revoked, but no incident report was ever filed.
> * CPS section 3.4 indicates that certificates may be suspended. This would
> violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
> not the current CPS for their existing root [5].
> * CPS section 4.9.1 does not appear to include all the revocation reasons
> required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
> but not the current CPS for their existing root [5].
>
> This begins the 3-week comment period for this request [6].
>
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
>
> - Wayne
>
> [1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
> [4]
>

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread mirro860923--- via dev-security-policy 
在 2019年1月15日星期二 UTC+8上午8:58:30，David E. Ross写道：
> On 1/14/2019 4:18 PM, Wayne Thayer wrote:
> > This request is for inclusion of the Government of Hong Kong, Hongkong
> > Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
> > following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306
> > 
> > * BR Self Assessment is here:
> > https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480
> > 
> > * Summary of Information Gathered and Verified:
> > https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396
> > 
> > * Root Certificate Download URL:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8980482
> > 
> > * CP/CPS:
> > CP: there is no CP
> > CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf
> > 
> > * This request is to include the root with the websites trust bit enabled
> > and EV treatment.
> > 
> > * EV Policy OID: 2.23.140.1.1
> > 
> > * Test Websites
> > https://valid-ev.ecert.gov.hk/
> > https://expired-ev.hongkongpost.gov.hk
> > https://revoked-ev.hongkongpost.gov.hk
> > 
> > * CRL URLs:
> > http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
> > http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl
> > 
> > * OCSP URL:
> > http://ocsp1.hongkongpost.gov.hk
> > 
> > * Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
> > according to the WebTrust for CA, BR, and EV audit criteria.
> > WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
> > BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
> > EV:
> > https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf
> > 
> > I’ve reviewed the CPS, BR Self Assessment, and related information for
> > inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
> > this bug and have the following comments:
> > 
> > ==Good==
> > This root is relatively new, has continuous BR audit coverage, and appears
> > to have only signed certificates for the required test websites.
> > 
> > ==Meh==
> > * The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
> > that EV certificates for the test sites were issued in May 2018, one can
> > argue that EVGL section 17.4 required a period-of-time audit to have been
> > completed in October rather than December as was the case. However, it has
> > been common for CAs to argue that certificates for test websites don’t
> > count and I have not yet published clear guidance on this issue.
> > * There is no document referenced as a CP. Hongkong Post says that the
> > document is a combined CP/CPS.
> > * In 2016, it was discovered that Hongkong Post was issuing SHA-1
> > certificates with non-random serial numbers that could be used for TLS in
> > Firefox [2] [3]. The problem was resolved by adding the problematic
> > intermediate certificate to OneCRL.
> > * The CPS permits external RAs, but according to Appendix E, there are none
> > at present. I would prefer that the CPS clearly state that domain
> > validation functions are never delegated.
> > * Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
> > the bug that differ from the published versions 2 and 3 in their
> > repository. The latest version “4” is marked as a “Pre-production CPS”.
> > They state that “…we cannot issue EV certificate to customers until
> > Mozilla, or at least some other root certificate programs, have granted EV
> > treatment to our root certificate. So, we do not yet publish the CPS in
> > order to avoid confusion to customers.”
> > 
> > ==Bad==
> > * Fairly recent misissuance under the currently included Hong Kong Post
> > Root CA 1: O and OU fields too long [4]. These certificates have all been
> > revoked, but no incident report was ever filed.
> > * CPS section 3.4 indicates that certificates may be suspended. This would
> > violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
> > not the current CPS for their existing root [5].
> > * CPS section 4.9.1 does not appear to include all the revocation reasons
> > required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
> > but not the current CPS for their existing root [5].
> > 
> > This begins the 3-week comment period for this request [6].
> > 
> > I will greatly appreciate your thoughtful and constructive feedback on the
> > acceptance of this root into the Mozilla CA program.
> > 
> > - Wayne
> > 
> > [1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
> > [2]
> > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
> > [4]
> > https://crt.sh/?caid=7319&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
> > [5] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en3.pdf
> > [6] https://wiki.mozilla.org/CA/Application_Process
> > 
> 
> I would think that lack of a CP alone would disqualify this root.

I think it is ok to combine C

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Wayne Thayer via dev-security-policy 
On Mon, Jan 14, 2019 at 5:58 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would think that lack of a CP alone would disqualify this root.
>
> Does it? I'm not saying that there is missing information, only that the
document is called a "CPS" rather than a "CP/CPS". Also, this concern
applies to the currently included root.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread David E. Ross via dev-security-policy 
On 1/14/2019 4:18 PM, Wayne Thayer wrote:
> This request is for inclusion of the Government of Hong Kong, Hongkong
> Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
> following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306
> 
> * BR Self Assessment is here:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480
> 
> * Summary of Information Gathered and Verified:
> https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8980482
> 
> * CP/CPS:
> CP: there is no CP
> CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf
> 
> * This request is to include the root with the websites trust bit enabled
> and EV treatment.
> 
> * EV Policy OID: 2.23.140.1.1
> 
> * Test Websites
> https://valid-ev.ecert.gov.hk/
> https://expired-ev.hongkongpost.gov.hk
> https://revoked-ev.hongkongpost.gov.hk
> 
> * CRL URLs:
> http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
> http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl
> 
> * OCSP URL:
> http://ocsp1.hongkongpost.gov.hk
> 
> * Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
> according to the WebTrust for CA, BR, and EV audit criteria.
> WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
> BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
> EV:
> https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf
> 
> I’ve reviewed the CPS, BR Self Assessment, and related information for
> inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
> this bug and have the following comments:
> 
> ==Good==
> This root is relatively new, has continuous BR audit coverage, and appears
> to have only signed certificates for the required test websites.
> 
> ==Meh==
> * The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
> that EV certificates for the test sites were issued in May 2018, one can
> argue that EVGL section 17.4 required a period-of-time audit to have been
> completed in October rather than December as was the case. However, it has
> been common for CAs to argue that certificates for test websites don’t
> count and I have not yet published clear guidance on this issue.
> * There is no document referenced as a CP. Hongkong Post says that the
> document is a combined CP/CPS.
> * In 2016, it was discovered that Hongkong Post was issuing SHA-1
> certificates with non-random serial numbers that could be used for TLS in
> Firefox [2] [3]. The problem was resolved by adding the problematic
> intermediate certificate to OneCRL.
> * The CPS permits external RAs, but according to Appendix E, there are none
> at present. I would prefer that the CPS clearly state that domain
> validation functions are never delegated.
> * Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
> the bug that differ from the published versions 2 and 3 in their
> repository. The latest version “4” is marked as a “Pre-production CPS”.
> They state that “…we cannot issue EV certificate to customers until
> Mozilla, or at least some other root certificate programs, have granted EV
> treatment to our root certificate. So, we do not yet publish the CPS in
> order to avoid confusion to customers.”
> 
> ==Bad==
> * Fairly recent misissuance under the currently included Hong Kong Post
> Root CA 1: O and OU fields too long [4]. These certificates have all been
> revoked, but no incident report was ever filed.
> * CPS section 3.4 indicates that certificates may be suspended. This would
> violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
> not the current CPS for their existing root [5].
> * CPS section 4.9.1 does not appear to include all the revocation reasons
> required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
> but not the current CPS for their existing root [5].
> 
> This begins the 3-week comment period for this request [6].
> 
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
> 
> - Wayne
> 
> [1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
> [2]
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
> [4]
> https://crt.sh/?caid=7319&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
> [5] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en3.pdf
> [6] https://wiki.mozilla.org/CA/Application_Process
> 

I would think that lack of a CP alone would disqualify this root.
Furthermore, the the "Meh" issues should be resolved before approval.

-- 
David E. Ross

Trump again proves he is a major source of fake news.  He wants
to cut off disaster funds to repair the damage caused by the
Woolsey Fire in southern California because he claims the state
fails

Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Wayne Thayer via dev-security-policy 
This request is for inclusion of the Government of Hong Kong, Hongkong
Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306

* BR Self Assessment is here:
https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480

* Summary of Information Gathered and Verified:
https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8980482

* CP/CPS:
CP: there is no CP
CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf

* This request is to include the root with the websites trust bit enabled
and EV treatment.

* EV Policy OID: 2.23.140.1.1

* Test Websites
https://valid-ev.ecert.gov.hk/
https://expired-ev.hongkongpost.gov.hk
https://revoked-ev.hongkongpost.gov.hk

* CRL URLs:
http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl

* OCSP URL:
http://ocsp1.hongkongpost.gov.hk

* Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
according to the WebTrust for CA, BR, and EV audit criteria.
WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
EV:
https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for
inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
this bug and have the following comments:

==Good==
This root is relatively new, has continuous BR audit coverage, and appears
to have only signed certificates for the required test websites.

==Meh==
* The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
that EV certificates for the test sites were issued in May 2018, one can
argue that EVGL section 17.4 required a period-of-time audit to have been
completed in October rather than December as was the case. However, it has
been common for CAs to argue that certificates for test websites don’t
count and I have not yet published clear guidance on this issue.
* There is no document referenced as a CP. Hongkong Post says that the
document is a combined CP/CPS.
* In 2016, it was discovered that Hongkong Post was issuing SHA-1
certificates with non-random serial numbers that could be used for TLS in
Firefox [2] [3]. The problem was resolved by adding the problematic
intermediate certificate to OneCRL.
* The CPS permits external RAs, but according to Appendix E, there are none
at present. I would prefer that the CPS clearly state that domain
validation functions are never delegated.
* Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
the bug that differ from the published versions 2 and 3 in their
repository. The latest version “4” is marked as a “Pre-production CPS”.
They state that “…we cannot issue EV certificate to customers until
Mozilla, or at least some other root certificate programs, have granted EV
treatment to our root certificate. So, we do not yet publish the CPS in
order to avoid confusion to customers.”

==Bad==
* Fairly recent misissuance under the currently included Hong Kong Post
Root CA 1: O and OU fields too long [4]. These certificates have all been
revoked, but no incident report was ever filed.
* CPS section 3.4 indicates that certificates may be suspended. This would
violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
not the current CPS for their existing root [5].
* CPS section 4.9.1 does not appear to include all the revocation reasons
required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
but not the current CPS for their existing root [5].

This begins the 3-week comment period for this request [6].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

- Wayne

[1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
[2]
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
[4]
https://crt.sh/?caid=7319&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[5] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en3.pdf
[6] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: usareally.com and OFAC lists

2019-01-14 Thread Wayne Thayer via dev-security-policy 
On Fri, Jan 11, 2019 at 11:51 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A few of us have been discussing the usareally.com "issue" recently.  In
> case you didn't know, the US Treasure put out a notice that US companies
> must not do business with USA Really:
>
> https://home.treasury.gov/news/press-releases/sm577
>
>
>
> Let's Encrypt mapped that release to certificates they had issued to the
> domain and revoked them:
>
>
> https://www.mcclatchydc.com/news/policy/technology/cyber-security/article223
> 832790.html
> 
>
>
>
> They came to the GlobalSign Russia organization then to WoTrus:
>
> https://crt.sh/?q=usareally.com
>
> US CAs should take notice and put the proper controls in place.
>
> Am I wrong to expect US CAs to be monitoring OFAC sanctions lists?
Otherwise they would risk violating the typical "comply with applicable
law" stipulation in section 9 of their CPS'.

>
>
> This site never appeared on Google Safe Browsing as it's not a malware "bad
> site", and it's safe to visit.  You can even issue them a certificate or do
> business with them if you're not a US company.  It's likely that there are
> governmental notices like this in other regions which would be useful to
> share and factor into the CA's High Risk checks.
>
>
>
> Does this group have any recommendations for how/where such "claims" or
> announcements could be posted? Is the this list off-limits for such
> communication?
>
> Unless/until someone responds with specific objections, feel free to use
this list to share that type of information.

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

Re: Do we need multiple name constraints on one certificate chain?

2019-01-14 Thread Wayne Thayer via dev-security-policy 
On Mon, Jan 14, 2019 at 9:57 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via
> dev-security-policy  wrote:
>
> > Hi
> >
> > I have question for following case of certificate chain.
> > (root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
> > In addition, "1st intermediate cert" is for technically constrained with
> > name constraints (including server-auth EKU).
> >
> > I believe we Must put EKU (server-auth) for "2nd intermediate cert".
> > (regarding Mozilla root store policy 5.3)
> > However, Does "2nd intermediate cert" need name constraints?
> > # For our understanding, name constraints on 2nd intermediate is not
> > necessary, but do not sure about that.
> >
>
> Thanks for raising this question! I defer to Wayne to provide the
> authoritative answer, but I believe your reading is mostly correct.
>
>  This is an interesting question.

Under Section 5.3 of the Mozilla Policy, intermediate certificates created
> after 2019-01-01 MUST contain an EKU according to those policies.
> Under Section 5.3.1 of the Mozilla Policy, in order to be considered
> technically constrained, then it MUST contain nameConstraints in line with
> Section 7.1.5 of the BRs.
>
> This means that (2nd intermediate cert), according to policy, MUST contain
> both an EKU and nameConstraints.
>
> If the purpose of the technical constraints are to comply with section
5.3.1 so that (2nd intermediate) does not need to be disclosed or audited,
then I agree with Ryan. Mozilla policy for intermediate certificates
applies to "All certificates that are capable of being used to issue new
certificates".


> This is done for policy reasons, not strictly technical reasons. That is,
> RFC 5280 ensures that constraints flow down, such that if you had a chain
> (root cert)--(1st intermediate)--(2nd intermediate)--(EE)
> and 1st intermediate was nameConstrained, then those constraints would also
> apply to 2nd intermediate and EE.
>
> So (2nd intermediate) could contain no name constraints and be publicly
disclosed and audited to comply with Mozilla policy. The result would still
be that end-entity certificates signed by (2nd intermediate) are
technically name constrained due to (1st intermediate), correct?

Another valid scenario is:
* (1st intermediate) not name constrained, is disclosed and audited
* (2nd intermediate) name constrained, not disclosed or audited
* (root cert)--(1st intermediate)--(2nd intermediate)--(EE)

However, it also means that if a chain existed
> (root cert)--(another intermediate)--(2nd intermediate)--(EE)
>
> and "another intermediate" was NOT nameConstrained, then (2nd intermediate)
> would also not be constrained.
>
> Thus, the policy requirement - of expressing those constraints in (2nd
> intermediate) - helps ensures that the intermediate will be constrained
> regardless of it building the chain from (1st intermediate) or (another
> intermediate). Mozilla Policy also requires disclosure of (another
> intermediate), but as the recent discussion reflected, that's not
> technically enforced yet. One can imagine that if there was technical
> enforcement - of all intermediates being disclosed and not trusted unless
> they were - then the policy requirement might be changed to align with the
> technical requirement. However, this is only possible when it can be
> guaranteed that an unconstrained "another intermediate" doesn't exist, and
> absent that technical guarantee, expressing all of the constraints
> (duplicating them) in "2nd intermediate" offers a more robust guarantee.
>
> Perhaps the way to think about this is that each intermediate must
independently (regardless of other certificates in the chain) comply with
Mozilla policy section 5.3. Having name constraints in (1st intermediate)
does not exempt (2nd intermediate) from complying with the policy. That is
literally what our policy says today, but it also wouldn't hurt to clarify
for the case that Tadahiko described.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Do we need multiple name constraints on one certificate chain?

2019-01-14 Thread Ryan Sleevi via dev-security-policy 
On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via
dev-security-policy  wrote:

> Hi
>
> I have question for following case of certificate chain.
> (root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
> In addition, "1st intermediate cert" is for technically constrained with
> name constraints (including server-auth EKU).
>
> I believe we Must put EKU (server-auth) for "2nd intermediate cert".
> (regarding Mozilla root store policy 5.3)
> However, Does "2nd intermediate cert" need name constraints?
> # For our understanding, name constraints on 2nd intermediate is not
> necessary, but do not sure about that.
>

Thanks for raising this question! I defer to Wayne to provide the
authoritative answer, but I believe your reading is mostly correct.

Under Section 5.3 of the Mozilla Policy, intermediate certificates created
after 2019-01-01 MUST contain an EKU according to those policies.
Under Section 5.3.1 of the Mozilla Policy, in order to be considered
technically constrained, then it MUST contain nameConstraints in line with
Section 7.1.5 of the BRs.

This means that (2nd intermediate cert), according to policy, MUST contain
both an EKU and nameConstraints.

This is done for policy reasons, not strictly technical reasons. That is,
RFC 5280 ensures that constraints flow down, such that if you had a chain
(root cert)--(1st intermediate)--(2nd intermediate)--(EE)
and 1st intermediate was nameConstrained, then those constraints would also
apply to 2nd intermediate and EE.

However, it also means that if a chain existed
(root cert)--(another intermediate)--(2nd intermediate)--(EE)

and "another intermediate" was NOT nameConstrained, then (2nd intermediate)
would also not be constrained.

Thus, the policy requirement - of expressing those constraints in (2nd
intermediate) - helps ensures that the intermediate will be constrained
regardless of it building the chain from (1st intermediate) or (another
intermediate). Mozilla Policy also requires disclosure of (another
intermediate), but as the recent discussion reflected, that's not
technically enforced yet. One can imagine that if there was technical
enforcement - of all intermediates being disclosed and not trusted unless
they were - then the policy requirement might be changed to align with the
technical requirement. However, this is only possible when it can be
guaranteed that an unconstrained "another intermediate" doesn't exist, and
absent that technical guarantee, expressing all of the constraints
(duplicating them) in "2nd intermediate" offers a more robust guarantee.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Do we need multiple name constraints on one certificate chain?

2019-01-14 Thread tadahiko.ito.public--- via dev-security-policy 
Hi

I have question for following case of certificate chain.
(root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
In addition, "1st intermediate cert" is for technically constrained with name 
constraints (including server-auth EKU).
    
I believe we Must put EKU (server-auth) for "2nd intermediate cert". (regarding 
Mozilla root store policy 5.3)
However, Does "2nd intermediate cert" need name constraints? 
# For our understanding, name constraints on 2nd intermediate is not necessary, 
but do not sure about that.

Furthermore, if I should concern something, I am more than happy to hear 
advices.
# i.e, in case of cross cert, or some verification environment which require 
name-constraints with server-auth (if exists).

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

Re: Test website monitor

2019-01-14 Thread Rob Stradling via dev-security-policy 
On 14/01/2019 08:09, westmail24--- via dev-security-policy wrote:
> This URL ( https://crt.sh/test-websites ) does not work (~5 days)

Fixed.  Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Test website monitor

2019-01-14 Thread westmail24--- via dev-security-policy 
This URL ( https://crt.sh/test-websites ) does not work (~5 days)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy