RE: CAs not compliant with CAA CP/CPS requirement

[Ryan Hurst via dev-security-policy]

Responding from my personal account but I can confirm that Google Trust 
Services does check CAA and our policy was updated earlier today to reflect 
that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Violations of Baseline Requirements 4.9.10

[Ben Wilson via dev-security-policy]

Hi Paul,

In case you're not on the distribution for the DigiCert bug for this, here is 
my recent post.

https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c2 

Cheers,

Ben


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Paul Kehrer via dev-security-policy
Sent: Friday, September 8, 2017 6:19 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Violations of Baseline Requirements 4.9.10

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy
(dev-security-policy@lists.mozilla.org) wrote:

Bugs filed…



~

Thanks,
Kathleen


Thank you very much Kathleen! If I receive additional responses I will update 
the bugs directly.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAs not compliant with CAA CP/CPS requirement

[Ben Wilson via dev-security-policy]

Those are typos.  See section 4.2.1 of our CPS posted here:
https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Samuel Pinder via dev-security-policy
Sent: Friday, September 8, 2017 4:08 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Andrew Ayer

Subject: CAs not compliant with CAA CP/CPS requirement

Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not resolve,
Japan tends to use the .NE.jp suffix, not .net.jp . Therefore shouldn't
these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do indeed resolve.
On this subject, I am curious as to why it appears a lot of CA's do not tend
to be publicizing information about CAA nor the issuer domains that can be
used. There does appear to be a last-minute rush for compliance with CAA
validation requirements, as well as confusion on how to interpret the
regulations, but that's just my opinion. I very much support the idea in
principle but adoption is probably being hampered by the lack of information
on correct issuer domains.
Sam


On Fri, Sep 8, 2017 at 10:57 PM, Jeremy Rowley via dev-security-policy
 wrote:
> Hi Andrew,
>
> I'm not certain how to update the previous Mozilla response with 
> respect to CAA, but we added the following as authorized CAA records:
> Digicert.com
> *.digicert
> Digicert.net.jp
> Cybertrust.net.jp
>
> I wasn't sure if adding a wildcard to the CAA record is kosher, but I 
> didn't seem anything prohibiting use of wildcard characters in CAA 
> records.  We saw quite a few records similar to CAA.digiert.com during 
> the testing and added this to the list.
>
> Jeremy
>
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla .org] On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Friday, September 8, 2017 1:25 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: CAs not compliant with CAA CP/CPS requirement
>
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate 
> Policy and/or Certification Practice Statement (section 4.1 for CAs 
> still conforming to RFC 2527) SHALL state the CA's policy or practice 
> on processing CAA Records for Fully Qualified Domain Names; that 
> policy shall be consistent with these Requirements. It shall clearly 
> specify the set of Issuer Domain Names that the CA recognises in CAA
'issue' or 'issuewild'
> records as permitting it to issue. The CA SHALL log all actions taken, 
> if any, consistent with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes 
> of some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs 
> are not compliant with the above provision of the BRs:
>
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
>
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not 
> specify issuer domain names
>
> DigiCert (https://www.digicert.com/legal-repository/) - Does not 
> specify issuer domain names, and processing is not compliant with BRs 
> ("If a CAA record exists that does not list DigiCert as an authorized 
> CA, DigiCert verifies that the applicant has authorized issuance, 
> despite the CAA
> record.")
>
> Google Trust Services (https://pki.goog/) - Does not check CAA
>
> Identrust (https://secure.identrust.com/certificates/policy/ts/) - 
> Does not check CAA
>
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_
> certif
> icados/es_url/index.shtml)
> - Does not specify issuer domain names
>
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
>
> Symantec / GeoTrust 
> (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
>
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - 
> No mention of CAA
>
> Visa (http://www.visa.com/pki/) - Does not check CAA
>
>
> These CAs have compliant CP/CPSes:
>
> Entrust
>
> GlobalSign
>
> GoDaddy
>
> Let's Encrypt
>
> QuoVadis
>
> Trustwave
>
>
> It would be nice to hear confirmation from the non-compliant CAs that 
> they really are checking CAA as required, and if so, why they 
> overlooked the requirement to update their CP/CPS.
>
> Regards,
> Andrew
> ___
> 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
>
___
dev-security-policy mailing list

Re: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy
(dev-security-policy@lists.mozilla.org) wrote:

Bugs filed…



~

Thanks,
Kathleen


Thank you very much Kathleen! If I receive additional responses I will
update the bugs directly.

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

CAs not compliant with CAA CP/CPS requirement

[Samuel Pinder via dev-security-policy]

Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not
resolve, Japan tends to use the .NE.jp suffix, not .net.jp . Therefore
shouldn't these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do
indeed resolve. On this subject, I am curious as to why it appears a
lot of CA's do not tend to be publicizing information about CAA nor
the issuer domains that can be used. There does appear to be a
last-minute rush for compliance with CAA validation requirements, as
well as confusion on how to interpret the regulations, but that's just
my opinion. I very much support the idea in principle but adoption is
probably being hampered by the lack of information on correct issuer
domains.
Sam


On Fri, Sep 8, 2017 at 10:57 PM, Jeremy Rowley via dev-security-policy
 wrote:
> Hi Andrew,
>
> I'm not certain how to update the previous Mozilla response with respect to
> CAA, but we added the following as authorized CAA records:
> Digicert.com
> *.digicert
> Digicert.net.jp
> Cybertrust.net.jp
>
> I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't
> seem anything prohibiting use of wildcard characters in CAA records.  We saw
> quite a few records similar to CAA.digiert.com during the testing and added
> this to the list.
>
> Jeremy
>
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Friday, September 8, 2017 1:25 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: CAs not compliant with CAA CP/CPS requirement
>
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy
> and/or Certification Practice Statement (section 4.1 for CAs still
> conforming to RFC 2527) SHALL state the CA's policy or practice on
> processing CAA Records for Fully Qualified Domain Names; that policy shall
> be consistent with these Requirements. It shall clearly specify the set of
> Issuer Domain Names that the CA recognises in CAA 'issue' or 'issuewild'
> records as permitting it to issue. The CA SHALL log all actions taken, if
> any, consistent with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes of
> some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs are
> not compliant with the above provision of the BRs:
>
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
>
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
>
> DigiCert (https://www.digicert.com/legal-repository/) - Does not specify
> issuer domain names, and processing is not compliant with BRs ("If a CAA
> record exists that does not list DigiCert as an authorized CA, DigiCert
> verifies that the applicant has authorized issuance, despite the CAA
> record.")
>
> Google Trust Services (https://pki.goog/) - Does not check CAA
>
> Identrust (https://secure.identrust.com/certificates/policy/ts/) - Does not
> check CAA
>
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certif
> icados/es_url/index.shtml)
> - Does not specify issuer domain names
>
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
>
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
>
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - No
> mention of CAA
>
> Visa (http://www.visa.com/pki/) - Does not check CAA
>
>
> These CAs have compliant CP/CPSes:
>
> Entrust
>
> GlobalSign
>
> GoDaddy
>
> Let's Encrypt
>
> QuoVadis
>
> Trustwave
>
>
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
>
> Regards,
> Andrew
> ___
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

Hi Andrew, 

I'm not certain how to update the previous Mozilla response with respect to
CAA, but we added the following as authorized CAA records:
Digicert.com
*.digicert
Digicert.net.jp
Cybertrust.net.jp

I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't
seem anything prohibiting use of wildcard characters in CAA records.  We saw
quite a few records similar to CAA.digiert.com during the testing and added
this to the list.

Jeremy


Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Andrew Ayer via dev-security-policy
Sent: Friday, September 8, 2017 1:25 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CAs not compliant with CAA CP/CPS requirement

The BRs state:

"Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy
and/or Certification Practice Statement (section 4.1 for CAs still
conforming to RFC 2527) SHALL state the CA's policy or practice on
processing CAA Records for Fully Qualified Domain Names; that policy shall
be consistent with these Requirements. It shall clearly specify the set of
Issuer Domain Names that the CA recognises in CAA 'issue' or 'issuewild'
records as permitting it to issue. The CA SHALL log all actions taken, if
any, consistent with its processing practice."

Since it is now 8 September 2017, I decided to spot check the CP/CPSes of
some CAs.

At time of writing, the latest published CP/CPSes of the following CAs are
not compliant with the above provision of the BRs:

Amazon (https://www.amazontrust.com/repository/) - Does not check CAA

Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
specify issuer domain names

DigiCert (https://www.digicert.com/legal-repository/) - Does not specify
issuer domain names, and processing is not compliant with BRs ("If a CAA
record exists that does not list DigiCert as an authorized CA, DigiCert
verifies that the applicant has authorized issuance, despite the CAA
record.")

Google Trust Services (https://pki.goog/) - Does not check CAA

Identrust (https://secure.identrust.com/certificates/policy/ts/) - Does not
check CAA

Izenpe
(http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certif
icados/es_url/index.shtml)
- Does not specify issuer domain names

PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA

Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
- Does not specify issuer domain names

Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - No
mention of CAA

Visa (http://www.visa.com/pki/) - Does not check CAA


These CAs have compliant CP/CPSes:

Entrust

GlobalSign

GoDaddy

Let's Encrypt

QuoVadis

Trustwave


It would be nice to hear confirmation from the non-compliant CAs that they
really are checking CAA as required, and if so, why they overlooked the
requirement to update their CP/CPS.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

[Nick Lamb via dev-security-policy]

Thanks Kathleen,

I have briefly inspected this BR Self Assessment document. Nothing terrifying 
leaped out at me that would lead me to ask that Mozilla deny the renewal, 
however I did find things worth mentioning here.

The only listed 3.2.2.4 method is 3.2.2.4.5, Domain Authorization Document. 
This explains why Certigna has chosen to outsource the validation to an RA, the 
documents for 3.2.2.4.5 might require local expertise to obtain and interpret, 
as distinct from technical and automatable methods like 3.2.2.4.10. 
Nevertheless, involvement of human agents is always a weak point in security 
systems, we saw with Symantec that problems can arise if the CA outsources this 
work but doesn't make the effort to inspect what is being done on their behalf. 
So we need to keep a particular eye on the results.

AFNIC is mentioned by name. I understand that Certigna specialises in 
particular in French-speaking locales (maybe mostly ex-French colonies?) but 
it's not obvious to me in these documents whether Certigna by policy doesn't 
issue certificates for names that aren't under AFNIC's control. If not, why 
call them out particularly?


For 3.2.2.6 Wildcard Domain Validation the submission responds with a lot of 
content about validation of identities. Section 3.2.2.6 actually concerns 
special considerations for the dnsName wildcard, such as verifying whether the 
requested wildcard is for a Public Suffix or Registry-controlled Label. It is 
important that the CA has some procedure to avoid issuing, for example, *.co.uk 
or other wildcards that must not exist and this procedure should be in their 
policy documents AND the relevant sections highlighted in the assessment. Is 
this an error by Certigna? Or do I misunderstand the requirement here?

For 4.2.1 Mozilla's document specifically requests information about the CA's 
policy for High Risk Certificate Requests. Nothing is indicated about this. [ 
Kathleen: Consider *bolding* the relevant text for emphasis so that it stands 
out from cells which are just repeating the relevant RFC section header name? ]

For 4.9.{2,3} We need clarity on how Relying Parties, including but not limited 
to people who read m.d.s.policy can report a problem with a certificate despite 
not being the subscriber or a representative of the subscriber. This isn't 
listed - but maybe it is actually documented somewhere? I think previous 
m.d.s.policy discussions found that the most appropriate thing is to supply an 
email address to which such problems can be reported.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Peter Bowen via dev-security-policy]

On Fri, Sep 8, 2017 at 12:24 PM, Andrew Ayer via dev-security-policy
 wrote:
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
>
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
>
>
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.

Amazon Trust Services is checking CAA prior to issuance of
certificates.  We provided the domain list in our responses to the
last Mozilla communication and will be updating our externally
published policy and practice documentation to match shortly.

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

Re: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

Hey Andrew, we are checking CAA records at time of issuance. The CPS update 
should publish today.

> On Sep 8, 2017, at 1:25 PM, Andrew Ayer via dev-security-policy 
>  wrote:
> 
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issues

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/09/2017 17:17, Gervase Markham wrote:
>
>> Mozilla has decided that there is sufficient concern about the
>> activities and operations of the CA "PROCERT" to collect together our
>> list of current concerns. That list can be found here:
>> https://wiki.mozilla.org/CA:PROCERT_Issues
>>
>> Note that this list may expand or reduce over time as issues are
>> investigated further, with information either from our or our
>> community's investigations or from PROCERT.
>>
>> We expect PROCERT to engage in a public discussion of these issues and
>> give their comments and viewpoint. We also hope that our community will
>> make comments, and perhaps provide additional information based on their
>> own investigations.
>>
>> When commenting on these issues, please clearly state which issue you
>> are addressing on each occasion. The issues have been given identifying
>> letters to help with this.
>>
>> At the end of a public discussion period between Mozilla, our community
>> and PROCERT, which we hope will be no longer than a couple of weeks,
>> Mozilla will move to make a decision about the continued trust of
>> PROCERT, based on the picture which has then emerged.
>>
>> Gerv
>>
>>
> Although violating the same rules, and involving the same certificates;
> for purposes of risk assessment I think issue K should be divided into
> two issues:
>

Note, I was explicitly suggesting we not do this, because this introduces a
greater level of subjectivity of assessment, and based on incomplete or
unknowable information. For this reason, ensuring a consistent application
of risk (e.g. the factors that allowed this to happen are the same) is far
more beneficial for the community and for consistency in application of
policy.

So I do not believe we should split these issues up, and do not think it
would help the discussions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issues

[Jakob Bohm via dev-security-policy]

On 07/09/2017 17:17, Gervase Markham wrote:

Mozilla has decided that there is sufficient concern about the
activities and operations of the CA "PROCERT" to collect together our
list of current concerns. That list can be found here:
https://wiki.mozilla.org/CA:PROCERT_Issues

Note that this list may expand or reduce over time as issues are
investigated further, with information either from our or our
community's investigations or from PROCERT.

We expect PROCERT to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you
are addressing on each occasion. The issues have been given identifying
letters to help with this.

At the end of a public discussion period between Mozilla, our community
and PROCERT, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about the continued trust of
PROCERT, based on the picture which has then emerged.

Gerv



Although violating the same rules, and involving the same certificates;
for purposes of risk assessment I think issue K should be divided into
two issues:

K1 (most serious): Multiple certificates issued for the bare hostname
  OWASERVER (uppercase, no qualifying domain).  As pointed out by Ryan
  Sleevi, many e-mail clients (including mobile clients) may look for
  this name on their local DNS search list and may or may not (depending
  on client implementation) accept any of these bare certificates as
  proving they are talking to their "home" mail server.  So far none of
  the other MS mail server magic/default names have been found as bare
  name SANs.

K2 (very serious): Multiple certificates issued to potentially
  non-unique subdomains of the local. TLD previously common for LAN DNS,
  but now mostly reserved for multicast DNS.  These violations should
  only pose a risk to clients who have somehow chosen the same arbitrary
  2. level domain under local. as the certificate holder(s).  The main
  issue here is that since the local. TLD doesn't have an official
  registry, there is no way that the CA could have properly validated
  that *any* applicant was the proper owner of such a 2nd level domain,
  because noone is.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[Kathleen Wilson via dev-security-policy]

Bugs filed…


>
> AS Sertifitseerimiskeskuse (SK)
>

Bug #1398233

> 
> Autoridad de Certificacion Firmaprofesional
> 

Bug #1398240

> 
> CA Disig a.s. (Fixed as of 2017-08-31)
> 

Bug #1398242

> 
> certSIGN (partially resolved)
> 

Bug #1398243

> 
> Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
> 

Bug #1398246

> 
> DigiCert:
> 


Bug #1398269


> 
> DocuSign (OpenTrust/Keynectis)
> 

Bug #1398247


> 
> Government of The Netherlands, PKIoverheid (Logius) (Fixed as of 2017-08-31)
> 

Bug #1398251

> 
> IdenTrust (fixed as of 2017-08-31)
> 

Bug #1398255

> 
> Izenpe S.A. (fixed as of 2017-09-05)
> 

Bug #1398258


> 
> PROCERT
> 

Existing Bug: 1391058

> 
> SECOM Trust Systems Co. Ltd.
> 

Bug #1398259

> 
> Visa
> 

Bug #1398261

~

Thanks,
Kathleen



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

Re: TunRootCA2 root inclusion request

[Fotis Loukos via dev-security-policy]

Hello,
I started reading your CP/CPS and I noticed that you do not use the
standard CA/B Forum terminology. Is this on purpose? Is it just a
translation issue?

Furthermore, I believe that the English Root CA CP/CPS should be added
to the bug, I can only find the translation of the SSL SubCA CP/CPS.

And just a final note, I can't seem to be able to access the mail sent
by Gerv the 15th of August (the one I'm replying to) at the google
groups thread
(https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wCZsVq7AtUY).
Maybe it got lost somehow and the CA contacts are using google groups to
get an update on their discussion.

Regards,
Fotis

On 15/08/2017 03:41 μμ, Gervase Markham via dev-security-policy wrote:
> On 03/08/17 08:01, Olfa Kaddachi wrote:
>> ==> Some of these controls are already in place (such as the field CN and 
>> Subject Alternative Name that does not contain a private IP address). 
> 
> That doesn't quite answer my question.
> 
> Let me ask another way: for how long has the Government of Tunisia CA
> been aware of the Baseline Requirements? From what date do you assert
> that you have been compliant with these requirements?
> 
>> 4-   Validation of the technical data included in the CSR: The RA operator 
>> checks :
>>
>> Digital Signature Algorithm: SHA256
>> Key Algorithm: RSA
>> Key Size: 2048
> 
> Why can such things not be checked programmatically? It seems you are
> opening yourselves up to the possibility of human error.
> 
>> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
>> be in production by the end of September 2017.  For the moment, the only 
>> improvement done, is the printing of all the subject alternative names in 
>> the certificate for the RA operators, in addition to the other fields (CN, 
>> O, OU, mail) in such a way that they can visually check all the fields 
>> before the delivery of the certificate.
> 
> A visual check may not catch every problem. For example, would it catch
> a trailing space?
> 
>> >From what date would you say that your CA has been compliant with the CAB 
>> >Forum Baseline Requirements? 
>> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
>> performed by LSTI. The last audit took place from 27th to 30th September 
>> 2016 in applying the relevant ETSI Technical Specifications ETSI TS 
>> 102042v2.4.1. 
> 
> And that audit includes a BR audit?
> 
> Did the audit report have any qualifications?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 OCSP responder certificates

[Gervase Markham via dev-security-policy]

On 07/09/17 00:41, Ben Wilson wrote:
> We immediately contacted the operators of the issuing CAs and
> requested that they replace their OCSP responder certificates with
> ones signed with SHA2, and most have done so.  However, in drafting
> this post I reviewed the Baseline Requirements, section 7.1.3, which
> I think is ambiguous and allows SHA1 OCSP Responder Certificates in
> some situations.  It says, “Effective 1 January 2016, CAs MUST NOT
> issue any new Subscriber certificates or Subordinate CA certificates
> using the SHA-1 hash algorithm. CAs MAY continue to sign certificates
> to verify OCSP responses using SHA1 until 1 January 2017.

I interpret that as saying that if your OCSP responder's signing
certificate was created before 1 January 2017, and was signed using
SHA-1, you can keep using it until it expires.

However, note that Mozilla policy has some additional requirements in
this area, notably that SHA-1 certs used to sign OCSP responses must be
technically constrained to be only used for OCSP signing.

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

Re: Violations of Baseline Requirements 4.9.10

[Jonathan Rudenberg via dev-security-policy]

> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
>> I have updated the list again to note the additional responders fixed (in
>> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly
>> less enormous I've also started removing everything but the CA's name when
>> I have confirmed that all the reported responders are now properly
>> responding to my queries.
> 
> Should I still file a bug for those, so that the incident report is recorded 
> in Bugzilla?

Yes, it will be much easier to track there instead of being buried in this 
thread.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

[Kathleen Wilson via dev-security-policy]

> This request from the Dhimyotis/Certigna is to include the 
> SHA-256 ‘Certigna Root CA’ certificate and turn on the 
> Websites and Email trust bits. This root certificate will 
> eventually replace the SHA-1 ‘Certigna’ root certificate 
> that was included via Bugzilla #393166. 
> ...
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1265683

This CA has provided an updated BR Self Assessment:
https://bugzilla.mozilla.org/show_bug.cgi?id=1265683#c25

I will greatly appreciate constructive feedback on this CA's root renewal 
request.

Thanks,
Kathleen

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

Re: Violations of Baseline Requirements 4.9.10

[Kathleen Wilson via dev-security-policy]

I'm going to file the Bugzilla Bugs for each of these CAs, as follows.

==
Bug Summary: : Non-BR-Compliant OCSP Responders

Bug Description:
Problems have been found with OCSP responders for this CA, and reported in the 
mozilla.dev.security.policy forum here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ

As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a 
“good” status for unissued certificates. The effective date for this 
requirement was 2013-08-01.

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
==


> I have updated the list again to note the additional responders fixed (in
> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly
> less enormous I've also started removing everything but the CA's name when
> I have confirmed that all the reported responders are now properly
> responding to my queries.

Should I still file a bug for those, so that the incident report is recorded in 
Bugzilla?

Thanks,
Kathleen

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

On 07/09/17 22:27, Ryan Sleevi wrote:
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?

I don't want to place a hard limit on it because often finding the truth
requires several rounds of interaction. But, as noted in the original
post, I would expect to be moving towards a determination of a response
in a matter of weeks (rather than months).

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

RE: StartCom communication

[Inigo Barreira via dev-security-policy]

Andrew et al,

Just to inform that we have upgraded the EJBCA release to 6.9.0 in
production this early morning and the CAA checking is working fine, as
showed in the EJBCA´s logs. 

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Inigo Barreira via dev-security-policy
Sent: lunes, 4 de septiembre de 2017 18:40
To: Andrew Ayer 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: StartCom communication

Hi Andrew,

Thank you for your questions/suggestions. Let me answer

1.- We removed the ability to the CA administrator as a role to issue
certificates, independently who´s assigned to that role. In the explanation
I tried to detail exactly what happened and who did it (not to blame on
them) and those two were asigned as CA administrators. So now, none can
issue certificates directly from the EJBCA.

2.- This error happened when testing the CT behaviour and since then,
nothing happened. Those were tests. The EJBCA system controls this and all
the pre-certs generated mean the issuance of those certs. 

3.- Hopefully yes. This is our intention. Primekey was delayed a little bit
and we´re somehow in a rush for making the upgrade but we want to meet that
deadline. Just in case, Primekey provided a manual checking of the CAA but
our aim is to upgrade to the new version and use it. I´m afraid all EJBCA
customers are in the same situation.
Regarding the CAA test suite, we haven´t had time to test it but we´re going
to test it.

4.- Yes, the use of those tools are performed after the issuance and the
goal is that if this happen, a mis-issuance, be quick enough to react
promptly and if possible, even before the customer can retrieve the
certificate, revoke timely and start the investigation.
And yes, I´ve been reading the email from Rob and I think it´s a very good
idea. In fact, we´ve scheduled for next week if possible (after the upgrade
to EJBCA 6.9.0) or the following one depending on how the CAA works once put
in production. I´ll keep this list informed of the progress.
We asked Primekey to include this kind of tools or similar before or after
the issuance but there´s no such feature at the moment.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: Andrew Ayer [mailto:a...@andrewayer.name]
Sent: lunes, 4 de septiembre de 2017 18:06
To: Inigo Barreira 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 +
Inigo Barreira via dev-security-policy
 wrote:

> [...]
>
> a. Test certificates
> 
> It__s been detailed in bugzilla #1369359. There__s an attachment with 
> a detailed explanation what happened, when, who, what was done to 
> remediate and to avoid it happening in the future. Those certs were 
> all the time under our control and lived for some minutes while 
> testing the CT behaviour.
> 
> Actions: removed issuance rights for the CA administrator

Could you clarify whether you removed the issuance rights of the particular
administrator who issued the test certificates, or if you removed the
ability for administrators in general to issue certificates bypassing
technical controls?

Considering that your incident report names the CA administrator and
internal checker 10 times each, and states the reason for the incident as
"Operators of EJBCA server didn't follow the operating protocol of
StartCom", one could conclude that StartCom sees its failures as a problem
with individual people, rather than a systemic problem of insufficient
technical controls.  What has StartCom done to correct this?


> b. Pre-certificates
> 
> It__s explained in bugzilla #1386894. Perhaps I was wrong with the 
> word __intent__ and then no need to revoke as they were not real 
> certificates, but once we had to do it, had to work with Primekey to 
> revoke those certs, because they didn__t exist for the EJBCA system as 
> they only have certificates, not pre-certificates.

What has been done to fix the underlying issue so that in the future you
won't create a pre-certificate unless you really intend to issue the final
certificate?

> [...]
> 
> a. apply newest version of EJBCA v6.9.0
> 
> Primekey has just released the new version of EJBCA, v6.9.0 (end of 
> august).
> 
> This new version comes with some important improvements, such as:
> 
> -  CAA automatic checking
> 
> -  Perform public key validation (RSA and ECC) 
> 

Will EJBCA 6.9.0 be deployed by September 8, when CAA checking becomes
mandatory? If not, how will you be checking CAA on September 8?

Does your/EJBCA's implementation of CAA pass the test suite I recently
posted to the CABF list? https://caatestsuite.com/

> b. integrate cablint/x509lint in CAProxy
> 
> These tools have been integrated at the issuance 

Re: PROCERT issues

[Alex Gaynor via dev-security-policy]

I believe it's important to consider more than just the issues themselves,
and to look at a CA's response to the issues. In the past weeks, we've done
a lot of really fantastic work to push CAs on publishing more comprehensive
post-mortems, and several CAs have distinguished themselves with timely
responses and solid analysis of the underlying causes of failures.

In that frame, I want to highlight a few issues that raise serious concerns
to me:

* In responding to issue D, PROCERT displayed a failure to analyze and
understand the issues.
* In responding to issue O, PROCERT once again claimed there wasn't a
problem after evidence has already been provided of the issue. Further,
they appear to have significant challenges maintaining and updating their
PKI software.
* In responding to issue E, PROCERT made several rounds of incorrect
statements about their certificate issuance; they have not substantively
responded to the issue.

I believe that PROCERT's inability to respond to problem reports in a
timely and correct fashion, even more so than the certificate issuance
itself, represents an ongoing practice practice which is not in keeping
with the goals of the Mozilla Root Program.

Alex

On Thu, Sep 7, 2017 at 5:27 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Mozilla has decided that there is sufficient concern about the
> > activities and operations of the CA "PROCERT" to collect together our
> > list of current concerns. That list can be found here:
> > https://wiki.mozilla.org/CA:PROCERT_Issues
> >
> > Note that this list may expand or reduce over time as issues are
> > investigated further, with information either from our or our
> > community's investigations or from PROCERT.
> >
> > We expect PROCERT to engage in a public discussion of these issues and
> > give their comments and viewpoint. We also hope that our community will
> > make comments, and perhaps provide additional information based on their
> > own investigations.
> >
> > When commenting on these issues, please clearly state which issue you
> > are addressing on each occasion. The issues have been given identifying
> > letters to help with this.
> >
> > At the end of a public discussion period between Mozilla, our community
> > and PROCERT, which we hope will be no longer than a couple of weeks,
> > Mozilla will move to make a decision about the continued trust of
> > PROCERT, based on the picture which has then emerged.
> >
>
> (Unless stated, wearing a personal hat)
>
> Hi Gerv,
>
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?
>
> Based on the information provided, Issue K represents an unconditional
> security issue, in as much as names such as "autodiscover" and "owaserver"
> are widely-used domains for Outlook Web Access. Many clients attempt to
> access resources at this (unqualified) domain, relying on the combination
> of DNS suffix search and locally-trusted certificates to ensure proper
> resolution. By issuing a publicly trusted certificate for this name - and
> then failing to revoke it - represents a critical security risk and
> arguably a dereliction of responsibility.
>
> Combined with Issue D and Issue G, it is questionable as to how it was ever
> validated, and suggest serious failings over the most critical security
> control of a CA - which is validation of a domain.
>
> Combined with Issue L, Issue Q, Issue R, Issue X, and Issue W, serious
> questions are raised about the oversight and technical ability of the
> staff, as these are indicative of serious control failures.
>
> Outside of Issue K, I would suggest that Issue O and Issue S show a lack of
> awareness of developments in the CA ecosystem, as both of these controls
> were direct responses to widely reported CA security issues. The failure to
> take appropriate steps - or to appreciate the reasons behind such steps -
> are indicative of a systematic misunderstanding of the security function of
> a CA.
>
> On the basis of the sum of these issues, it would seem that the criteria in
> Section 7.3 of Mozilla policy -
> https://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/policy/
> - is met: "Mozilla will disable or remove a certificate if the CA
> demonstrates ongoing or egregious practices that do not maintain the
> expected level of service or that do not comply with the requirements of
> this policy."
> ___
> 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

Re: dNSName containing '/' / low serial number entropy

[Kim Nguyen via dev-security-policy]

Am Mittwoch, 19. Juli 2017 00:26:16 UTC+2 schrieb Charles Reiss:
> https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL 
> Class 3 CA 1 2009 containing the DNS SAN 
> 'www.lbv-gis.brandenburg.de/lbvagszit' (containing a '/') with a 
> notBefore in April 2017.
> 

Regarding this Topic, this incorpates the D-Trust PostMortem, 
Remidiation and Revocation Status. Regards, Kim

Issue dNSName containing '/', https://crt.sh/?id=174827359 

PostMortem:
An incident was triggered by a bug in mozilla.dev.security.policy 07-08-2017.
Issuance was stopped immediately at 07-08-2017
Analysis yielded the following results:
Validation is based on both a four-eyed principle “human” approach as well as a 
tool based automated validation.
The GUI of our validation software backend which our team is using had some 
usability and visualization related issues. This implied that the way multiple 
SANs were displayed had potential for mistakes. We released the improvement of 
the backend GUI on the 2017-08-24 as previously announced.
The bug mentioned with respect to the CSR Validator was that the CSR validator 
didn’t filter prohibited characters correctly and was introduced by the 
previous release but was not recognized during test. 

Mitigation/Remediation:
Existing Mitigations: Certificates require two independent parties to approve 
("four eyes principle")

Remediation:
2017-08-15 - The Certificate was revoked
2017-08-24 - Hotfix to systems to validate CSR against RFC 5280
2017-08-24 - Hotfix to update validation software UI to reduce risk of mistakes
2018-03-31 - Improved software testing to consider such cases
In order to enhance the quality assurance during issuance we are setting up 
both manual random checks as well as automated compliance checks in our 
issuance system. 
Also a case-related awareness training was performed.

Revocation plan:
The cert was revoked, a new BR compliant cert was issued for the costumer
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy