RE: GoDaddy Misissuance Action Items

[Wayne Thayer via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy


> Here is our proposed remediation plan for GoDaddy.
> 
> 1) As with all CAs, update all their domain validation code to use one of the 
> 10
> approved methods;
> 
> 2) Implement comprehensive automated testing for their domain validation
> code for all issuance systems;
> 
> 3) Make sure those tests automatically run when any change is made to the
> code, before deployment, such that deployment is gated on a pass;
> 
> 4) Get a statement from their auditors that these tests have been created
> and positioned correctly in the deployment workflow.
> 
> All steps to be completed within 3 months.
> 
> Comments on this plan are welcome, including from GoDaddy.
>

Gerv - this makes sense and it is GoDaddy's intent to perform these steps 
within 3 months.

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

Re: Swiss Government root inclusion request

[Wayne Thayer via dev-security-policy]

On Thursday, November 23, 2017 at 4:03:27 AM UTC-7, 
michael.vonn...@bit.admin.ch wrote:
> Hi Matt
> 
> Thank you for your statement.
> 
> Let me try to clarify:
> 
> In 3.2.2.4 we specify the Authorization by Domain Name Registrant as follows:
> 
> 3.2.2.4 Authorization by Domain Name Registrant For each Fully-Qualified 
> Domain Name listed in a Certificate, SG PKI confirms that, as of the date the 
> Certificate was issued, the Applicant (or the Applicant's Parent Company, 
> Subsidiary Company or Affiliate, collectively referred to as "Applicant" for 
> the purpose of this Section) either is the Domain Name Registrant or has 
> control over the FQDN by:
> - communicating directly with the Domain Name Registrant using the contact 
> information listed in the WHOIS records "registrant", "technical" or 
> "administrative" field.
> - Relying upon a Domain Authorization Document approved by the Domain Name 
> Registrant. The document MUST be dated on or after the certificate request 
> date or used by SG PKI to verify a previously issued certificate and that the 
> Domain Name's WHOIS record has not been modified since the previous 
> certificate issuance.
> 
The Mozilla policy requires the CPS to reference the specific BR section, so at 
the very least the CPS is out of compliance because it does not contain these 
references.
>
> And in paragraph 4.2 the certificate application process is described and 
> refers in the end to the before mentioned checklist:
> 
> [...]
> The validation process is detailed in a checklist for each certificate type. 
> [25][26][27] [...]
>
Mozilla's Required Practices document [1] specifies more details on the amount 
of disclosure required for a CA's domain validation methods.
>
> As the checklist potentially needs to be adapted to actual threats, we chose 
> to leave it in a separate document and refer to it in the CPS to make the 
> check procedure transparent.
> If required, we will adapt this procedure and integrate all steps into the 
> CPS. That would make the checklist document handling less agile. I would 
> appreciate some more input on this point from others, before we change that.
>
I'm familiar with a number of CPS documents and they all include details on 
domain validation practices. I'm also concerned about the separate document 
because:
1. It was not accessible when I originally requested it (404)
2. It contains a comment that implies the use of 7 methods instead of just two 
as stated in the CPS
3. That comment references outdated methods including "any other"
4. It appears that the document hasn't been updated in over a year and it 
contains no version control information other than a date and "version 1.0" 
> 
> Regards
> Michael

[1] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Anomalous Certificate Issuances based on historic CAA records

[Wayne Thayer via dev-security-policy]

What problem(s) are you trying to solve?

- Subscribers already (or soon will) have CT logs and monitors available to
detect mis-issued certs. They don't need CAA Transparency.

- This thread started as a discussion over possible mis-issuance that was
determined to be false positives. As has been stated, without DNSSEC there
is no such thing as a coherent view of DNS and Ryan described a legitimate
example where a domain owner may consciously update CAA records briefly to
permit issuance. It's unclear to me how CAA Transparency could solve this
problem and thus provide a mechanism to confirm mis-issuance, if that is
the goal.

- The goal of reducing the risk of mis-issuance from well-behaved CAs who
have bad or manipulated CAA data seems most worthwhile to me. To Ryan's
point (I think), there may be better ways of achieving this one such as
requiring CAs to "gossip" CAA records, or requiring CAA checks be performed
from multiple network locations.

Wayne

On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think there’s value in publicly logging things even if that isn’t the
> basis for trust.  So I disagree that what I wrote boils down to what I
> didn’t write.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA generated keys

[Wayne Thayer via dev-security-policy]

On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I don't know but it's worth talking about.  I think the discussion should
> be
> "when should this be allowed, and how can it be done securely?"
>
> The outcome to be avoided is a CA that holds in escrow thousands of
private keys used for TLS. I don’t think that a policy permitting a CA to
generate the key pair is bad as long as the CA doesn’t hold on to the key
(unless  the certificate was issued to the CA or the CA is hosting the
site).

What if the policy were to allow CA key generation but require the CA to
deliver the private key to the Subscriber and destroy the CA’s copy prior
to issuing a certificate? Would that make key generation easier? Tim, some
examples describing how this might be used would be helpful here.

A policy allowing CAs to generate key pairs should also include provisions
for:
- The CA must generate the key in accordance with technical best practices
- While in possession of the private key, the CA must store it securely

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

Re: On the value of EV

[Wayne Thayer via dev-security-policy]

Thank you Ryan for raising this question, and to everyone who has been
contributing in a constructive manner to the discussion. A number of
excellent points have been raised on the effectiveness of EV in general and
on the practicality of solving the problems that exist with EV.

While we have concerns about the value of EV as well as the potential for
EV to actually harm users, Mozilla currently has no definite plans to
remove the EV UI from Firefox. At the very least, we want to see
Certificate Transparency required for all certificates before making any
change that is likely to reduce the use of EV certificates.

Is Google planning to remove the EV UI from desktop Chrome? If so, how does
that relate to the plan to mark HTTP sites as ‘Not secure’ [1]? Does this
imply the complete removal of HTTPS UI?

While we agree that improvements to EV validation won’t remove many of the
underlying issues that have been raised here, we hope that CAs will move
quickly to make the EV Subject information displayed in the address bar
more reliable and less confusing.

- Wayne

[1]
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thank you for your notes,
> Here are the answers to your points.
>
> all the "bad" points about the CPS were addressed:
> Both CPS's are now changed to ver 4.1
>

Looks good, thank you.

section 1 states that we are addressing the latest BR
>

I am not convinced that section 1 of your CPS meets the requirements set
forth in BR 2.2. Your CPS states:

Comsign will develop, implement, enforce, and annually update these
Procedures in accordance with the requirements of the Law, the latest
requirements of the CA/Browser forum and any other relevant practices and
requirements.

The BRs state that you 'must include a link to the official version of
these Requirements'. Also, your CPS says that you will annually update your
procedures, while the BRs require the CA to commit to comply with the
latest public version at all times.

3.2.2.4 was corrected
>

My concern about delegated third parties was addressed (thank you), but my
concern about homograph spoofing was not.

Also, my final point about the audit report covering the period from
2014-10-26 to 2015-04-27 was not addressed.


> i'm also attaching the new CPS'es so you can review them
>
> About the "creative commons license" it is indeed not listed and therefore
> according to Mozilla policy 3.3 will automatically be treated as CC-BY-ND
> 4.0.
> I'm also attaching the audit for October 2014 as requested and recent
> audits who include the intermediate certificates.
>
> I do not think this is the intent of the policy, but I agree that this is
allowed. I've added an issue [1] to consider updating this requirement in
the next version of the policy.

[1] https://github.com/mozilla/pkipolicy/issues/110

>
> Link to all the attachments:
>
> https://drive.google.com/open?id=1VzrWqouZeda5bQkyhdboO_KvfBo9QV17
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA generated keys

[Wayne Thayer via dev-security-policy]

On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/12/2017 19:39, Wayne Thayer wrote:
>
>> The outcome to be avoided is a CA that holds in escrow thousands of
>> private keys used for TLS. I don’t think that a policy permitting a CA to
>> generate the key pair is bad as long as the CA doesn’t hold on to the key
>> (unless  the certificate was issued to the CA or the CA is hosting the
>> site).
>>
>> What if the policy were to allow CA key generation but require the CA to
>> deliver the private key to the Subscriber and destroy the CA’s copy prior
>> to issuing a certificate? Would that make key generation easier? Tim, some
>> examples describing how this might be used would be helpful here.
>>
>>
> That would conflict with delivery in PKCS#12 format or any other format
> that delivers the key and certificate together, as users of such
> services commonly expect.
>
> Yes, it would. But it's a clear policy. If the requirement is to deliver
the key at the same time as the certificate, then how long can the CA hold
the private key?



> It would also conflict with keeping the issuing CA key far removed from
> public web interfaces, such as the interface used by users to pick up
> their key and certificate, even if separate, as it would not be fun to
> have to log in twice with 1 hour in between (once to pick up key, then
> once again to pick up certificate).
>
> I don't think I understand this use case, or how the proposed policy
relates to the issuing CA.


> It would only really work with a CSR+key generation service where the
> user receives the key at application time, then the cert after vetting.
> And many end systems cannot easily import that.
>
> Many commercial CAs could accommodate a workflow where they deliver the
private key at application time. Maybe you are thinking of IOT scenarios?
Again, some use cases describing the problem would be helpful.


> A policy allowing CAs to generate key pairs should also include provisions
>> for:
>> - The CA must generate the key in accordance with technical best practices
>> - While in possession of the private key, the CA must store it securely
>>
>> Wayne
>>
>>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

[Wayne Thayer via dev-security-policy]

Thanks Rob! I went through the list and filed a bug for each CA if there
wasn't one already open (with one exception that I'm still researching).
All open OCSP issues are included in the list at
https://wiki.mozilla.org/CA/Incident_Dashboard

Wayne

On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Some example reports:
>
> 1. CAs / Responder URLs that are in scope for, but violate, the BR
> prohibition on returning a signed a "Good" response for a random serial
> number, and are also in scope for Mozilla's consideration:
> https://crt.sh/ocsp-responders?trustedExclude=constrained%
> 2Cexpired%2Conecrl=Mozilla=Server+Auth
> entication=Good
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)

[Wayne Thayer via dev-security-policy]

On Thu, Nov 9, 2017 at 1:25 PM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> There's always a risk that a CA owner will create a security nightmare
> when we aren't looking, probationary period or not. In theory regular
> audits help to prevent it, but even in cases where they don't, people are
> free to raise concerns as they come up. I think we've had examples of
> exactly that in both StartCom and Symantec.‎
>

I agree. What we're really talking about here is the removal of trust in a
CA based on new information. In the case of an acquisition, that
information may not be publicly available until after a deal is completed,
making the current requirement to halt issuance very disruptive. I'd modify
section 8.1 of the policy to distinguish an acquisition of the CA
operations from a purchase of a root key, and only require approval prior
to issuance in the latter case.

>
>
Perhaps one way to think of it is: Do we have reason to believe that the
> acquiring organization, leadership, etc. will probably make good decisions
> in the furtherance of public trust on the Internet? For a company that is a
> complete unknown, I would say that no evidence exists and therefore a
> public review prior to the acquisition is appropriate. If we do have
> sufficient evidence, perhaps it's OK to let the acquisition go through and
> have a public discussion afterwards.
>

The CA should be responsible for providing information about the effect of
the acquisition on their operations. In this case, Robin provided some
essentials:

>As you have seen from the announcement, we have a new CEO and new Chairman
>who have prior experience in managing a trusted CA organization.
>
>There are to be no resultant changes to our CPS, our operations, our
>business policies or procedures, or the secure locations from which we
>operate our CA infrastructure.
>
>The operational personnel in Comodo CA Limited will not change.  The
>certificate validation teams will remain unchanged.

The policy already requires the CA to disclose any CPS changes. I'd add a
requirement that the CA provide a public statement describing all material
changes that will be made as a result of the acquisition. That statement
should be signed by Senior management of the acquiring company. The CA
should also [obviously] be expected to answer any reasonable questions that
are raised during the discussion period.

>
> The Francisco Partners situation is more complicated, however. Francisco
> Partners itself does not strike me as the sort of company that should own a
> CA but only because they are investors and not a public trust firm of some
> sort. That said, they are smart enough to bring in a leadership team that
> does have knowledge and experience in this space. Unfortunately, though,
> they are also bringing in a Deep Packet Inspection business which is
> antithetical to public trust. So what is one to conclude?
>
> The reporting that I've seen seem to indicate that Francisco Partners will
> not (will never?) combine ‎PKI and DPI into a single business operation.
> They have to know that doing so would be ruinous to their CA investment. If
> we assume they know that and if we are willing to take them at their word,
> I suppose it's reasonable to "allow" the transfer as it relates to Mozilla
> policy. If we should learn later on that that trust was misplaced, I'm sure
> we will discuss it and take appropriate action at that time.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

> We can restart the discussion and please review their updated documents and 
> comment in this discussion if you have further questions or concerns about 
> this request.
> 
After reviewing Comsign's updated CPS and related documents, I have the 
following comments:

== Good ==
- CPS follows RFC 3647 and includes a table of revisions
- CAA requirements are met
- Audit reports cover a full year
- Contact information for problem reporting is clearly stated in section 4.9.3
- Aside from what I’ve listed below, all of the issues reported earlier by Ryan 
Sleevi appear to have been addressed.

== Meh ==
- Fingerprints in the audit reports are SHA-1; should be SHA-256
- The CPS is located at https://www.comsign.co.il/CPS under the heading “CPS – 
in accordance with the Electronic Signature Law of Israel” but earlier 
discussions indicate that SSL certificates aren’t covered by this law, in which 
case it’s not clear what the difference is between this CPS and the one listed 
under “CPS – for - Certificates that are not under the Electronic Signature Law 
of Israel” on the same page.
- None of the subordinate CAs contain an EKU extension. [1]
- Section 3.1.3 states that “Comsign will not issue an Electronic Certificate 
bearing a nickname of the Subscriber or one that does not state the name of the 
Subscriber” but section 7.1.2.3(iv) shows a DV certificate profile that doesn’t 
name the Subscriber. If the term ‘Electronic Certificate’ is intended to only 
apply to non-SSL certificates, then the definition should be clarified.
- The domain validation methods specified in CPS section 3.2.2.4 are nearly 
cut-and-paste from the BRs, so this section provides little information that 
can be used to evaluate Comsign’s domain validation practices. [2]
- None of the four intermediates shown in the root hierarchy diagram [3] are 
disclosed in CCADB at this time (this isn’t required until the root is 
included). There are (at least) 3 different “ComSign Organizational CA” 
subordinate CA certificates with the same public key that should be disclosed.

== Bad ==
- The Hebrew version of the CPS at https://www.comsign.co.il/repository/ is 
version 3.1 while the English version on the same page is 4.0, so I assume that 
these are different documents. I see nothing in the English version stating 
that it takes precedence over the Hebrew version.
- Section 1 of the CPS doesn’t clearly state that Comsign adheres to the 
**latest** version of the BRs, nor that the BRs take precedence over the CPS 
(BR 2.2).
- The Creative Commons license is not listed in the CPS (Mozilla policy 3.3).
- Audit reports don’t list any intermediates covered by the audit (Mozilla 
policy 3.1.4).
- 3.2.2.4 states “All authentication  and  verification  procedures  in  this  
sub-section shall be  performed  either  directly by Comsign's personnel (RAs) 
or by Comsign's authorized representatives.”. There is no definition of who can 
be an ‘authorized representative’, but in this context it sounds like a 
Delegated Third Party, and CAs are not permitted to delegate domain validation 
(BR 1.3.2).
- CPS 3.2.2.4 states: “For  issuing certificates to organizations requesting 
SSL certificates,Comsign performs domain name owners verification to detect 
cases of homographic spoofing of IDNs. Comsign employs an automated or manual 
process that searches various ‘whois’ services to find the owner of a 
particular domain. A search failure result is flagged and the RA rejects the 
Certificate Request. Additionally, the RA rejects any domain name that visually 
appears to be made up of multiple scripts within one hostname label.” How does 
a WHOIS check or a human review effectively detect mixed scripts in a label? I 
don’t believe this is an effective safeguard against homograph spoofing.
- The audit reports supplied cover the period from 2015-04-27 to present. This 
doesn’t appear to satisfy the requirement for an unbroken sequence of audit 
periods back to the issuance of the first certificate on 2014-10-26 (refer to 
earlier discussion in this thread).

Wayne

[1] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Usage_of_Appropriate_Constraints
[2] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership
[3] https://bug675060.bmoattachments.org/attachment.cgi?id=8608692
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Wayne Thayer via dev-security-policy]

On Fri, Dec 8, 2017 at 3:55 PM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> So I wonder: If a CA signs an intermediate - are they responsible
> making sure that reports brought to the subca are properly handled?
>
> The root CA is ultimately responsible for subordinate CAs it has signed.
That's why I asked DigiCert for an incident report via
https://bugzilla.mozilla.org/show_bug.cgi?id=1424305

Having said that, I do think there are a few opportunities for improvement
here. DigiCert couldn't directly revoke the compromised certificates, so I
think it makes sense to add problem reporting mechanisms for subordinate
CAs to CCADB when they differ from the root. That would also help when the
problem reporting mechanism is buried in the CPS or when a general email
address is published but there is no indication that it is the one the CA
monitors 24x7 for certificate problem reports (both issues apply here).

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

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Wayne Thayer via dev-security-policy]

On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sat, 9 Dec 2017 09:51:59 +0100
> Hanno Böck via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> > On Fri, 8 Dec 2017 16:43:48 -0700
> > Wayne Thayer via dev-security-policy
> > <dev-security-policy@lists.mozilla.org> wrote:
> >
> > > The root CA is ultimately responsible for subordinate CAs it has
> > > signed.
> >
> > I see a problem with that, as this is far from obvious.
>
> I saw "responsibility" here as meaning responsibility to the Trust
> Stores on behalf of the Relying Parties. For the Relying Parties
> themselves I think the right pattern is: Try filing a Problem Report
> with the Issuer, if the result isn't satisfactory, complain to your
> Trust Store(s). We can do the rest, can we not?
>
> Yes, I think we're talking about two separate problems. I was looking at
this from Mozilla's perspective.

>
> > I'm mostly not concerned about the people following these things
> > closely and are members of this list, but about random other people who
> > happen to find problems. It surely seems beneficial for the certificate
> > ecosystem to make sure that they can easily find the right place to
> > report problems.


It can be confusing even for people following these things. That's where I
think collecting problem reporting info from audited sub-CAs in CCADB would
help.

For everyone else, finding the correct problem reporting information is
mostly a matter of luck. Perhaps we should require an email address be
included in the end-entity certificate? Unless that info was exposed in the
browser, it would still be difficult to find, but at least it would then be
in a consistent location.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Swiss Government root inclusion request

[Wayne Thayer via dev-security-policy]

I've placed this discussion on hold pending:

1. Updated audit statement specifying the audit period.
2. Updated CP/CPS including CAA information, BR compliance statement, and 
clearer specification of the domain validation procedures that are in use.

Wayne
>On Tuesday, November 28, 2017 at 4:35:37 PM UTC-7, wth...@mozilla.com wrote:
>> On Thursday, November 23, 2017 at 4:03:27 AM UTC-7, 
>> michael.vonn...@bit.admin.ch wrote:
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Doug,

I am not aware of any requirement for CAs to detect or prevent homograph
spoofing in the names contained in certificates they issue. Mozilla's
position is that this is something best handled by registries/registrars
just as stated in the CPS you quoted.

In the case of the ComSign CPS, my concerns were that the paragraph was
confusing and it described an ineffective process, so I asked for
clarification.

Wayne

On Tue, Dec 19, 2017 at 4:14 PM, Doug Beattie <doug.beat...@globalsign.com>
wrote:

> Hi Wayne,
>
> I noticed your comment on IDN validation. Is there a requirement that CAs
> establish an effective safeguard against homograph spoofing?
>
> The reason I ask is that Let's Encrypt's CPS  says this: "Regarding
> Internationalized Domain Names, ISRG will have no objection so long as the
> domain is resolvable via DNS. It is the CA’s position that homoglyph
> spoofing should be dealt with by registrars, and Web browsers should have
> sensible policies for when to display the punycode versions of names."
>
> Doug
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> > Wayne Thayer via dev-security-policy
> > Sent: Tuesday, December 5, 2017 1:44 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: ComSign Root Renewal Request
> >
> > > We can restart the discussion and please review their updated documents
> > and comment in this discussion if you have further questions or concerns
> > about this request.
> > >
> > After reviewing Comsign's updated CPS and related documents, I have the
> > following comments:
> >
> > == Good ==
> > - CPS follows RFC 3647 and includes a table of revisions
> > - CAA requirements are met
> > - Audit reports cover a full year
> > - Contact information for problem reporting is clearly stated in section
> 4.9.3
> > - Aside from what I’ve listed below, all of the issues reported earlier
> by Ryan
> > Sleevi appear to have been addressed.
> >
> > == Meh ==
> > - Fingerprints in the audit reports are SHA-1; should be SHA-256
> > - The CPS is located at https://www.comsign.co.il/CPS under the heading
> > “CPS – in accordance with the Electronic Signature Law of Israel” but
> earlier
> > discussions indicate that SSL certificates aren’t covered by this law,
> in which
> > case it’s not clear what the difference is between this CPS and the one
> listed
> > under “CPS – for - Certificates that are not under the Electronic
> Signature
> > Law of Israel” on the same page.
> > - None of the subordinate CAs contain an EKU extension. [1]
> > - Section 3.1.3 states that “Comsign will not issue an Electronic
> Certificate
> > bearing a nickname of the Subscriber or one that does not state the name
> of
> > the Subscriber” but section 7.1.2.3(iv) shows a DV certificate profile
> that
> > doesn’t name the Subscriber. If the term ‘Electronic Certificate’ is
> intended
> > to only apply to non-SSL certificates, then the definition should be
> clarified.
> > - The domain validation methods specified in CPS section 3.2.2.4 are
> nearly
> > cut-and-paste from the BRs, so this section provides little information
> that
> > can be used to evaluate Comsign’s domain validation practices. [2]
> > - None of the four intermediates shown in the root hierarchy diagram [3]
> are
> > disclosed in CCADB at this time (this isn’t required until the root is
> included).
> > There are (at least) 3 different “ComSign Organizational CA” subordinate
> CA
> > certificates with the same public key that should be disclosed.
> >
> > == Bad ==
> > - The Hebrew version of the CPS at https://www.comsign.co.il/repository/
> is
> > version 3.1 while the English version on the same page is 4.0, so I
> assume
> > that these are different documents. I see nothing in the English version
> > stating that it takes precedence over the Hebrew version.
> > - Section 1 of the CPS doesn’t clearly state that Comsign adheres to the
> > **latest** version of the BRs, nor that the BRs take precedence over the
> CPS
> > (BR 2.2).
> > - The Creative Commons license is not listed in the CPS (Mozilla policy
> 3.3).
> > - Audit reports don’t list any intermediates covered by the audit
> (Mozilla
> > policy 3.1.4).
> > - 3.2.2.4 states “All authentication  and  verification  procedures  in
> this  sub-
> > section shall be  performed  either  directly by Comsign's personnel
> (RAs) or
> > by Comsign's authorized representatives.

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey Doug,
>
> On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote:
> > Hey Wayne,
> >
> > This should be a really easy thing, but it's not.
> >
> > First comments on this: "MUST be encrypted and signed; or, MUST have a
> password that..."
> > - Isn't the password the key used for encryption?  I'm not sure if the
> "or" makes sense since in both cases the password is the key for encryption
>
> The password is used through a round of hashes (or a pbkdf, depending on
> the algorithm) to create a set of bits that are used as a key. (see
> paragraph 6 here: https://www.cem.me/20150315-cert-binaries-6.html)
>
> > - In general, I don't think PKCS#12 files are signed, so I'd leave that
> out, a signature isn't necessary.  I could be wrong...
>
> That goes back to Ryan's comment here:
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/SYC0d1YgXtI/slRunsYbAgAJ
> "PKCS#12 supports both symmetric and asymmetric key based protection also."
>
> >
Yes, that is the intent. If my wording is poor, please suggest improvements.
>

>
>
> > I'd still like to see a modification on the requirement: "password MUST
> be transferred using a different channel than the PKCS#12 file".  A user
> should be able to download the P12 and password via HTTP.  Can we add an
> exception for that?
>
> >
I'd like to hear from others who think this is needed.
>

> What about "or a user supplied password"?
>
>
Doesn't the current language already permit this? It does make sense if
you're suggesting it to Doug as a workaround.
>

> -carl
> ___
> 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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

The optimist in me thinks we might be getting close to resolving this issue
(the last one remaining for the 2.6 policy update). Here is another
proposal that attempts to account for most of the input we've received:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>
> PKCS#12 files must employ an encryption algorithm that is sufficiently
> strong to protect the key pair for its useful life based on current
> guidelines published by a recognized standards body. PKCS#12 files MUST be
> encrypted and signed; or, MUST have a password that exhibits at least 112
> bits of entropy, and the password MUST be transferred using a different
> channel than the PKCS#12 file.
>

This isn't perfect. I would appreciate your comments if you have
significant concerns with this proposed policy.

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

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> > I think we have settled on the following resolution to this issue:
> >
> > Add the following to section 5.2 (Forbidden and Required Practices):
> >
> > CAs MUST NOT generate the key pairs for end-entity certificates that have
> > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > > anyExtendedKeyUsage.
> > >
> > > PKCS#12 files must employ an encryption key and algorithm that is
> > > sufficiently strong to protect the key pair for its useful life based
> on
> > > current guidelines published by a recognized standards body. PKCS#12
> files
> > > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > > least 112 bits of entropy, and the password MUST be transferred using a
> > > different channel than the PKCS#12 file.
> > >
> >
> > Unless there is further discussion, I will include this language in the
> > final version of the policy.
> >
> > - Wayne
>
> In one use case, the Subscriber can create their own password to start the
> enrollment process for the S/MIME certificate. The P12 is created,
> encrypted and sent to the Subscriber to be decrypted using the password. I
> think that asking the Subscriber to create a password with 112-bits entropy
> may create a very long password (over 20 characters). I think that this
> will take much longer than the life of the certificate (or its user) to
> crack. This password may also be recorded improperly or recorded on the
> same device as the key will reside. Could we consider reducing the size of
> the password?
>
> Remember that this only applies when the CA generates the key pair. If the
CA must for some reason do that, then it's reasonable to expect the CA to
secure it with a strong password.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
Or the user could generate the key :-)
>

> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assuming we want to
> continue supporting that option).
>
> Perhaps the following language is a workable solution to the first
objection?

PKCS#12 files must employ an encryption key and algorithm that is
sufficiently strong to protect the key pair for its useful life based on
current guidelines published by a recognized standards body. PKCS#12 files
MUST be encrypted and signed; or, MUST have a password that exhibits at
least 112 bits of entropy, and the password MUST be transmitted via a
secure channel.

I really don't seem a benefit to user generation of these passwords -
either they are weak and memorable, or sufficiently complicated that
there's little value in being able to choose it.

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

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

Doug,

On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 4:35 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> CA key
> > generation to policy)
> >
> > On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
> > > First comments on this: "MUST be encrypted and signed; or, MUST have a
> > password that..."
> > > - Isn't the password the key used for encryption?  I'm not sure if the
> "or"
> > makes sense since in both cases the password is the key for encryption
> >
> > There are modes of PKCS#12 that do not use passwords.
> If you're stating that we should include the use of PKCS#12 that don't use
> passwords and that are encrupted, then we need to define the parameters of
> the key used for that purpose,
>
> >
Would it be enough to say that "PKCS#12 files must employ an encryption key
and algorithm that is sufficiently strong..." (add "key and")?
>

> > > - In general, I don't think PKCS#12 files are signed, so I'd leave
> that out, a
> > signature isn't necessary.  I could be wrong...
> >
> > They may be, see: http://unmitigatedrisk.com/?p=543
> The requirement seems to imply it must be signed, and I don't think we
> want that, do we?  I think should remove "or signed" and that will permit
> them to be signed, but not require it.
>
>
 That's not hoe I read it. The proposed language provides the option of
'encrypted and signed' or 'protected with a password'. Since your use case
is 'protected with a password', there is no requirement for the file to be
signed.
>

> > >
> > > I'd still like to see a modification on the requirement: "password
> MUST be
> > transferred using a different channel than the PKCS#12 file".  A user
> should be
> > able to download the P12 and password via HTTP.  Can we add an exception
> > for that?
> >
> > Why do you want to allow the use of HTTP?
> Sorry, I meant HTTPS.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I suggest to make the requirement „* The PKCS#12 file must have a
> sufficiently secure password, and the password must be transferred via a
> separate channel than the PKCS#12 file.” binding for both transfer methods
> and not be limited to physical data storage.
> Otherwise I agree with this proposal.
>
> Enrico
>
> That seems like a good and reasonable change, resulting in the following
policy:

CAs MUST NOT generate the key pairs for end-entity certificates that have
EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
insecure electronic channels. The PKCS#12 file must have a sufficiently
secure password, and the password must not be transferred together with the
file. If a PKCS#12 file is distributed via a physical data storage device,
then the storage must be packaged in a way that the opening of the package
causes irrecoverable physical damage. (e.g. a security seal)

Unless other comments are made, I'll consider this to be the conclusion of
discussion on this topic.

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

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Wayne Thayer via dev-security-policy]

On Thu, Apr 26, 2018 at 6:59 AM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote:
> > > > which is why in the near future we can hopefully use RDAP over TLS
> > > > (RFC
> > > > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> > >
> > > I agree moving away from WHOIS to RDAP over TLS is a good low hanging
> fruit
> > > mitigator once it is viable.
> >
> > My opinion is it is viable now, and the time to transition to optionally
> authenticated RDAP over TLS is now.  It solves pretty much all the problems
> we are currently having in a straightforward, standards-based way.
> >
> > The only opposition I've seem comes from people who seem to want to
> promote alternative models that destroy the WHOIS ecosystem, leading to
> proprietary distribution and monetization of WHOIS data.
> >
> > I can see why that is attractive to some people, but I don’t think it's
> best for everyone.
> >
> > I also agree that DNSSEC is a lost cause, though I understand why Paul
> doesn't want to give up   I've wanted to see it succeed for basically my
> entire career, but it seems to be making about as much progress as fusion
> energy.
> >
>
I don't think this opinion is in conflict with the suggestion that we
required DNSSEC validation on CAA records when (however rarely) it is
deployed. I added this as https://github.com/mozilla/pkipolicy/issues/133


> > -Tim
>
> Moving to RDAP does not solve "all the problems we are currently having"
> in that it does not do anything for DCV which is what I think this thread
> was about (e.g. BGP implications for DCV).
>
> I agree that these are two different issues. I added
https://github.com/mozilla/pkipolicy/issues/134 to track the proposal to
require CAs to perform domain validations from multiple network
perspectives. I do suspect this will be difficult to define in a policy.

That said, if in fact, RDAP is viable today I agree we should deprecate the
> use of WhoIs and mandate use of RDAP in the associated scenarios.
>
> I began work on a CAB Forum ballot that adds explicit BR support for RDAP.
I could be wrong, but I doubt that RDAP deployment is far enough along that
we can deprecate WHOIS.

I will also raise the first two issues with the CAB Forum because I think
they are better addressed in the BRs than in Mozilla policy.

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

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

I think we have settled on the following resolution to this issue:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be encrypted and signed; or, MUST have a password that exhibits at
> least 112 bits of entropy, and the password MUST be transferred using a
> different channel than the PKCS#12 file.
>

Unless there is further discussion, I will include this language in the
final version of the policy.

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

Policy 2.6 Proposal: Update Minimum Audit Versions

[Wayne Thayer via dev-security-policy]

After consulting with representatives from WebTrust and ETSI, I propose
that we update the minimum required versions of audit criteria in section
3.1.1 as follows:

- WebTrust "Principles and Criteria for Certification Authorities -
Extended Validation SSL" from 1.4.5 to 1.6.0 or later
- “Trust Service Providers practice” in ETSI EN 319 411-1 from 1.1.1 to 1.2
or later
- “Trust Service Providers practice” in ETSI EN 319 411-2  from 2.1.1 to
2.2 or later

These newer versions were all published last year and should be the minimum
for audits completed from now on.

Please respond with any concerns you have about this update to our root
store policy.

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

Re: question about DNS CAA and S/MIME certificates

[Wayne Thayer via dev-security-policy]

I created a new issue suggesting that we add this requirement to Mozilla
policy: https://github.com/mozilla/pkipolicy/issues/135

On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello,
> > this question is somewhat outside the current Baseline Requirements,
> but...
> >
> > wouldn't it be normal for the same CAA rules for server certificates to
> > also apply to client certificates when the email address is for a domain
> > that already has a valid CAA policy published in DNS?
> >
> >
> > RFC 6844 doesn't seem to make any distinction between server and S/MIME
> > client certificates, it combines them together by referring to
> certificates
> > "for that domain" as a whole.
> >
> >
> > i tested this last night - i obtained an email certificate from one of
> the
> > CAs participating here (not for this exact address though) and it was
> > happily issued even if CAA records authenticated by DNSSEC do not allow
> > their CA to issue for this domain.
> >
> > Now, this is technically not a mis-issuance because it was a proper
> > email-validated address and their CPS says that CAA is only checked for
> > server-type certificates. It doesn't say anything about CAA validation
> for
> > such client certificates.
> >
> > I got in touch with them and they seemed equally surprised by such
> > intended use case for CAA, so my second question is: is anyone actually
> > checking CAA records for client certificates where an email address is
> > included in the certificate subject info and the EKU includes Secure
> Email?
> >
> >
> > Or is CAA usually checked only for server-type certificates, even if RFC
> > 6844 refers to certificates "for that domain" as a whole?
> >
>
> CAs are generally only checking CAA when they're required to in order to be
> trusted.
>
> Right now, CAs are only required to check CAA for server-type certificates
> (by virtue of the Baseline Requirements Section 3.2.2.8).
> CAs are not presently being required to check CAA for e-mail. They can, but
> they are required to do it, so they are unlikely to do it.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

We're concluding discussions on all of the issues identified for version
2.6 of the policy [1].

You can find a complete set of changes here:
https://github.com/mozilla/pkipolicy/compare/master...2.6

Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs
the current practice is to wait for the next required annual review
(usually coinciding with their audit) to make CP/CPS changes. Do we want to
allow that practice to continue, or set a date by which we expect CP/CPSs
to reflect the new requirements? This was previously discussed [4], with
the outcome being that we would make these decisions on a case-by-case
basis.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93=label%3A2.6+
[2]
https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8
[3]
https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ

On Mon, Mar 19, 2018 at 10:15 PM Wayne Thayer  wrote:

> There are 17 proposed changes in total for version 2.6 of the policy, and
> I'm about to kick off discussions on the first batch. I expect some of
> these to be straightforward while others will hopefully generate good
> dialogues. As always, everyone's constructive input is appreciated.
>
> Thanks,
>
> Wayne
>
> On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer  wrote:
>
>> I've added the issue of subordinate CA transfers to the list for policy
>> version 2.6: https://github.com/mozilla/pkipolicy/issues/122
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

[Wayne Thayer via dev-security-policy]

My understanding of this discussion is that it is too soon to increase the
minimum required versions of EN 319 411-1 and 319 411-2. I will only make
the proposed change to the WebTrust EV version in the 2.6 policy update.

- Wayne

On Fri, May 11, 2018 at 12:19 PM <ji...@it.auth.gr> wrote:

> Thanks Peter, I think we are in agreement.
>
> Dimitris.
>
> -Original Message-
> From: "Peter Miškovič via dev-security-policy" <
> dev-security-policy@lists.mozilla.org>
> To: Dimitris Zacharopoulos <ji...@it.auth.gr>, Wayne Thayer <
> wtha...@mozilla.com>, mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Sent: Fri, 11 May 2018 12:53
> Subject: RE: Policy 2.6 Proposal: Update Minimum Audit Versions
>
> Hi Dimitris,
>
> the official list of ETSI published standards you can find at
> http://www.etsi.org/standards-search#Pre-defined%20Collections
>
> If you search for ETSI EN 319 411 you can find that only officially  ETSI
> published versions for ETSI EN 319 411-1 <3194111> were V1.1.1 (2016-02)
> and V1.2.2 (2018-04). Any other version, according document history on the
> last page of standard, were version for  EN approval Procedure (V1.2.0) or
> Vote (V1.2.1).  It means that versions 1.2.0 and 1.2.1 were not officially
> published by ETSI.
>
> For ETSI EN 319 411-2 <3194112> you can find that only official ETSI
> published version were versions V2.1.1 (2016-02) and V2.2.2 (2018-04).
>
> According this the minimal requirements should looks like:
>
> “Trust Service Providers practice” in ETSI EN 319 411-1 <3194111> version
> 1.1.1 or version 1.2.2 or later ETSI officially published version.
> “Trust Service Providers practice” in ETSI EN 319 411-2 <3194112>
> version 2.1.1  or version 2.2.2 or later ETSI officially published version
>
> Regards
> Peter
>
>
>
>
> -Original Message-
> From: Dimitris Zacharopoulos <ji...@it.auth.gr>
> Sent: Friday, May 11, 2018 7:23 AM
> To: Peter Miškovič <peter.misko...@disig.sk>; Wayne Thayer <
> wtha...@mozilla.com>; mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.6 Proposal: Update Minimum Audit Versions
>
> Hello Peter,
>
> These were very recently published however not everyone is tracking down
> ETSI updates by registering to the mailing lists. The main question is
> where can you find the authoritative document *list*? I though the official
> list is https://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx.
>
> Also, were there any other versions published before 1.2.2? The
> recommendation says "1.2 or later". Where are the versions 1.2.0, 1.2.1
> published?
>
> Thanks,
> Dimitris.
>
> On 11/5/2018 8:13 πμ, Peter Miškovič via dev-security-policy wrote:
> > There were published a new versions of both ETSI standards:
> >
> > ETSI EN 319 411-1 <3194111> V1.2.2 adopted on April 23, 2018
> > http://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.02.02_60
> > /en_31941101v010202p.pdf
> >
> > ETSI EN 319 411-2 <3194112> V2.2.2 adopted on April 23, 2018
> > http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60
> > /en_31941102v020202p.pdf
> >
> > Peter
> >
> > -Original Message-
> > From: dev-security-policy
> > <dev-security-policy-bounces+peter.miskovic=disig...@lists.mozilla.org
> > > On Behalf Of Wayne Thayer via dev-security-policy
> > Sent: Thursday, May 10, 2018 5:04 PM
> > To: mozilla-dev-security-policy
> > <mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: Policy 2.6 Proposal: Update Minimum Audit Versions
> >
> > After consulting with representatives from WebTrust and ETSI, I
> > propose that we update the minimum required versions of audit criteria
> > in section
> > 3.1.1 as follows:
> >
> > - WebTrust "Principles and Criteria for Certification Authorities -
> > Extended Validation SSL" from 1.4.5 to 1.6.0 or later
> > - “Trust Service Providers practice” in ETSI EN 319 411-1 <3194111>
> from 1.1.1
> > to 1.2 or later
> > - “Trust Service Providers practice” in ETSI EN 319 411-2 <3194112>
> from 2.1.1
> > to
> > 2.2 or later
> >
> > These newer versions were all published last year and should be the
> minimum for audits completed from now on.
> >
> > Please respond with any concerns you have about this update to our root
> store policy.
> >
> > - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

Doug,

On Thu, May 10, 2018 at 10:57 AM Doug Beattie 
wrote:

> Hi Wayne,
>
>
>
> I’m OK with this as long as this permits the password (fully or partially
> generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS
> (a single channel).
>
>
>
This language is not intended to permit both the password and PKCS#12 file
to be transmitted over HTTPS. In an earlier message I said that I'd like to
hear from other CAs who feel that this exception is necessary, but none
have commented. Given the difficultly in carving out an exception limited
to the scenario you described and the [perhaps marginal] increase in
security that this requirement provides even in your scenario, I'm not
inclined to try to accommodate it.

If the proposed language is not clear in stating that the password and
PKCS#12 file cannot both be transmitted over HTTPS, please let me know.

Doug
>
>
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Wednesday, May 9, 2018 11:43 PM
> *To:* Doug Beattie 
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition
> on CA key generation to policy)
>
>
>
>
>
> I think we have settled on the following resolution to this issue:
>
>
>
> Add the following to section 5.2 (Forbidden and Required Practices):
>
>
>
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
>
> anyExtendedKeyUsage.
>
>
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be encrypted and signed; or, MUST have a password that exhibits at
> least 112 bits of entropy, and the password MUST be transferred using a
> different channel than the PKCS#12 file.
>
>
>
> Unless there is further discussion, I will include this language in the
> final version of the policy.
>
>
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Tue, May 15, 2018 at 7:51 AM Doug Beattie 
wrote:

> Wayne,
>
>
>
> This going to require 19 randomly generated Base64 characters and that
> does not include removing common confused characters which will drive up
> the length a bit more, but if this is what the Mozilla risk assessment came
> up with, then we’ll all have to comply.
>
>
As discussed earlier in this thread, 112 bits of entropy is not something
we just made up. It's grounded in guidance from NIST and other industry
bodies.
>

>   I hope there is a sufficiently long time for CAs to change their
> processes and APIs and to roll out updated training and documentation to
> their customers (for this unplanned change).
>
>
>
>
I'll propose January 1, 2019 as the effective date.
>

> Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
> distributed via secure channels, how strong does the password need to be?
>
>
>
>
I think this depends on our threat model, which to be fair is not something
we've defined. If we're only concerned with protecting the delivery of the
PKCS#12 file to the user, then this makes sense. If we're also concerned
with protection of the file while in possession of the user, then a strong
password makes sense regardless of the delivery mechanism.
>

> Doug
>
>
>
>
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Monday, May 14, 2018 4:54 PM
> *To:* Doug Beattie ;
> mozilla-dev-security-policy  >
> *Subject:* Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> CA key generation to policy)
>
>
>
> On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
>
> Or the user could generate the key :-)
>
> >
>
> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assuming we want to
> continue supporting that option).
>
> Perhaps the following language is a workable solution to the first
> objection?
>
>
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be 

Re: question about DNS CAA and S/MIME certificates

[Wayne Thayer via dev-security-policy]

I don't see how this debate is leading us to a solution. Can we just
acknowledge that, prior to this discussion, the implications of CAA for the
issuance of email certificates was not well understood by CAs or domain
name registrants?

I share the desire to have a system that fails closed in the presence of
any CAA record, but that is a challenge as long as ecosystem participants
view CAA as applicable only to server certificates. The sooner we address
this issue, the better.

Mozilla policy isn't a great place to define CAA syntax. The CA/Browser
Forum currently has no jurisdiction over email, so at best could define
syntax to limit CAA scope to server certificates. The scope of the LAMPS
recharter for 6844bis appears too narrow to include this. What is the best
path forward?

- Wayne

On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Blatantly false.  I actually suspect DigiCert might already support CAA
> for email.  I haven’t double-checked.
>
>
>
> -Tim
>
>
>
> The only reason that "CAA is HTTPS-only" today is because CAs are not
> interested in doing the 'right' thing.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

I'm coming to the conclusion that this discussion is about "security
theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there
are gaping holes in the PKCS#12 requirements, the most obvious being that a
CA can just transfer the private key to the user in pem format! Are there
any objections to dropping the PKCS#12 requirements altogether and just
forbidding key generation for TLS certificates as follows?

CAs MUST NOT generate the key pairs for end-entity certificates that have
an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

- Wayne

[1] https://en.wikipedia.org/wiki/Security_theater

On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>
> On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
>
> Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
> distributed via secure channels, how strong does the password need to be?
>
>
>
>
>
> I think this depends on our threat model, which to be fair is not something
> we've defined. If we're only concerned with protecting the delivery of the
> PKCS#12 file to the user, then this makes sense. If we're also concerned
> with protection of the file while in possession of the user, then a strong
> password makes sense regardless of the delivery mechanism.
>
>
> I think once the key material is securely delivered to the user, it is no
> longer under the CA's control and we shouldn't assume that it is. The user
> might change the passphrase of the PKCS#12 file to whatever, or store the
> private key without any encryption.
>
>
> Dimitris.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

InfoCert Acquisition of Camerfirma

[Wayne Thayer via dev-security-policy]

On Thursday, a representative of AC Camerfirma sent an email informing
Mozilla that InfoCert [1] has taken control of Camerfirma. News of the deal
was first published on May 4th. [2]

Section 8.1 of our policy applies here (quoting version 2.6 draft):

If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program. If the entire CA
> operation is not included in the scope of the transaction, issuance is not
> permitted until the discussion has been resolved with a positive conclusion.
>

InfoCert is new to the Mozilla root program, so a public discussion
regarding their admittance to the root program is in order. I have
requested clarification, but my current understanding is that AC
Camerfirma's entire CA operation is part of the transaction. Thus,
according to our new policy, certificate issuance may continue during our
discussion period.

Camerfirma has informed me that they will not be able to answer our
questions until the transaction "has been done in the Spanish government's
public registry", which they expect to take approximately 4 weeks.
Meanwhile, I have created a bug [3] to track this request and have posed a
number of questions to InfoCert.

- Wayne
[1] https://infocert.digital/about-us/
[2]
https://www.corrierecomunicazioni.it/digital-economy/infocert-sbarca-allestero-acquisito-il-51-della-spagnola-camerfirma/
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1463597
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi  wrote:

> Overall, I think this would be good to proceed, but there's certain
> discrepancies called out under Questions that I think should be resolved
> before doing so. I would suggest contacting WISeKey for follow-up on these,
> and not proceed until we've got a satisfactory response. With the upcoming
> CA/Browser Forum F2F, I think that effectively means a delay of
> approximately two weeks, to allow both WISeKey to respond and the community
> (and maintainers) to review for sufficiency. I think that, provided a
> response is provided, than barring any further feedback raising additional
> concerns, proceeding by June 14 would be a reasonable timeframe? Does that
> seem like a reasonable set of expectations and timing?
>
> This sounds reasonable, but I will note that there is no time limit on
public discussions - this one will end after WISeKey has responded to these
questions and sufficient time has passed for any additional concerns to be
raised.

>
> * As noted, the key generation was performed in May, and this audit is a
> period of time audit beginning in September. This does mean that there is a
> gap in the audit coverage - from May through September - that's difficult
> to reason about. Are there any other supporting documents that would help
> assuage these concerns?
>
> I would have expected this new root to be included on WISeKey's next
regular audit statements for the period ending June 2nd 2017, but WISeKey
apparently chooses to perform separate audits (or at least procure separate
audit statements) for each of it's roots. Given these circumstances, I
share Ryan's concerns and would like an explanation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

I have incorporated the final changes from our policy discussions, as well
as some corrections and clarifications that Kathleen and I found during our
review, into the latest draft of the policy:
https://github.com/mozilla/pkipolicy/compare/master...2.6 I would encourage
everyone to review the changes and respond with any comments.

On Fri, May 11, 2018 at 11:11 AM Wayne Thayer  wrote:

> We're concluding discussions on all of the issues identified for version
> 2.6 of the policy [1].
>
> You can find a complete set of changes here:
> https://github.com/mozilla/pkipolicy/compare/master...2.6
>
> Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs
> the current practice is to wait for the next required annual review
> (usually coinciding with their audit) to make CP/CPS changes. Do we want to
> allow that practice to continue, or set a date by which we expect CP/CPSs
> to reflect the new requirements? This was previously discussed [4], with
> the outcome being that we would make these decisions on a case-by-case
> basis.
>
> >
Since there were no comments on the question above, we'll continue with the
status-quo: there will be no defined enforcement date for the CP/CPS
changes required by the 2.6 version of our policy. CAs are expected to
update their CP/CPSs within a reasonable period of time of the 2.6
effective date. I expect the 2.6 effective date to be sometime in June.
>

> - Wayne
>
> [1]
> https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93=label%3A2.6+
> [2]
> https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8
> [3]
> https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ
>
> On Mon, Mar 19, 2018 at 10:15 PM Wayne Thayer  wrote:
>
>> There are 17 proposed changes in total for version 2.6 of the policy, and
>> I'm about to kick off discussions on the first batch. I expect some of
>> these to be straightforward while others will hopefully generate good
>> dialogues. As always, everyone's constructive input is appreciated.
>>
>> Thanks,
>>
>> Wayne
>>
>> On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer 
>> wrote:
>>
>>> I've added the issue of subordinate CA transfers to the list for policy
>>> version 2.6: https://github.com/mozilla/pkipolicy/issues/122
>>>
>>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

Reminder: there is one week left in the discussion period for this
inclusion request.

On Tue, May 1, 2018 at 12:02 PM Wayne Thayer  wrote:

> This request is for inclusion of the OISTE WISeKey Global Root GC CA as
> documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1403591
>
> * BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=8912732
>
> * Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8955363
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8912737
>
> CP/CPS:
> https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf
>
> * This request is to turn on the Websites and Email trust bits. EV
> treatment is not requested.
>
> * EV Policy OIDs: Not EV
>
> * Test Websites
> https://gcvalidssl.hightrusted.com/
> https://gcexpiredssl.hightrusted.com/
> https://gcrevokedssl.hightrusted.com/
>
> * CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl
>
> * OCSP URL: http://ocsp.wisekey.com/
>
> * Audit: Annual audits are performed by AUREN according to the WebTrust
> for CA and BR audit criteria.
> WebTrust:
> https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf
> BR:
> https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf
> EV: Not EV
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for the
> OISTE WISeKey Global Root GC CA inclusion request that are being tracked in
> this bug and have the following comments:
>
> ==Good==
> * This root was created in May of 2017 and the intermediate appears to
> have only signed test certs since then.
> * Problem reporting mechanism is clearly labeled as such in the CPS.
>
> ==Meh==
> * The older OISTE WISeKey Global Root GA CA that is in our program has
> issued a few certs containing linting errors (some are false positives for
> OCSP signing certs):
> https://crt.sh/?caid=15102=cablint,zlint,x509lint=2010-01-01
> Two notable concerns are:
> ** Valid wildcard certificate for a public suffix:
> https://crt.sh/?id=76535370=cablint (BR 3.2.2.6 permits this only if
> “the applicant proves its rightful control of the entire Domain Namespace“)
> ** Valid cert containing a non-printable string in the Subject :
> https://crt.sh/?id=308365498=x509lint,ocsp
> * WISeKey was the subject of one misissuance bug for “invalid dnsNames”
> and “CN not in SAN” errors to which they responded promptly:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1391089
> ** They also failed to respond to a problem report during this
> incident.
> Domain validations procedures are listed in an appendix instead of section
> 3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and
> 3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued
> after August 1st. The reference to 3.2.2.4.1 appears to be a documentation
> error.
> During my initial review, the CPS was missing CAA information and still
> referenced 3-year validity periods. WISeKey quickly made the needed changes
> but indicated that they update their CPS during an annual review rather
> than regularly as new requirements come into effect.
>
> ==Bad==
> Nothing to report
>
> This begins the 3-week comment period for this request [1].
>
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
>
> - Wayne
>
> [1] 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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek 
wrote:

> My only objection is that this will cause key generation to shift to
> partners and
> affiliates, who will almost certainly do an even worse job.
>
> >
This is already a Mozilla requirement [1] - we're just moving it into the
policy document.
>

> If you want to ban key generation by anyone but the end entity, ban key
> generation by anyone but the end entity.
>
> >
We've already debated this [2] and didn't come to that conclusion.
>

> -Tim
>

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Chunghwa Telecom eCA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Chunghwa Telecom eCA as documented in
the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1341604

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8963172

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

* Root Certificate Download URL: http://eca.hinet.net/download/eCA2.cer

* CP/CPS:
** Root CP: http://eca.hinet.net/download/ePKI_CP_v1.5(Eng).pdf
** Root CPS: https://bug1341604.bmoattachments.org/attachment.cgi?id=8961804
** Public (DV, OV) intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961805
** EV intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961812

* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.

* EV Policy OID: 2.23.140.1.1

* Test Websites:
** Valid: https://ev.hinet.net/
** Expired: https://ra.testev.hinet.net/
** Revoked: https://testev.hinet.net/

* CRL URL: http://repository.ev.hinet.net/crl/EVSSL/complete.crl

* OCSP URL: http://ocsp.ev.hinet.net/OCSP/ocsp

* Audit: Annual audits are performed by SunRise CPAs / DFK International
according to the WebTrust for CA, BR, and EV audit criteria.
** WebTrust: https://cert.webtrust.org/SealFile?seal=2306=pdf
** BR: https://cert.webtrust.org/SealFile?seal=2307=pdf
** EV: https://cert.webtrust.org/SealFile?seal=2279=pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Chunghwa Telecom eCA inclusion request that is being tracked in this bug
and have the following comments:

==Good==
* Clean WebTrust & BR audit statements cover periods back to the creation
of this root in 2015.
* The CPSs properly document 825 day maximum validity periods, and change
logs were recently added.

==Meh==
* Both of the domain validation methods that will be deprecated on 1-August
are currently listed as in-use in the root CP/CPS
* CAA Issuer Domain Names are only specified in the root CP, in section
1.3.2.2 rather than 2.2.
* For domain validation, each CPS does not state which subsection of BR
3.2.2.4 it is complying with as recommended by our policy.
* There is, in my opinion, an excessive amount of duplication of
information between the CP and 3 CPSs (over 600 pages in total), making the
review of these docs difficult and tedious.

==Bad==
* A large number of certificates have been misissued from the “Public
Certification Authority - G2” intermediate [4] (recent example: [2]). Many
of these certificates remain valid. Chunghwa Telecom has published a
response to these errors [3] in the inclusion bug. My main concern with the
response is the assertion that some of these are not SSL certificates bound
to follow the BRs because they do not contain the CAB Forum OV OID in the
certificate policies extension. This assertion contradicts section 1.1 of
Mozilla policy.

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

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

- Wayne

[1]
https://crt.sh/?CAID=1770=cablint,zlint,x509lint=2015-01-01
[2] https://crt.sh/?id=290793483=zlint,cablint,x509lint
[3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418
[4] 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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus 
wrote:

> Did we somehow came to a conclusion / agreed wording here? I'm not sure if
> I missed something, but the last email I've received in regards to this
> issue is from mid of May and the last change in
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
> dates to beginning of March. I don't want to make artificial pressure here
> but want to be sure I don't miss something important.
>
> I went ahead with my most recent proposal from 15-March and removed all of
the PKCS#12 language from the proposal:
https://github.com/mozilla/pkipolicy/commit/c56e0fed3d9ada3bba2f466b3ba638dc652b913b

These changes are in the 2.6 branch on GitHub.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Wayne Thayer via dev-security-policy]

On Thu, May 31, 2018 at 8:39 PM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> This is wrong and should be changed to allow all types of legally
> incorporated company names to get certificates. I understand this
> doesn't fit any of the standard company name profiles you've seen but this
> company name can be used in practice  and I can think of many business
> types that would love this type of name.
>
> In my opinion, this is just a rehash of the same debate we've been having
over misleading information in certificates ever since James obtained the
"Identity Verified" EV certificate. The options we have to address this
seem to be:
1. Accept that some entities, based on somewhat arbitrary rules and
decisions, can't get OV or EV certs
2. Accept that the organization information in certificates will sometimes
be misleading or at least uninformative
3. Decide that organization information in certificates is irrelevant and
ignore it, or get rid of it

We currently have chosen "some parts of all of the above" :-)

I am most interested in exploring the first option since that is the
direction CAs are headed with the recent proposal to limit EV certificates
to organizations that have existed for more than 18 months [1]. As long as
anyone can obtain a DV certificate, are restrictions on who can obtain an
OV or EV certificate a problem, and if so, why?

[1] https://cabforum.org/pipermail/validation/2018-May/000882.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Namecheap refused to revoke certificate despite domain owner changed

[Wayne Thayer via dev-security-policy]

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires
> the CA (not some reseller) to revoke the certificate within 24 hours if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, they
> must revoke once made aware of the situation (in this case by you
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. In
practice, I believe that the requirement Jakob quoted is rarely invoked
because (despite the examples), the language is too vague and narrow. It
can also be quite difficult for a CA to verify that the revocation request
is coming from the legitimate domain name registrant [1], making it less
likely the CA will take action.

I've made a couple of attempts to fix this, resulting in the current
language proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or
control for any Fully-Qualified Domain Name or IP address in the
Certificate should not be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke
by proving that they control the domain name using one of the BR 3.2.2.4
methods, but this is a problem because most CAs don't support every domain
validation method and many domains are configured such that some validation
methods can't be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Fwd: Invalid Country Code Issuance

[Wayne Thayer via dev-security-policy]

Forwarding this for Brenda because the list's SPAM filter is preventing her
from posting it:

*From:* Brenda Bernal 
*Date:* June 1, 2018 at 1:33:46 PM PDT
*To:* 
*Subject:* *Invalid Country Code Issuance*

Digicert has posted a bug (below) on our invalid country code issuance.
Wayne requested us to post for forum visibility.



1. How your CA first became aware of the problem (e.g. via a
problem report submitted to your Problem Reporting Mechanism, a
discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal
self-audit), and the time and date.



The Product team discovered on 2018-05-17 that we had certificates in
our system that were issued from two incorrect Country codes, AN and
XK, as they were addressing a revalidation question.



2. A timeline of the actions your CA took in response. A timeline
is a date-and-time-stamped sequence of all relevant events. This may
include events before the incident was reported, such as when a
particular requirement became applicable, or a document changed, or a
bug was introduced, or an audit was done.

2018/05/17  7:30 AM MT - Certificates were discovered via
internal forum discussion

   2018/05/17 4:16 PM MT - Certificates were confirmed by
Engineering Manager with AN and XK country codes

   2018/5/18 5:01 PM MT - 'AN' ISO country code removed from CA

   2018/05/25 1:09 PM MT -'XK' ISO country code removed from CA



3. Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be
considered a pledge to the community; a statement that you have not
requires an explanation.



We have stopped issuing certificates using these country codes at the
CA level through code changes as indicated in 2) above.



4. A summary of the problematic certificates. For each problem:
number of certs, and the date the first and last certs with that
problem were issued.

7 certs associated with AN country code and 10 certs associated with
XK country code

"XK" country code first issued was 2016/12/06 AND last issued was 2018/5/15

"AN" country code first issued was 2015/08/25 AND last issued was 2018/3/13



Here’s the link to the
bug:https://bugzilla.mozilla.org/show_bug.cgi?id=1465600 for the
crt.sh links to the certificates.



5. The complete certificate data for the problematic certificates.
The recommended way to provide this is to ensure each certificate is
logged to CT and then list the fingerprints or crt.sh IDs, either in
the report or as an attached spreadsheet, with one list per distinct
problem.



We will provide when CT logs are updated.



6. Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.



a. There was no product team in 2012 when the Baseline Requirement
requiring the use of ISO country codes was passed. At the time, an
engineer checked the ISO codes, and "AN" was still in transitionary
state, while "XK" was included as a user-assigned value. It wasn't
clear to that engineer, at that time, that it wasn't officially
accepted by the ISO standards, and was allowed in error.  We have
updated our list to exclude user codes.



b. The "AN" country code was a previously admissible country code
by ISO standards. It was removed transitionally on 2011/12/15, which
meant it could be used for 5 years while the new codes were adopted.
However, it wasn't removed from our database as an allowed value in
2016, due to the lack of a product group and oversight. Product
oversight has been established.  We have an amended process in place
to thoroughly review all ballot impact with subsequent baseline
requirement changes that will need to be reflected in software and
operational procedures.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Mon, Jun 25, 2018 at 2:45 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> 7. In my humble opinion, I think that these requirements must be formalized
> > in audit criteria or explicitly in the BR, and not raised "ad hoc". Any
> CA
> > embarking in an inclusion process should know all requirements
> beforehand.
>
>
> But they're already arguably part of the BRs, as I showed, and it's up to
> the relevant groups (WebTrust, ETSI) to ensure that the criteria they adopt
> reflect what browsers expect. As we see with ETSI and ACAB-c, if the
> auditor fails to meet those requirements, it's the auditor that's at fault.
>
> 8.1 is the relevant section of the BRs, and the issue was recently
discussed on this list:
https://groups.google.com/d/msg/mozilla.dev.security.policy/rR9g5BJ6R8E/Gwzqquv6BgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi  escribió:
>
> Hopefully the audit report will be just as boringly positive as usual... :)
>
> I'll come back then in a few weeks, once the audit process is over and we
> get the result.
>
> Thank you Pedro. My understanding, then, is that we will be placing this
inclusion request on hold until we receive the audit report covering the
period beginning on 9-May 2017.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

Jakob,

On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote

>
> However maybe an additional (clarifying or new) requirement set:
>
> I think the existing language in section 5.3.1 covers all of this. If not,
can you point out the gaps so that I can open a new issue?

To be considered as a name constrained SubCA, the SubCA certificate must
> satisfy all of the following:
>
> 1. Specify a specific non-empty list or permitted EKUs, which does not
>   include the value anyExtendedKeyUsage.
>
> 2. Specify name constraints (whitelist-based) for all the name types
>   that can be used with the specified permitted EKUs.  Any EV-capable
>   such SubCA must also specify name constraints for the directory name
>   type.
>
> 3. Each name constraint must permit only names for which the holder of
>   the name constrained CA has been fully vetted as ultimately
>   authoritative.  For example, any DNS names must correspond to domains
>   registered to the holder for a registration period completely
>   overlapping the CA cert validity period.  Any Distinguished name must
>   correspond to the verified real world identity of the holder (for
>   example C=US, O=Google Inc would be a permitted dirname subtree
>   constraint for a subCA issued to the US headquarters of Google Inc.
>   The validation must be done to standards above and beyond the
>   standards required for end entity certific
> ates
> of the types that the
>   SubCA can issue.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the OISTE WISeKey Global Root GC CA as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1403591

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8912732

* Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8955363

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

CP/CPS:
https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf

* This request is to turn on the Websites and Email trust bits. EV
treatment is not requested.

* EV Policy OIDs: Not EV

* Test Websites
https://gcvalidssl.hightrusted.com/
https://gcexpiredssl.hightrusted.com/
https://gcrevokedssl.hightrusted.com/

* CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl

* OCSP URL: http://ocsp.wisekey.com/

* Audit: Annual audits are performed by AUREN according to the WebTrust for
CA and BR audit criteria.
WebTrust:
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf
BR:
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf
EV: Not EV

I’ve reviewed the CPS, BR Self Assessment, and related information for the
OISTE WISeKey Global Root GC CA inclusion request that are being tracked in
this bug and have the following comments:

==Good==
* This root was created in May of 2017 and the intermediate appears to have
only signed test certs since then.
* Problem reporting mechanism is clearly labeled as such in the CPS.

==Meh==
* The older OISTE WISeKey Global Root GA CA that is in our program has
issued a few certs containing linting errors (some are false positives for
OCSP signing certs):
https://crt.sh/?caid=15102=cablint,zlint,x509lint=2010-01-01
Two notable concerns are:
** Valid wildcard certificate for a public suffix:
https://crt.sh/?id=76535370=cablint (BR 3.2.2.6 permits this only if
“the applicant proves its rightful control of the entire Domain Namespace“)
** Valid cert containing a non-printable string in the Subject :
https://crt.sh/?id=308365498=x509lint,ocsp
* WISeKey was the subject of one misissuance bug for “invalid dnsNames” and
“CN not in SAN” errors to which they responded promptly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1391089
** They also failed to respond to a problem report during this incident.
Domain validations procedures are listed in an appendix instead of section
3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and
3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued
after August 1st. The reference to 3.2.2.4.1 appears to be a documentation
error.
During my initial review, the CPS was missing CAA information and still
referenced 3-year validity periods. WISeKey quickly made the needed changes
but indicated that they update their CPS during an annual review rather
than regularly as new requirements come into effect.

==Bad==
Nothing to report

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

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

- Wayne

[1] 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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

Ryan - thanks for raising these issues again. I still have concerns about
getting this specific in the policy, but since we're now headed down that
road...

On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A few problems I see with the proposed text:
>
> - What is sufficient? I would go with a definition tied to the effective
> strength of the keys it protects; in other words, you should protect a
> 2048bit RSA key with something that offers similar properties or that
> 2048bit key does not live up to its 2048 bit properties. This is basically
> the same CSPRNG conversation but it's worth looking at
> https://www.keylength.com/


The latest proposal replaces "sufficient" with "at least 64 bits of output
from a CSPRNG". We could go back to "sufficient strength for the keys it
protects", but that also leaves quite a bit of room for misinterpretation.

Are there objections to "at least 112 bits of output from a CSPRNG" as Tim
proposed?

>
> - The language should recommend that the "password" be a value that is a
> mix of a user-supplied value and the CSPRNG output and that the CA can not
> store the user-supplied value for longer than necessary to create the
> PKCS#12.
>

I'm with Tim on this - it's added complexity for no real added security.

- The strength of the password is discussed but PKCS#12 supports a bunch of
> weak cipher suites and it is common to find them in use in PKCS#12s. The
> minimum should be specified to be what Microsoft supports which is
> pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy
> of certificates it uses pbeWithSHAAnd40BitRC2-CBC.
>

After reading your (Ryan's) blog, I was left with the impression that
Windows only supports the weakest algorithms, so adding this requirement
doesn't mean anything. If that's not correct, can you suggest some language?

- The language requires the use of a password when using PKCS#12s but
> PKCS#12 supports both symmetric and asymmetric key based protection also.
> While these are not broadly supported the text should not prohibit the use
> of stronger mechanisms than 3DES and a password.
>
> Does the following language work? If not, could you suggest something
better?

PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password
containing at least 64 bits of output from a CSPRNG, and the password SHALL
be transferred using a different channel than the PKCS#12 file.


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

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

Unless there is further discussion, I will consider this issue closed with
the following change to section 5.3, meaning that it applies to both
unconstrained and technically constrained intermediates:

Subordinate CA certificates created after January 1, 2019:
* MUST contain an EKU extension; and,
* MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
* MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection
KeyPurposeIds in the same certificate.

- Wayne

On Mon, Apr 30, 2018 at 5:58 PM, pfuentes69--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Maybe I'm too pragmatic, but from a risk management perspective, I don't
> see a constrained CA issuing a poor certificate harming the whole
> CA/Browser community, so I would even accept that risk.
>
> Anyway, as a conclusion, I see your point about this maybe being difficult
> to manage in the real world, so I guess my request to consider the
> exception for name constrained CAs is not as straightforward as it's in my
> head.
>
> Cheers!
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

; the
> > password must be sent via separate channel.
> >
> > 
> > Comments:
> >
> > 1) The discussions to date have not addressed the use of secure channels
> on
> > the quality of the password, nor on the use of multiple channels.  What
> is the
> > intent?  We should specify that so it's clear.
> >
> > 2) I think the use of CSPRNG is overkill for this application.  Can we
> leave this at
> > a certain entropy level?
> >
> > 3) The tamper requirement would only seem applicable if the P12 wasn't
> > protected well (via strong P12 password on USB storage or via "good" PIN
> on a
> > suitably secure crypto token).
> >
> >
> >
> > > -Original Message-
> > >
> > > I would like to suggest to rephrase the central sentence a little bit:
> > >
> > > Original:
> > >
> > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. The PKCS#12 file must have a
> > > sufficiently secure password, and the password must not be transferred
> > together with the file.
> > >
> > > Proposal:
> > >
> > > CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. If the CA chooses to do so, the
> > > PKCS#12 file SHALL have a  password containing at least 32 bit of
> > > output from a CSPRNG, and the password SHALL be transferred using a
> > > different channel as the
> > > PKCS#12 file.
> > >
> > > My proposal would allow a CA to centrally generate a P12 file, send it
> > > to the Subject by unencrypted email and send the P12 pin as a SMS or
> > > Threema message. This is an important use case if you want to have
> > > email encryption on a mobile device that is not managed by a mobile
> device
> > management system.
> > > Additionally I made the wording a little bit more rfc2119-ish and made
> > > clear, what defines a 'sufficiently secure password' as the original
> > > wording lets a lot of room for 'interpretation'.
> > >
> > > What do you think?
> > >
> > > /Rufus
> > >
> > >
> > > Siemens AG
> > > Information Technology
> > > Human Resources
> > > PKI / Trustcenter
> > > GS IT HR 7 4
> > > Hugo-Junkers-Str. 9
> > > 90411 Nuernberg, Germany
> > > Tel.: +49 1522 2894134
> > > mailto:rufus.busch...@siemens.com
> > > www.twitter.com/siemens
> > >
> > > www.siemens.com/ingenuityforlife
> > >
> > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> > > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> > > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> > > offices: Berlin and Munich, Germany; Commercial registries: Berlin
> > > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: dev-security-policy
> > > > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists
> > > > .m ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy
> > > > Gesendet: Freitag, 27. April 2018 19:30
> > > > An: Enrico Entschew
> > > > Cc: mozilla-dev-security-policy
> > > > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key
> > > > generation to policy
> > > >
> > > > On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via
> > > > dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > > I suggest to make the requirement „* The PKCS#12 file must have a
> > > > > sufficiently secure password, and the password must be transferred
> > > > > via a separate channel than the PKCS#12 file.” binding for both
> > > > > transfer methods and not be limited to physical data storage.
> > > > > Otherwise I agree with this proposal.
> > > > >
> > > > > Enrico
> > > > >
> > > > > That seems like a good and reasonable change, resulting in the
> > > > > following
> > > > policy:
> > > >
> > > > CAs MUST NOT generate the key pairs for end-entity certificates that
> > > > have EKU extension containing the KeyPurposeIds id-kp- serverAuth or
> > > anyExtendedKeyUsage.
> > > >
> > > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > > through insecure electronic channels. The PKCS#12 file must have a
> > > > sufficiently secure password, and the password must not be
> > > > transferred together with the file. If a PKCS#12 file is distributed
> > > > via a physical data storage device, then the storage must be
> > > > packaged in a way that the opening of the package causes
> > > > irrecoverable physical damage. (e.g. a security seal)
> > > >
> > > > Unless other comments are made, I'll consider this to be the
> > > > conclusion of
> > > discussion on this topic.
> > > >
> > > > Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

[Wayne Thayer via dev-security-policy]

Seeing no additional comments, I've gone ahead and added this change to the
2.6 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10

- Wayne


On Tue, Apr 24, 2018 at 6:02 PM, Wayne Thayer <wtha...@mozilla.com> wrote:

> On Tue, Apr 24, 2018 at 9:21 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>
>>
>>
>> On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> I'm re-sending this with the subject tagged as a 'policy 2.6 proposal' in
>>> case anyone missed it the first time.
>>>
>>> I am leaning toward option 2 as the best solution. The scope of section 8
>>> could be updated to state the following:
>>>
>>> CAs SHOULD NOT assume that trust is transferable. All CAs whose
>>> certificates are included in Mozilla's root program MUST notify Mozilla
>>> if:
>>>
>>> * ownership or control of the CA’s included certificate(s) changes; or,
>>> * the CA creates an unconstrained intermediate certificate as defined in
>>> section 5.3.2 that is controlled by another organization; or,
>>> * ownership or control of the CA's unconstrained intermediate
>>> certificate(s) changes; or,
>>> * ownership or control of the CA’s operations changes; or,
>>> * there is a material change in the CA's operations.
>>>
>>>
>>> This would then explicitly require CAs who create or transfer an
>>> unconstrained intermediate certificate to a 3rd party to obtain approval
>>> and meet the other requirements outlined in section 8.
>>>
>>> I would appreciate everyone's comments on this proposed change.
>>>
>>
>> Apologies if I'm missing something, but I'm curious how this would cover
>> the case of:
>>
>> Org A - "TSP" operating a singular root certificate in the Mozilla program
>> Org B - "TSP" operating a single signed intermediate from Org A's Root
>> Certificate
>> Org C - "TSP" operating a single signed intermediate from Org B's
>> "Intermediate Certificate"
>> Org D - A new TSP
>>
>> My understanding is that the proposed language would address the
>> situation if Org B transferred control to org D, but I'm struggling to see
>> where/how it would require Org C to be subject to that if they transferred
>> to Org D.
>>
>> Good point. How about combining the two bullets from my earlier proposal
> as follows:
>
> CAs SHOULD NOT assume that trust is transferable. All CAs whose
> certificates are included in Mozilla's root program MUST notify Mozilla if:
>
> * an organization other than the CA obtains control of an unconstrained
> intermediate certificate (as defined in section 5.3.2) that directly or
> transitively chains to the CA's included certificate(s); or,
>
> The ambiguity that I struggle with comes from "control of the CA's" (in
>> the third bullet) that seems subject to "All CAs whose certificates are
>> included in Mozilla's root program" in the intro. It would seem it would
>> only bind the Org A relationship, not Org B's.
>>
>> In this regard, 5.3.2 is slightly less ambiguous, as it governs "All
>> certificates that are capable of being used to issue new certificates, and
>> which directly or transitively chain to a certificate included in Mozilla’s
>> CA Certificate Program,"
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi  wrote:

>
>
> On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer  wrote:
>
>> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:
>>
>>> I'm not sure I underestand the use case. I'm hoping that they can
>>> clarify more.
>>>
>>> Pedro - can you explain more about why this is important?
>>
>> That is, it would seem valuable as part of the technical constraint
>>> exercise to ensure the EKUs are restsricted. This is particularly true due
>>> to how nameConstraints work - they are blacklists (effectively), rather
>>> than whitelists, which means that combined with EKUs, they can be used for
>>> unconstrained purposes.
>>>
>>> Similar to the discussions regarding nameConstraints and name types,
>>> this has the effect of discouraging the introduction of new EKUs, as such
>>> intermediates would be unconstrained for these potential new and novel EKU
>>> use cases.
>>>
>>> Ryan - can you explain this concern in more detail? If, for instance,
>> the srvName type was added for TLS certificates, new intermediates would be
>> required to constrain that name type due to the "fail open" nature of name
>> constraints. If a single intermediate contained both the serverAuth and
>> emailProtection EKUs, how does that make the situation worse? Is it just
>> that now all of the S/MIME certificates issued under the intermediate  must
>> also expire or be replaced so that the old intermediate (without a
>> constraint on srvName) can be revoked?
>>
>
> You're absolutely correct that if an intermediate certificate contains
> serverAuth and emailProtection EKUs, then we are bounded in the types of
> certificates it issues. It is only in the situation where it lacks an EKU,
> or where it's granted the anyExtendedKeyusage EKU, that we're in a
> situation where we're failing "open".
>
> My understanding of the proposal to "make an exception" for
> nameConstrained CAs was to allow any of these - that is, a combination of
> explicit EKUs, lacking an EKU, and an anyEKU. The consequence of this would
> be that the introduction of srvName for TLS, in the case of (lacking an
> EKU, any EKU), would mean that such an intermediate is unconstrained for
> TLS issuance - even if it was only 'intended' for something such as S/MIME
> and smart-card auth.
>
> If the proposal is to allow multiple (explicit) EKUs on an intermediate,
> when the intermediate also has constraints appropriate for each of the
> enumerated EKUs, then I think we're in a better place, although we should
> understand the motivation more :)
>

This proposal wouldn't change the current requirement for technically
constrained intermediates:

For a certificate to be considered technically constrained, the certificate
MUST include an Extended Key Usage (EKU) extension specifying all extended
key usages that the subordinate CA is authorized to issue certificates for.
The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Japan GPKI Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote:
> > This request by the Government of Japan, Ministry of Internal 
> > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' 
> > certificate and enable the Websites trust bit. This new root certificate 
> > has been created in order to comply with the Baseline Requirements, and 
> > will eventually replace the 'ApplicationCA - Japanese Government' root 
> > certificate that was included via Bugzilla Bug #474706. Note that their 
> > currently-included root certificate expires in 2017, and will be removed 
> > via Bugzilla Bug #1268219.
> > 
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=870185
> 
> Thank you to those of you who reviewed and commented on this request from 
> Japan GPKI to include the GPKI 'ApplicationCA2 Root' certificate and enable 
> the Websites trust bit. 
> 
> This discussion is on hold pending completion of the following action items 
> by the CA:
> 
> 1) Update the CP/CPS documents with sufficient detail to describe the 
> policies and procedures that apply to this root cert and all certs that chain 
> to it.
> Note that I added a new section to the Recommended Practices wiki page to 
> provide pointers to previous reviews of CP/CPS documents, so CAs can see both 
> good and not-so-good examples.
> https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
> 
> 2) Provide an updated BR audit statement
> 
> Thanks,
> Kathleen

GPKI recently provided an updated CPS and also has provided a BR audit 
statement. I've reviewed the information provided and have the following 
comments:

== Good ==
* GPKI is requesting a name constraint to go.jp
* Section 1 states that the BRs take precedence over the CPS
* Problem reporting information is published at 
http://www.gpki.go.jp/apca2/index.html

== Meh ==
* Full name of the BRs is cut off in section 1: “CA/Browser  Forum,  Baseline  
Requirements for the Issuance and Management of Publicly.”
* Revision history doesn’t state what was changed (Mozilla policy 3.3 requires 
a “dated changelog” but doesn’t explicitly require a description of changes to 
be included)
* Neither the CPS or the BR Self Assessment explain how GPKI identifies 
high-risk certificate requests
* There are separate CPS’s for the root and it’s subordinate CA. Some of the 
required information (CAA, domain validation methods) is only contained in the 
sub CA’s CPS.
* The CPS doesn’t contain an explicit open-source license statement as 
encouraged by Mozilla policy 3.3(3)
* A minimal description of the methods used by the CA to perform domain 
authorization was added to section 4.1.2. How is method 3.2.2.4.1 used? I don’t 
think enough information is provided to comply with Mozilla policy 2.2(3) that 
states “The CA's CP/CPS must clearly specify the procedure(s) that the CA 
employs”. However, the fact that this CA will be name constrained to go.jp 
reduces my concern over this.
* There are references to the “sterling committee” in the CPS. I believe this 
is meant to translate to “steering committee”.

== Bad ==
* CPS docs are not assigned a version number (Mozilla policy 3.3)
* I can’t find a current WebTrust for CAs audit statement - I've requested a 
translated copy in the bug. There may be confusion over the fact that two 
audits are required.
* The translated WebTrust BR audit report does not include all the information 
required by Mozilla policy 3.1.4. Based on information in the bug I believe 
this meant to be a period-of-time audit, but it looks like a point-in-time 
readiness audit.

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

Re: Mis-Issuance of a SSL multi-domain certificate

[Wayne Thayer via dev-security-policy]

Thank you for reporting this issue. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1428877 to track the issue and
SwissSign's response.

- Wayne

On Mon, Jan 8, 2018 at 5:08 AM, Reinhard Dietrich via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To whom it may concern
>
>
> We have to inform you about a mis-issuance of a SSL multi-domain
> certificate with a wrong SAN entry showing the word “dns” again (no valid
> FQDN). We detected this error this morning based on our now implemented
> cablint based error detection system. The certificate concerned is:
> (https://crt.sh/?id=295437114=cablint)
>
> We are now in the phase of analyzing the underlying cause and will report
> our results in the standard required bug report format
>
> Regards
>
> Reinhard Dietrich, SwissSign
> ___
> 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: Misissued certificate with improper characters in DNSname

[Wayne Thayer via dev-security-policy]

Stephen,

Thanks for the report. I have a few questions:
1. Did you scan for any additional certificates containing this type of
error that Quovadis or your subordinate CAs have issued? What were the
findings?
2. Will the linting check be performed pre- or post-issuance?
3. When will the linting check be in place, and will it cover all
certificates issued under a Quovadis root?

Wayne

On Fri, Dec 22, 2017 at 1:54 PM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Dec 21 at 1715 UST we received a problem report (below) by email to
> complia...@quovadisglobal.com from Alex Gaynor relating to a TLS/SSL
> certificate issued by Swiss Government Public Trust Standard CA 02, a
> technically constrained external CA operated by Bundesamt fuer Informatik
> und Telekommunikation (BIT).
>
> Specifically, a SAN in that certificate included a dNSName that ended with
> two \n characters:
> https://crt.sh/?id=282646337=cablinthttps://crt.sh/?id=
> 282646337=cablint
>
> The certificate was revoked by the CA on Dec 22 at 1125 UST.
>
> Upon investigation, the CA reports that the misissuance was the result of
> administrator error during the manual input of the SAN entry.  The
> misissuance will be reported to the CAs external auditors.  The CA has
> undertaken to add linting as part of the issuance of their TLS/SSL
> certificates.
>
> Thanks to Alex Gaynor for reporting the issue.
>
> Regards,
> Stephen Davidson
> QuoVadis, a WISeKey company
>
> --
>
> From: Alex Gaynor [mailto:agay...@mozilla.com]
> Sent: Thursday, December 21, 2017 1:15 PM
> To: Group - QuoVadis Compliance >
> Subject: Misissued certificate
>
> Hi,
>
> I'm reporting a misissued certificate from one of your sub CAs:
> https://crt.sh/?id=282646337=cablint
>
> Specifically, one of the dNSNames ends with two newline (\n) chracters,
> which are not valid is a DNS label.
>
> I am requesting you revoke this certificate and provide a post-mortem to
> MDSP.
> ___
> 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: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Wayne Thayer via dev-security-policy]

On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > I don't think that's true. If your hosting provider allows other sites
> > to respond to HTTP requests for your domain, there's a similar
> > vulnerability in the HTTP-01 checker. One configuration where this can
> > happen is when multiple sites share an IP but only one gets port 443
> > (i.e. the pre-SNI support situation), and it's not you.
> >
> >
> There's a significant difference here.  At a minimum the original request
> arrives on port 80 and with a proper Host: header identifying the target
> website to be validated.  Yes, it's possible that your host redirects that,
> but presumably you the website at that address have some say or control
> over that.  Furthermore, at a minimum the target being forwarded to still
> has to have knowledge of a calculated challenge value to return to the
> validator which the validator does not reveal in the process of raising the
> question.  A fact which arises from this is that the target was being
> manipulated by the requestor of the validation -- a fact which some modes
> of failure of the TLS-SNI-01 mechanism would not be able to assert.  The
> TLS-SNI-01 validation process never even surfaces to the hosting
> infrastructure just exactly what domain label is being validated.
>
> Although the BRs allow method 6 to be performed over TLS, my understanding
is that Let's Encrypt only supports the HTTP-01 mechanism on port 80 in
order to prevent the exploit that Gerv described. Similarly, my
understanding is that the updated TLS-SNI-02 mechanism prevents the attack
that Matthew described.

>
> > Or, if an email provider allows people to claim any of the special email
> > addresses, there's a similar vulnerability in email-based methods.
> >
>
> Clearly those mechanisms have that well known risk for a very long time
> now.  Certainly, I have no doubt that one can still today bootstrap their
> way to a bad certificate via these mechanisms.  I note  that LetsEncrypt
> and ACME chose to eschew those methods. I admit to merely presuming that
> those chose not to implement, at least in part, due to those risks.
>
>
> > The "don't allow acme.invalid" mitigation is the easiest one to
> > implement, but another perfectly good one would be "don't allow people
> > to deploy certs for sites they don't own or control", or even "don't
> > allow people to deploy certs for sites your other customers own or
> > control". Put that way, that doesn't seem like an unreasonable
> > requirement, does it?
> >
>
> Here again, I think we have a problem.  It's regarded as normal and
> acceptable at many web host infrastructures to pre-stage sites for
> domain-labels not yet in use to allow for development and test deployment.
> Split horizon DNS or other in-browser or /etc/hosts, etc, are utilized to
> direct the "dev and test browser" to the right infrastructure for the
> pending label.  It will be an uphill battle to get arbitrary web hosts to
> implement any one of the mitigations you've set out.  Especially when it
> reduces a functionality some of their clients like and doesn't seem to get
> them any tangible benefit.
>
> I agree with this point. It's common and by design for shared hosting
environments to allow sites to exist without any sort of domain name
validation.


> In the course of adopting the 10 blessed methods, did any of the methods
> move forward with the expectation that active effort on the part of non-CA
> participants versus the status quo would be required in order to ensure the
> continuing reliability of the method?
>

In my opinion, adoption of the 10 blessed methods was only an effort to
document what CAs were already doing in practice so that the catch-all "any
other method" could be removed. There is more work to be done, as can be
seen in the current discussion of method #1 on the CAB Forum Public list.

> ___
> 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: Incident report: Failure to verify authenticity for some partner requests

[Wayne Thayer via dev-security-policy]

Thank you for the report Tim. I just created
https://bugzilla.mozilla.org/show_bug.cgi?id=1429639 to track this issue.
Please follow up in the bug and on this thread.

- Wayne

On Wed, Jan 10, 2018 at 2:24 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> Hi everyone,
>
> There was a bug in our OEM integration that led to a lapse in the
> verification of authenticity of some OV certificate requests coming in
> through the reseller/partner system.
>
> As you know, BR 3.2.5 requires CAs to verify the authenticity of a request
> for an OV certificate through a Reliable Method of Communication (RMOC).
> Email can be a RMOC, but in these cases, the email address was a
> constructed
> email address as in BR 3.2.2.4.4.  Despite the fact that these addresses
> are
> standardized in RFC 2142 or elsewhere, we do not believe this meets the
> standard of "verified using a source other than the Applicant
> Representative."
>
> The issue was discovered by TBS Internet on Dec 30, 2018. Apologies for the
> delay in reporting this. Because of the holidays, it took longer than we
> wanted to collect the data we needed.  We patched the system to prevent
> continued use of constructed emails for authenticity verification early,
> but
> getting the number of impacted orgs took a bit more time. We are using the
> lessons learned to implement changes that will benefit overall user
> security
> as we migrate the legacy Symantec practices and systems to DigiCert.
>
> Here's the incident report:
>
> 1.How your CA first became aware of the problem (e.g. via a problem
> report submitted to your Problem Reporting Mechanism, via a discussion in
> mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> Email from JP at TBS about the issue on Dec 30, 2017.
>
> 2.A timeline of the actions your CA took in response.
>
> A. Dec 30, 2017 - Received report that indirect accounts did not require a
> third-party source for authenticity checks. Constructed emails bled from
> the
> domain verification approval list to the authenticity approval list.
> B. Dec 30, 2017 - Investigation began. Shut off email verification of
> authenticity.
> C. Jan 3, 2017 - Call with JP to investigate what he was seeing and
> confirmed that all indirect accounts were potentially impacted.
> D. Jan 3, 2017 - Fixed issue where constructed emails were showing as a
> permitted address for authenticity verification.
> E. Jan 5, 2017 - Invalidated all indirect order's authenticity checks.
> Started calling on verified numbers to confirm authenticity for impacted
> accounts.
> F. Jan 6, 2017 - Narrowed scope to only identify customers impacted (where
> the validation staff used a constructed email rather than a verified
> number).
> G. Jan 10, 2017 - This disclosure.
>
> Ongoing:
> H. Reverification of all impacted accounts
> I. Training of verification staff on permitted authenticity verification
>
> 3.Confirmation that your CA has stopped issuing TLS/SSL certificates
> with the problem.
>
> Confirmed. Email verification of authenticity remains disabled until we can
> ensure additional safeguards.
>
> 4.A summary of the problematic certificates. For each problem: number
> of
> certs, and the date the first and last certs with that problem were issued.
>
> There are 3,437 orgs impacted, with a total of 5,067 certificates.  The
> certificates were issued between December 1st and December 30th.
>
> 5.The complete certificate data for the problematic certificates. The
> recommended way to provide this is to ensure each certificate is logged to
> CT and then list the fingerprints or crt.sh IDs, either in the report or as
> an attached spreadsheet, with one list per distinct problem.
>
> Will add to CT once we grab it all.  I will provide a list of affected
> certificates in a separate email (it's big, so it was getting this post
> moderated).
>
> 6.Explanation about how and why the mistakes were made or bugs
> introduced, and how they avoided detection until now.
>
> In truth, it comes down to a short timeframe to implement the
> Symantec-DigiCert system integration and properly train everyone we hired.
> We are implementing lessons learned to correct this and improve security
> overall as we migrate legacy Symantec practices and systems to DigiCert. In
> this case, there are mitigating controls.  For example, these are mostly
> existing Symantec certs that are migrating to the DigiCert backend. The
> verification by Symantec previously means that the number of potentially
> problematic certs is pretty low. There's also a mitigating factor that we
> did not use method 1 to confirm domain control. In each case, someone from
> the approved constructed emails had to sign off on the certificate before
> issuance.  This is limited to OV certificates, meaning EV certificates were
> not impacted. Despite the mitigating factors, we believe this is a
> compliance issue, even though we believe the 

Re: 5.3.1 Technically Constrained

[Wayne Thayer via dev-security-policy]

Ben,

I'm about to use the term 'paragraph' to refer to the text within section
5.3.1 that is separated by carriage returns.

The prior version of the policy contained the language in the final
paragraph of section 5.3.1 - see
https://github.com/mozilla/pkipolicy/commit/f96076a01ef10e5d6a84fa4b042227512925cb7c
The language in paragraph 3 and the compliance deadline in paragraph 4 of
section 5.3.1 were added in the latest version of the policy.

I believe this shows that the intent of the conditional statement in the
fourth paragraph of section 5.3.1 is to reference the third paragraph of
section 5.3.1, not to the language in section 5.3. I also think that your
interpretation would allow a CA to neither publicly disclose or technically
constrain a subordinate CA containing the id-kp-emailProtection EKU -
something that was required in the previous version of the policy.

I've added an issue in Github requesting that we clarify this language as
you suggested in the next version of the policy.

- Wayne

On Mon, Jan 8, 2018 at 4:12 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The problem with the wording of the paragraphs in section 5.3.1 is that
> they
> should have said "..., in order to be considered Technically Constrained,
> ..." .  Right now they read like absolutes.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Monday, January 8, 2018 3:42 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: 5.3.1 Technically Constrained
>
> Which "above paragraph" is being referenced in the following excerpt from
> Section 5.3.1 of the Mozilla Root Store Policy v.2.5
> (https://www.mozilla.org/en-US/about/governance/policies/
> security-group/cert
> s/policy/)?
>
>
>
> "Instead of complying with the above paragraph, intermediate certificates
> issued before 22nd June 2017 may, until 15th January 2018, comply with the
> following paragraph:
>
>
>
> If the certificate includes the id-kp-emailProtection extended key usage,
> then all end-entity certificates MUST only include e-mail addresses or
> mailboxes that the issuing CA has confirmed (via technical and/or business
> controls) that the subordinate CA is authorized to use."
>
>
>
> I interpret that "the above paragraph" means the following paragraph:  "5.3
> Intermediate CertificatesAll certificates that are capable of being
> used
> to issue new certificates, and which directly or transitively chain to a
> certificate included in Mozilla's CA Certificate Program, MUST be operated
> in accordance with this policy and MUST either be technically constrained
> or
> be publicly disclosed and audited."
>
>
>
> Thanks,
>
>
>
> Ben Wilson
>
>
>
> Ben Wilson, JD, CISA, CISSP
>
> VP Compliance
>
> +1 801 701 9678
>
>
>
>
>
> ___
> 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

Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

I would like to open a discussion about the criteria by which Mozilla
decides which CAs we should allow to apply for inclusion in our root store.

Section 2.1 of Mozilla’s current Root Store Policy states:

CAs whose certificates are included in Mozilla's root program MUST:
> 1.provide some service relevant to typical users of our software
> products;
>

Further non-normative guidance for which organizations may apply to the CA
program is documented in the ‘Who May Apply’ section of the application
process at https://wiki.mozilla.org/CA/Application_Process . The original
intent of this provision in the policy and the guidance was to discourage a
large number of organizations from applying to the program solely for the
purpose of avoiding the difficulties of distributing private roots for
their own internal use.

Recently, we’ve encountered a number of examples that cause us to question
the usefulness of the currently-vague statement(s) we have that define
which CAs to accept, along a number of different axes:

* Visa is a current program member that has an open request to add another
root. They only issue a relatively small number of certificates per year to
partners and for internal use. They do not offer certificates to the
general public or to anyone with whom they do not have an existing business
relationship.

* Google is also a current program member, admitted via the acquisition of
an existing root, but does not currently, to the best of our knowledge,
meet the existing inclusion criteria, even though it is conceivable that
they would issue certificates to the public in the future.

* There are potential applicants for CA status who deploy a large number of
certificates, but only on their own infrastructure and for their own
domains, albeit that this infrastructure is public-facing rather than
company-internal.

* We have numerous government CAs in the program or in the inclusion
process that only intend to issue certificates to their own institutions.

* We have at least one CA applying for the program that (at least, it has
been reported in the press) is controlled by an entity which may wish to
use it for MITM.

There are many potential options for resolving this issue. Ideally, we
would like to establish some objective criteria that can be measured and
applied fairly. It’s possible that this could require us to define
different categories of CAs, each with different inclusion criteria. Or it
could be that we should remove the existing ‘relevance’ requirement and
inclusion guidelines and accept any applicant who can meet all of our other
requirements.

With this background, I would like to encourage everyone to provide
constructive input on this topic.

Thanks,

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

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

To recap, we've established that this root was first BR audited on 26-April 
2015 and has received clean period-of-time audits over the next two years. 
ComSign has disclosed 36 certificates issued by this root prior to the BR 
point-in-time audit, of which one remains unexpired. This does not meet the 
requirements of BR section 8.1 both because the point-in-time readiness 
assessment was not completed prior to issuing a publicly-trusted certificate, 
and because the first period-of-time audit was not completed within 90 days of 
issuing a publicly-trusted certificate. Mozilla policy, however, does not 
require a root to have maintained BR compliance over its entire lifetime to be 
included in the program. ComSign's current annual WebTrust for CAs and BR 
audits are enough to meet Mozilla's requirements.

The questions I raised have been addressed to my satisfaction. If anyone has 
further concerns, please raise them this week so that we can complete the 
public discussion period for this inclusion request. 

- Wayne

On Sunday, December 24, 2017 at 2:46:03 AM UTC-7, YairE wrote:
> Hi Wayne,
> 
> as requested i added the file with the certificates issued since 26/10/2014 
> until 31/03/2015 to the bug,
> 
> Back then it seems we didn’t have a WebTrust audit (I believe we started in 
> 2015) but only external CPA and governmental audits as are attached already.
> The reason we didn’t have a WebTrust audit is that we were already being 
> audited by other auditors and the external WebTrust auditor was qualified 
> only around that time.

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

Re: Camerfirma's misissued certificate

[Wayne Thayer via dev-security-policy]

Thank you for reporting this misissuance. Since this is a different issue
than described in bug 1390977, I have created a new bug to track this
problem and your response:
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also post your
incident report here.

Also, the crt.sh link above is reporting the following OCSP error for this
certificate: "OCSP response contains bad number of certificates" Please
investigate.

- Wayne


On Wed, Jan 17, 2018 at 9:27 AM, Juan Angel Martin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
>
> I have to inform you about a SSL certificate misissued. OU contains
> non-printable control characters.
>
> https://crt.sh/?id=305441195
>
> It has already been revoked.
>
> Regards
>
> Juan Angel Martin Gomez
> AC Camerfirma
> ___
> 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: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

This root inclusion request is currently in the public discussion phase [1]

After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the 
following comments:

==Good==
1. GRCA has requested that this root be constrained to issuing certificates for 
.tw domains.
2. The BR Self Assessment is very detailed and helpful.

==Meh==
1. This root is intended to replace an older root that has the exact same DN. 
Compatibility concerns were raised but testing performed by GRCA found no 
problems.
2. The CP doesn’t contain the ’dated changelog’ required under Mozilla policy 
section 3.3.
3. The audit reports don’t include the version numbers of CA policy documents 
referenced during the audit.
4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs 
covered by the audit. They are listed in a supplemental statement provided by 
the auditor.
5. The CP/CPS docs are still in RFC 2527 format.
6. It is not clear how the policy for authenticating individual identity 
described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3 
and 3.2.5. Please provide more detail.
7. In September it was reported that GRCA was signing OCSP responses with an 
unconstrained SHA-1 certificate: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been fixed.
8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for 
validating email addresses are not specified in any documents.

==Bad==
1. The application for inclusion states that only the GCA subordinate can issue 
SSL certificates, and this subordinate has its own CPS that lists SSL-specific 
policies such as CAA. The HCA subordinate also has a BR audit, but GRCA has 
stated that it is no longer used to issue SSL certificates. Should the HCA 
subordinate be added to OneCRL along with the other subordinates (XCA, MOICA, 
and MOECACA) that are not BR audited?
2. According to the audit supplement, the MOICA audit report is qualified due 
to ‘one issue related to system access management’, but the actual audit report 
is not written in English. Please describe the issue and how it was resolved.
3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are not 
listed as required by BR section 2.2.
4. GCA CPS section 3.1.12 describes the domain authorization process for SSL 
certificates, but it does not comply with Mozilla policy section 2.2(3).

One of the recent updates to the application process [1] is a 3-week time 
period for public comments. I would like to apply that change to this inclusion 
request. Specifically, if GRCA has sufficiently answered the questions that I 
have raised above, and any other discussion on this list has reached a 
conclusion, then I will plan to close the discussion period on 10-Feb.

- Wayne

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1065896
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Given this discussion, there must be no other CAs using method 9 or 10,
> else they would have come forward by now with disclosures and have
> demonstrated their compliance..  Maybe we need to post this on the CABF
> public list?
>
> Just a reminder that Mozilla policy requires CAs to monitor this list. And
yes I would hope that any other CAs using this method would have disclosed
that fact and their response by now.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

Peter,

On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> What does Mozilla expect to be verified?  We know the 10 methods allow
> issuance where "the applicant has registered the domain(s) referenced in
> the certificate or has been authorized by the domain registrant to act on
> their behalf” is not true.
>
> Will you describe a few examples of this?

I think the next step should be for Mozilla to clearly lay out the
> requirements for CAs and then the validation methods can be compared to see
> if they met the bar.
>
> Are you asking Mozilla to clarify these two potentially contradictory
statements in our policy? Or something more?

Thanks,

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

Re: Google OCSP service down

[Wayne Thayer via dev-security-policy]

On Sun, Jan 21, 2018 at 2:14 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > I think the whole CA incident reporting question has lots of room for
> > improvement. And I think this should be considered in a way that people
> > who are not familiar with the details of the CA ecosystem can
> > successfully report incidents. I.e. saying "you can find all the
> > contact info in our CPS" is not particularly helpful, as nobody outside
> > a small circle of people knows what that is.
>

Even if a relying party looks for the problem reporting mechanism in the
CPS, they are unlikely to find it. The only requirement is "The CA SHALL
publicly disclose the instructions through a readily accessible online
means" in BR 9.4.3. From my observations, many CAs do not place this in
their CPS, and almost none equate the requirement to "easy to find".

> I think if people try the "natural" way of contacting a certificate
> > issuing entity this should lead to a successful outcome. (And that is
> > more or less "This has been issued by X, so I try to contact X".)
>
> The "natural" way is likely to be some generic support email address that
receives thousands of emails a day and is subject to the problems Ryan
describes below. Maintaining a 24-hour response time for any email address
a relying party might find is not compatible with the requirement for a
timely response.

>
> To be honest, I think I find myself agreeing with other CAs when I question
> whether that should be or necessarily is a goal.
>
> If you’ve been on an inbound bug queue for virtually any product
> (particularly popular ones), you will be amazed at the (lack of) quality
> reports. Just search the Mozilla or Chromium bug trackers for “my computer
> has been hacked” to see a variety of bugs from people most likely suffering
> from one or more mental disorders, unfortunately, to see how bad it can be.
>
> Add to that the complexity of PKI, and the contractual obligations of
> responsivess, and t becomes quite different. Talk to existing CAs that
> provided email links to problem reporting mechanisms (prior to Mozilla’s
> requiring they do so) and hear about the spam. I know of problem reports
> from Google to other CAs that have similarly been caught by the spam
> filters designed to ensure high signal.
>
> Combined with the spectrum of technical acumen we see, even here, or
> through contributions from Interested Parties to the CA/Browser Forum, and
> I suspect that highlighting even more the reporting mechanism is to vastly
> increase the noise, rather than the signal, and thus do more harm than
> good.
>
> Normalizing problem reporting - meaning that reporters have to do more work
> to align their reports into actionable data - conversely increases the
> barrier to submission but reduces the barrier to action. Is it an equitable
> tradeoff? It may be.
>
> Something to ponder, however, as easier does not necessarily mean better.
>
> This is a good point, but easier doesn't necessarily mean worse either. I
propose that we add a requirement that makes the reporting mechanism more
consistent and easier to find (e.g. clearly labeled so that a search for
"google CA problem report" gets me there). Allow the reporting mechanism to
be flexible so that a CA can, for example, use a form with a captcha to
collect the report. I don't know if we need to specify "better" by
normalizing the mechanism or information that is gathered, but I'm also not
opposed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Today I noticed the following ComSign response to question 6 [1] in
Mozilla's November 2017 CA Communication:

We are in the process of perfecting our CAA system. As far as I know we do
> not have a devoted mailbox for problem reporting in the root program, the
> mail for that should be mine – ya...@comda.co.il
>

<ya...@comda.co.il>
This first implies that ComSign is not yet performing CAA checking as
required by the BRs effective 8-Sept 2017.

While the BRs do not require problem reports to be accepted via email, they
do require CAs to "publicly disclose the instructions through a readily
accessible online means". The ComSign CPS includes two email addresses:
supp...@comsign.co.il and customer_servi...@comsign.co.il. How has ComSign
met this requirement?

I will leave the discussion period open until ComSign has responded to
these concerns.

- Wayne

[1] https://ccadb-public.secure.force.com/mozillacommunications/
CACommResponsesOnlyReport?CommunicationId=a051J3mogw7=
Q00042,Q00048

On Tue, Jan 16, 2018 at 2:05 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To recap, we've established that this root was first BR audited on
> 26-April 2015 and has received clean period-of-time audits over the next
> two years. ComSign has disclosed 36 certificates issued by this root prior
> to the BR point-in-time audit, of which one remains unexpired. This does
> not meet the requirements of BR section 8.1 both because the point-in-time
> readiness assessment was not completed prior to issuing a publicly-trusted
> certificate, and because the first period-of-time audit was not completed
> within 90 days of issuing a publicly-trusted certificate. Mozilla policy,
> however, does not require a root to have maintained BR compliance over its
> entire lifetime to be included in the program. ComSign's current annual
> WebTrust for CAs and BR audits are enough to meet Mozilla's requirements.
>
> The questions I raised have been addressed to my satisfaction. If anyone
> has further concerns, please raise them this week so that we can complete
> the public discussion period for this inclusion request.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

I want to directly notify all CAs in the Mozilla program of the recently
exposed issues with domain validation methods and of some upcoming
deadlines. A draft is available below and at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

I would appreciate your prompt and constructive feedback on this message -
I'd like to get it sent out this week.

Thanks,

Wayne

===

Dear Certification Authority,

Because 2018 has already generated some important news for Certification
Authorities, we are sending this message to ensure that every CA in the
Mozilla program is aware of the following current events and impending
deadlines:

1. On 9-January, the CA “Let’s Encrypt” disclosed a vulnerability in the
ACME domain validation method known as TLS-SNI-01, which is an
implementation of the more general method described in BR 3.2.2.4.10. [1] A
subsequent vulnerability was disclosed on 11-January affecting the
validation method described in BR 3.2.2.4.9. [2] Mozilla expects all CAs to
be monitoring discussion in the mozilla.dev.security.policy forum and for
any CA that employs either of these methods to disclose that fact on the
list. From now on, Mozilla expects that CAs will not use these methods
unless they have implemented and disclosed a mitigation for the
vulnerabilities that have been discovered.

2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] If your CA uses either of these methods, please evaluate
your implementation for vulnerabilities and be prepared to discontinue
their use prior to the deadline if ballot 218 succeeds.

3. Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 [5]
require CAs to publicly disclose (via CCADB [6]) all subordinate CA
certificates including those used to issue email S/MIME certificates by
15-January unless they are technically constrained to a whitelist of
domains. We have since changed the compliance deadline to 15-April 2018.
Certificate monitors have detected over 200 certificates that currently do
not comply with this new policy. [7] Please ensure that your CA is in
compliance before 15-April 2018.

4. In our November 2017 CA Communication [8], Mozilla asked all CAs with
roots enabled for websites (SSL) to complete a BR self-assessment [9] by
31-January and send it to Kathleen. If you have not yet done so, please
complete this work. If you requested an extension, your deadline is
15-April 2018.

5. If you are one of the CAs that indicated in your response to the
November 2017 CA Communication that you need more time to update your CPS
to comply with version 2.5 of the Mozilla Root Store Policy, please
complete the updates no later than 15-April 2018. Mozilla feels that four
months is more than long enough to make a CPS change.

6. On 17-March 2017, in ballot 193, the CA/Browser Forum set a deadline of
1-March 2018 after which newly-issued SSL certificates must not have a
validity period greater than 825 days, and the re-use of validation
information must be limited to 825 days. As with all other baseline
requirements, Mozilla expects all CAs in the program to comply.

Participation in Mozilla's CA Certificate Program is at our sole
discretion, and we will take whatever steps are necessary to keep our users
safe. Nevertheless, we believe that the best approach to safeguard that
security is to work with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to improve. Thank you
for your cooperation in this pursuit.

Regards,
Wayne Thayer
Mozilla CA Program Manager

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ
[2]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU
[3] https://cabforum.org/pipermail/public/2017-December/012630.html
[4] https://cabforum.org/pipermail/public/2018-January/012819.html
[5]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[6] http://ccadb.org/cas/intermediates
[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/sKhPTsIYNqs/Q-_ZKmDVAQAJ
[8]
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
[9] https://wiki.mozilla.org/CA/BR_Self-Assessment
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi  wrote:

> This seems to be a perennial problem with CAs, and doesn't inspire
> confidence in them or their operations. I am also concerned that an
> extension of this nature does not inspire confidence in the Mozilla Root
> Program, either as relying parties (CAs that are not competent are allowed
> to continue to be incompetent) or for competent CAs (Mozilla's
> requests/requirements are not actual requirements, but merely suggestions)
>
> I have to agree with this sentiment. However, in this particular case I
suspect many CAs were unaware of the compliance date (as was I).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

To the best of my knowledge, the only "standard" sanction we have today is
complete distrust of a root or intermediate, and in practice that rarely
happens. On the surface, the idea of lesser sanctions like removing the EV
indicator for some period of time is appealing to me, but I think we need
to take a step back and discuss whether or not this is really a good idea.
Would Mozilla be better off in the long run having lesser sanctions readily
at our disposal?

First off, I question if we would really use lesser sanctions more often. I
think we would still want to coordinate their implementation with other
user agents, and that is a tedious process.

Second, what might be the unintended consequences? For example, would CAs
shift their focus from maintaining trust to avoiding sanctions?

- Wayne

On Wed, Jan 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:

> I didn't say it was easy, and I don't disagree that there are ways in
> which it can be improved (e.g. to include server side checks). However,
> there are some inescapable limitations in such approaches (e.g. users who
> cannot contact the Mozilla servers that govern such flags), thus there's
> always some code change necessary to ensure both a sane/predictable default
> (in the event of persistent DoS to an update server) and a configurable
> flag for that which matters.
>
> On Wed, Jan 24, 2018 at 9:24 AM, James Burton  wrote:
>
>> There is no easy way to temporary sanction non-compliant CAs
>> for lateness of documents, incidents and etc.
>> There needs to be a switch developed which allows program members to
>> disable features such as EV without messing around in code.
>>
>> James
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg <jonat...@titanous.com>
wrote:

>
> > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > 2. On 19-December, significant concerns were raised about the reliability
> > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
> > [3] Since then, discussions on the CA/Browser Forum Public list have
> > resulted in a proposed ballot to prohibit the use of these methods after
> > 1-August 2018. [4] If your CA uses either of these methods, please
> evaluate
> > your implementation for vulnerabilities and be prepared to discontinue
> > their use prior to the deadline if ballot 218 succeeds.
>
> Is there a reason to make this deprecation conditional on the ballot?
> Given what we know about how the vulnerable methods are used in the wild,
> they have the same level of brokenness as TLS-SNI-01/02 and it’s not clear
> how evaluating for vulnerabilities would fix anything.


This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

August is a long time from now, and even that date would be conditional on
> the ballot.
>

We could still choose to set that date in our own policy if the ballot were
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists. I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

>
> I strongly believe that requiring CAs to disclose their use of these
> methods immediately, and setting a date not more than a couple months from
> now where these methods and previous validations using them must not be
> used would be the correct choice to protect Mozilla’s users.
>
> Jonathan


[1] https://github.com/mozilla/pkipolicy/issues/116
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Based on the feedback we've received, but sticking with the original intent
of this communication, I have converted it into a survey. You can find a
draft at:

https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

I would appreciate your comments on this. I have set the deadline for
responses to 9-Feb, making the assumption that we can send this out on
Monday.

Thanks,

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

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek 
wrote:

> I support "encouraging" those who are currently using the public web PKI
> for
> internal uses to move to their own private PKIs.  The current situation is
> an
> artifact of the old notion that there should be a global "One CA List to
> Rule
> Them All" owned by the operating system, and everyone should use that.
> That notion is a bit antiquated, in my mind.  Applications and components
> that need a trust list really need to carefully select (or create!) an
> appropriate
> one instead of just grabbing the most convenient one.
>
> I think this is a vote for the status quo, in which we have been accepting
CAs that don't meet the guidance provided under 'who may apply'

I'm familiar with a few efforts in the financial space to transition away
> from
> browser trust lists for non-browser TLS, but as you can imagine, that's
> not a
> trivial effort and will take some time.  My only request would be that if
> the
> rules are going to change, that large companies and entire industries that
> may be affected be given enough notice to be able to come up with
> reasonable transition plans.
>
> Point taken. My immediate concern is for new applications, not with
existing CAs.

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

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor  wrote:

> Hi Wayne,
>
> After some time thinking about it, I struggled to articulate what the
> right rules for inclusion were.
>
> Yes, that is the challenge.

So I decided to approach this from a different perspective: which is that I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing the
> Internet as a global public resource.
>
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the public
> internet struggle with compliance.
>
> Can we separate the ongoing work we need to do to improve the ecosystem
from a decision on root inclusion criteria? Or are you saying that we need
to set new requirements like these as a condition for changing the root
inclusion criteria?

In summary, I think we should focus less on the questions of whether a CA
> is "appropriate" or "deserving" of participation in the Mozilla Root
> Program, and more on whether they are willing and able to fulfill the
> expectations of them as a steward of global trust on the internet. This has
> the nice benefit of aligning well with Mozilla's mission to ensure the
> internet is a global public resource, open and accessible to all.
>
> With this approach we would welcome any CA that can meet the program's
requirements, regardless of the intended use of their certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/2018 23:03, Jonathan Rudenberg wrote:
>
> You seem to be stuck inside some kind of ivory tower world where
> computers are king and everything is done by robots.
>
> This is an interesting debate, but I don't think it's getting us any
closer to answering the question at hand.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote:

>
>
> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Is there a reason to make this deprecation conditional on the ballot?
>> > Given what we know about how the vulnerable methods are used in the
>> wild,
>> > they have the same level of brokenness as TLS-SNI-01/02 and it’s not
>> clear
>> > how evaluating for vulnerabilities would fix anything.
>>
>>
>> This is a matter of timing. When possible, we should give the CA/Browser
>> Forum time to act before Mozilla does so unilaterally. Also, changing our
>> own policy is a process that would need to happen before we send this
>> communication. I have already suggested the Mozilla policy change [1].
>>
>
> Why is this?
>
> Mozilla unilaterally acted with the 10 Blessed Methods in order to
> mitigate security risks, after the Forum kept postponing.
>

Yes, *after the Forum kept postponing*.

Google and Microsoft (and later Mozilla) unilaterally acted with the
> deprecation of SHA-1.
>

My recollection is that Microsoft acted after first raising the issue with
the Forum and getting nowhere. So I believe that both of your examples
support my statement.

>
> The CA/Browser Forum consensus process does not produce results aligned
> with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
> process where 2/3 of CAs have agreed to do something. This naturally
> creates a situation of regulatory capture unaligned with the interests of
> or security of Mozilla users.
>
> There's two parts to the question at play here:
> 1) Does Mozilla believe the ballot is likely to pass the Forum, given a
> number of CA's stated opposition?
>

I can't answer that, but it does appear logical that the ballot is less
likely to succeed with a March deadline.


> 2) Does Mozilla believe August is an appropriate time to cease the
> practice, given the risks?
>

I don't know if there is consensus on this, but it is now clear to me that
at least some members of our community believe that August is not
appropriate.

  - Similarly, is Mozilla comfortable with accepting certificates using
> methods with disclosed vulnerabilities between now and that time, and that
> CAs sufficiently understand said vulnerabilities and have devised (but
> seemingly not yet disclosed) appropriate mitigations or controls?
>
>
Based on the feedback we've seen on this list, I'm going to say no, this is
a risk we're not comfortable with.


> We could still choose to set that date in our own policy if the ballot were
>> to fail. The reasoning behind that date has been discussed on the
>> CA/Browser Forum lists.
>
>
> Are you talking the public list, or some other list, such as the
> Validation WG list? As a co-endorser of the Ballot, in its current form of
> August, it was presented that unless we agreed to endorse at August, it was
> not worth putting forward. One reason privately put forward as to why
> August was because "other user agents" would vote against it unless it was
> August. Is Mozilla such a User Agent?
>
> I expressed my concerns about a Mar 1 deadline on a Validation WG call and
then reiterated them on the Public list: https://cabforum.org/
pipermail/public/2018-January/012713.html I don't think that message
suggests Mozilla would vote against an earlier deadline, and I can't say if
Mozilla would or not. Conversely, your endorsement of the ballot certainly
made me think that Google supported the August deadline.


> I'm not yet aware of conversation that speaks to the volume of its usage
> (those questions have gone unanswered) or to the challenges in migrating to
> an alternative method (such as .2 or .3), which are still remarkably
> flexible and, indeed, mitigations for the risk of .1 inevitably come back
> to being .2 or .3 methods.
>
>
>> I would summarize the argument as (1) a number of
>> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
>> agreed that 6 months was enough time to migrate away from it.
>>
>
> I've not seen any CA publicly state that 6 months was sufficient time. Was
> this on the Validation list?
>

Yes - https://cabforum.org/pipermail/validation/2018-January/000703.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an
explanation of the new method 12 is too much detail for this message, and
it can be found in the ballot that I've referenced.

In order to move ahead with this communication to CAs while our timeline
for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed,
I'd like to propose modifying item #2 as follows:

2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] Rather than accept the risk of continued use of these
methods, Mozilla may decide to set an earlier deadline such as 1-March
2018. If your CA uses either of these methods, please evaluate your
implementation for vulnerabilities, follow the discussion closely, and be
prepared to quickly discontinue your use of these methods of domain
validation.

Please comment on this change.

Thanks,

Wayne

On Wed, Jan 24, 2018 at 5:09 PM, Wayne Thayer <wtha...@mozilla.com> wrote:

> On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> > Is there a reason to make this deprecation conditional on the ballot?
>>> > Given what we know about how the vulnerable methods are used in the
>>> wild,
>>> > they have the same level of brokenness as TLS-SNI-01/02 and it’s not
>>> clear
>>> > how evaluating for vulnerabilities would fix anything.
>>>
>>>
>>> This is a matter of timing. When possible, we should give the CA/Browser
>>> Forum time to act before Mozilla does so unilaterally. Also, changing our
>>> own policy is a process that would need to happen before we send this
>>> communication. I have already suggested the Mozilla policy change [1].
>>>
>>
>> Why is this?
>>
>> Mozilla unilaterally acted with the 10 Blessed Methods in order to
>> mitigate security risks, after the Forum kept postponing.
>>
>
> Yes, *after the Forum kept postponing*.
>
> Google and Microsoft (and later Mozilla) unilaterally acted with the
>> deprecation of SHA-1.
>>
>
> My recollection is that Microsoft acted after first raising the issue with
> the Forum and getting nowhere. So I believe that both of your examples
> support my statement.
>
>>
>> The CA/Browser Forum consensus process does not produce results aligned
>> with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
>> process where 2/3 of CAs have agreed to do something. This naturally
>> creates a situation of regulatory capture unaligned with the interests of
>> or security of Mozilla users.
>>
>> There's two parts to the question at play here:
>> 1) Does Mozilla believe the ballot is likely to pass the Forum, given a
>> number of CA's stated opposition?
>>
>
> I can't answer that, but it does appear logical that the ballot is less
> likely to succeed with a March deadline.
>
>
>> 2) Does Mozilla believe August is an appropriate time to cease the
>> practice, given the risks?
>>
>
> I don't know if there is consensus on this, but it is now clear to me that
> at least some members of our community believe that August is not
> appropriate.
>
>   - Similarly, is Mozilla comfortable with accepting certificates using
>> methods with disclosed vulnerabilities between now and that time, and that
>> CAs sufficiently understand said vulnerabilities and have devised (but
>> seemingly not yet disclosed) appropriate mitigations or controls?
>>
>>
> Based on the feedback we've seen on this list, I'm going to say no, this
> is a risk we're not comfortable with.
>
>
>> We could still choose to set that date in our own policy if the ballot
>>> were
>>> to fail. The reasoning behind that date has been discussed on the
>>> CA/Browser Forum lists.
>>
>>
>> Are you talking the public list, or some other list, such as the
>> Validation WG list? As a co-endorser of the Ballot, in its current form of
>> August, it was presented that unless we agreed to endorse at August, it was
>> not worth putting forward. One reason privately put forward as to why
>> August was because "other user agents" would vote against it unless it was
>> August. Is Mozilla such a User Agent?
>>
>> I expressed my concerns about a Mar 1 deadline on a Valida

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg 
wrote:

> This is a great improvement. I think we should also ask that any CAs using
> these methods immediate disclose that they are and the procedures they are
> using, as well as the date they expect to complete a review of their
> implementation, and then provide the review when it is complete.


The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we reviewed
our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?

If we want to hold CAs accountable for this disclosure, we'll need to turn
this communication into a survey and give CAs a certain amount of time to
respond, so we won't have answers for weeks.

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

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

In the past, new policy versions have not had a clearly defined future
effective date. That seems to have led some CAs to interpret the timing for
making changes to be "whenever we get around to it" instead of the intent
of "the policy is effective immediately and we expect you to comply with it
as soon as possible". Given this abuse, I'd prefer to put a date on each
new version of the policy by which CAs are expected to comply with it. This
date would be 2-3 months after the policy was announced, but would also
allow specific carve-outs for changes that take longer.

- Wayne

On Wed, Jan 24, 2018 at 3:01 AM, Gervase Markham  wrote:

> On 24/01/18 00:47, Wayne Thayer wrote:
> > more frequently when requirements change. I propose that we require CAs
> to
> > update their CPS to comply with version 2.5 of the Mozilla root store
> > policy no later than 15-April 2018.
>
> I think we should have a more general stipulation that Mozilla does not
> consider it reasonable to take more than N months to make an update to a
> CPS, with N being a number like 3 or 2.
>
> Now, a particular change my require code changes as well, and the CPS
> may only be updated when those are made, and that might take longer -
> that's fine. But if the requirement is e.g. "add some extra contact
> information", that's not fine. CAs should not be in the habit of having
> processes where their CPSes are only updated yearly.
>
> Gerv
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham  wrote:

> We do actually do that, it's just not written in the policy itself. See:
> https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
> which gives all the publication dates and compliance dates.
>
> Good. Then all I'm suggesting is that we add the compliance date to the
policy and related communications.

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

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Thanks Jakob. I updated the draft as described below.

On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I think a number of the questions/actions need additional options:
>
> For ACTION 1:
>
> (These 3 are between the 1st and second current option).
>
> Add Option: Our CPS permits these methods, but we have already stopped
>   exercising that permission, and any certificates so issued are no
>   longer valid (expired or revoked).
>
> Add Option: We previously used these methods, but have already suspended
>   doing so, We have reviewed our past implementation for vulnerabilities
>   and have reported our findings below.
>
> Add option: We previously used these methods, but have already suspended
>   doing so, We will review our past implementation for vulnerabilities
>   and report our findings on the mozilla.dev.security.policy list by the
>   date specified in the comments section below.
>
> I don't think many CAs are using these methods, so I simplified your
suggestion by changing option 3 to "Other (please describe below)"

>
> For ACTION 2:
>
> Add option: Our CPS permits these methods, but we only use them in a way
>   that already complies with the proposed method 12 in CAB/F ballot 218.
>
> Added.

Plus the 3 extra options from ACTION 1
>
> I again tried to simplify your suggestion by changing the existing choices
to cover these cases.


> For ACTION 4:
>
> Split the second item into:
>
> Option: We intend to deliver our BR Self Assessment prior to 31-january
>   2018
>
> Option: We previously requested an extension and intend to deliver our
>   BR Self Assessment prior to 15-April 2018.
>
> Done.

For ACTION 5:
>
> Split the or clause into two options (formatting error)
>
> Fixed.

For ACTION 6:
>
> Split into 3 options
>
> Option: We have never issued SSL certificates with a validity period
>   greater than 825 days, and will not do so in the future.
>
> Option: We will stop issueing SSL certificates with a validity period
>   greater than 825 days on or before 1-March 2018
>
> Option: We will stop issueing SSL certificates with a validity period
>   greater than 825 days on or before 1-March 2018.  Some certificates
>   issued before 1-March 2018 have a not-before date after 28-Feb 2018
>   and more than 825 days before their not-after date.  (But not-after is
>   still less than the previously permitted maximum time after the date
>   of issuance).
>
> (That 3rd option would apply, at least, to GlobalSign according to
> another thread).
>
> I rejected this change because it was determined that GlobalSign didn't
break any rules or find a loophole that bypasses the new 825-day
requirement, and the intent of this action is not to discover which CAs
have been issuing 3-year certs.

>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Wayne Thayer via dev-security-policy]

Doug,

I have some questions:

>
> c.The hosting company must allow you to manually create and upload
> a CSR for a site you don’t own
>
> Did you mean to say 'certificate' here instead of 'CSR'?

d.   The user must be able to trick the hosting provider to enable SNI
> for this domain and link it to the certificate they uploaded
>
> Is 'trick' the right term here? Isn't this just a default configuration
for vulnerable hosting providers?

While the vulnerabilities and risks are different between ACME TLS-SNI-01
> and OneClick,


Can you explain this statement? My impression is that the same
vulnerability affects both methods.

we’d like to propose a risk mitigation approach similar to Let’s Encrypt
> with the use of a whitelist.  We’ll verify that certain providers have
> secure practices in place to prevent users from requesting certificates
> outside of their permitted domains and then whitelist them.
>
> Let's Encrypt  has stated that this is a short- to medium-term mitigation.
Is your plan to continue to use this method indefinitely? Or are you
ultimately planning to fix or deprecate the method?

If this is acceptable, we’d like to resume issuance today if possible.
>
> If my understanding of the 3.2.2.4.9 vulnerability being essentially the
same as the 3.2.2.4.10 vulnerability, then this seems reasonable to me, at
least in the short term.

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

Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote:
> On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
> > All, 
> > 
> > I requested that this CA perform a BR Self Assessment, and they have 
> > attached their completed BR Self Assessment to the bug here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> > 
> > Aaron has reviewed and verified the BR Self Assessment.
> > 
> > Therefore, I plan to approve this request from the Government of Taiwan 
> > (GRCA) to include their "Government Root Certification Authority" root 
> > certificate, and turn on the Websites and Email trust bits, and constrain 
> > this root to *.tw. 
> > 
> > If there are no further concerns, then I will close this discussion and 
> > recommend approval in the bug.
> > 
> 
> After further consideration, I have decided to wait for the CA to provide 
> their updated CP/CPS that will address all of the shortcomings that they 
> noted in their BR Self Assessment that they plan to fix in the next version 
> of their CP/CPS.
> 
> So, this discussion will be on hold again until I have received and reviewed 
> their updated CP/CPS documents.

We have received the updated CP/CPS and have received and verified the most 
recent audits for this CA. Since we haven't yet implemented the changes to our 
inclusion process proposed by Kathleen a few days ago, I am now restarting 
discussion on this request, and I will post my comments once the CP/CPS review 
is completed.

I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to OneCRL 
because they are neither technically constrained or BR audited.

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Wayne Thayer via dev-security-policy]

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie 
wrote:

>
>
> Normally a web hosting provider should not let you set SNI for a domain
> someone else is using, especially on that IP address.  I think this is
> where method 9 deviates from method 10.
>
>
>
I agree, it seems somewhat less likely that a hosting provider would allow
someone to create a site for abc.example.com if one already exists on the
same server. Are you aware of any hosting providers that do allow this?
Also, did you consider wildcard DNS records in your analysis of the
vulnerability? (see below)

For method 10, you set up SNI on your server and add the acme.invalid
> string associated with your request/cert.  Since nobody owns that invalid
> domain, the provider probably doesn’t care that you set up that SNI name
> and are using a certificate for that fqdn on their shared IP address.
>
>
>
It's also possible that the only thing the hosting provider checks is if
there is already an SNI entry for that FQDN, in which case sites that
aren't configured for TLS would be vulnerable.

For method 10 we look explicitly for the FQDN in the cert and there is no
> special SNI reconfiguration required (the site is there before, during and
> after the validation and issuance).
>

Are you confusing method 9 and method 10 in this sentence and the one
below?

  Do hosting providers allow you to set SNI for domains you don’t own on a
> shared IP addresses?
>

I think that is exactly what has been found to be true.

  That sounds bad, but I defer to the experts here.  Method 9 does not
> require that.
>
>
>


> Also, the ACME client actively support the process of allowing this random
> acme.invalid value to be tied to the real FQDN and looks for requests based
> on that SNI name.  All of the OneClick plugins (which btw, support similar
> features like client like key generation, cert installation and apache
> configuration), require that the FQDN being validated match the value in
> the certificate and the SNI server name.  Validation will fail when the SNI
> does not match what is expected.  The vast majority of OneClick endpoints
> are not vulnerable (yes, bad guys can modify the plugins and subvert the
> security we built in).  Yes, there is a vulnerability, but I think it’s a
> smaller scale than what’s in TLS-SNI-01.
>
>
>
Do you perform wildcard certificate validation with this method? If so,
could someone create a site for evil.example.com on the same server as
www.example.com and then get a cert for *.example.com by relying on a
wildcard DNS record in the example.com zone (i.e. DNS responds to a query
for evil.example.com with the IP for www.example.com)?

>
>
> While the vulnerabilities and risks are different between ACME TLS-SNI-01
> and OneClick,
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Wayne Thayer via dev-security-policy]

On Thu, Jan 11, 2018 at 3:28 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> https://community.letsencrypt.org/t/2018-01-11-update-regard
> ing-acme-tls-sni-and-shared-hosting-infrastructure/50188
>
> Speaking for myself, this is an excellent game plan that prioritizes the
protection of Mozilla users and the Web PKI in general.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

Thanks for pointing this out Ryan and Dimitris. You are both correct: we
should direct Taiwan GRCA to change their request from including the root
to including only the subordinate CAs that comply with the Mozilla policy.
The option of adding the non-compliant subordinate CAs to OneCRL does not
meet our policy.

I will determine what additional information we need to change this
inclusion request and will add it to bug 1065896. I then expect to place
this request on hold until we receive the updated information.


- Wayne

On Sun, Jan 28, 2018 at 10:53 PM, Dimitris Zacharopoulos 
wrote:

>
>
> On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
>
> Has any consideration been given to adopt a similar policy as discussed
> with the Government of Korea application 
> -https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38
>
>
>
> Just to avoid any possible mis-reading of:
>
> "If you have intermediates for which you cannot disclose, whether it be for 
> personal, operational, or legal reasons, then an appropriate solution, 
> consistent with Mozilla CA Certificate Policy, is to use Technically 
> Constrained Subordinate CAs - as defined within the Baseline Requirements and 
> as reflected within the Mozilla policy. Such TCSCAs are technically limited 
> from the issuance of TLS certificates, and by doing so, are allowed to be 
> operated in a way that is not consistent with the Baseline Requirements nor 
> compliant with Mozilla Policy."
>
>
> Currently, the Baseline Requirements (section 7.1.5) allow for TCSCAs to
> issue TLS Certificates, by requiring the nameConstraints extension,
> limiting the issuance to specific Domain Names and Organizations. These
> TCSCAs MUST follow the Baseline Requirements, with the exceptions provided
> for these types of TCSCAs.
>
> As far as the Mozilla Policy is concerned, if a TCSCAs is technically
> capable of issuing a Certificate for TLS authentication or S/MIME, it MUST
> comply with the Mozilla policy, with the exceptions provided for TCSCAs.
> Section 1.1 of the Mozilla Policy is fairly clear on the scope of the
> policy. If there are possibly more exceptions, it should probably be
> updated to reflect these cases.
>
>
> Dimitris.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.

Thanks to everyone who contributed to this effort.

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

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

The email has been sent, and we've published a blog post:

https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/

On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote:
> You can find a link to the final version of the survey at
> https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
> 
> We're planning to send this out to all CAs in the Mozilla program later
> today. The deadline for responses has been set to 9-February.
> 
> Thanks to everyone who contributed to this effort.
> 
> - Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 18/01/18 14:24, Ryan Sleevi wrote:
> > Isn't this effectively the VISA situation? When were their first audits -
> > late 2016 / early 2017?
>
> I'm not certain; I'll ask Kathleen.
>
> Visa's first BR audit was a PITRA dated 31 March 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

I would like to thank everyone for your constructive input on this topic.
At the outset I stated a desire to ‘establish some objective criteria that
can be measured and applied fairly’. While some suggestions have been made,
no clear set of criteria has emerged. At the same time, we’ve heard the
argument that our time would be better spent on raising the bar for all CAs
in the program, regardless of their subjective value to typical users of
our products.

Some thought was also given to applying unique technical criteria to new
CAs, such as limiting certificate lifetime to 90 days or requiring ACME
support. It was pointed out, however, that this favors incumbents and
doesn’t drive improvement in the overall ecosystem.

The conclusion from this discussion is that we will not attempt to restrict
organizations from participating in the Mozilla CA program based on a
judgement of their value to our users. We will continue to require
applicants to demonstrate compliance with our policies, and reserve the
right to deny membership to any CA at our discretion, e.g. because they
have a documented pattern of misbehavior or we believe they intend to
violate our policies.

Here is a proposed update to the Mozilla Root Store Policy reflecting this
decision:

https://github.com/mozilla/pkipolicy/compare/master...inclusion-criteria?quick_pull=1

As always, comments are welcome. I intend to begin a discussion of the next
version of the policy soon and will plan to include this change in it.


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

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Yair,

Will you please provide a detailed response to each of Ryan's points? Also,
please provide the specific version of the RSA Certificate Manager in use
by ComSign.

Thanks,

Wayne

On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan,
>
> I noticed that your notes refer to a previous version of the CPS and not
> the current one
> here is a link to the current version which is 4.1.
> https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf
>
> About the CA software – we are now under auditing for our new Microsoft CA
> and it will take at least 4-6 months until it will be approved for full
> usage.
> We do understand that the Microsoft CA is much better and secure but we
> still ask of you to approve our root considering the fact we are at the
> last steps of implementing the Microsoft CA
> We are under heavy pressure from customers that are using Mozilla to allow
> them SSL and we were waiting too much until we reached this point
> Even if we receive that you acknowledged for 6 month to continue the
> current CA – it is good for us.
>
> Yair
> ___
> 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: Certificates with 2008 Debian weak key bug

[Wayne Thayer via dev-security-policy]

On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I logged two of those five certificates (https://crt.sh/?id=308392091
> and https://crt.sh/?id=307753186) to Argon, as part of a project to
> log every certificate in the censys.io database to a public CT log. I
> believe Censys found them by scanning all of IPv4 and grabbing the
> default (i.e. no SNI) certificate presented on port 443.
>
> Given that this method will not uncover every certificate ever issued,
> and that Certum isn't or wasn't checking for weak keys and isn't
> logging certificates to CT, should Mozilla ask Certum to scan every
> currently-valid certificate they have issued for weak keys?
>
> Thanks for pointing this out Alex. I would like to think that this is
required by the incident report, but it's not specifically called out, so I
added this request to the bug.

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

Re: Certificates with 2008 Debian weak key bug

[Wayne Thayer via dev-security-policy]

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770
requesting an incident report from Certum.

On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes, the two certificates issued by Certum are trusted by Mozilla.

On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hi,
> >
> > I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> > weak key bug. (Only 2048 bit.)
> >
> > Overall I found 5 unexpired certificates.
> >
> > Two certificates by Certum (reported on Saturday, Certum told me "We
> > have taken necessary steps to clarify this situation as soon as
> > possible", they're not revoked yet):
> > https://crt.sh/?id=308392091=ocsp
> > https://crt.sh/?id=663=ocsp
> >
> > Wosign:
> > https://crt.sh/?id=30347743
> > StartCom:
> > https://crt.sh/?id=54187884
> > https://crt.sh/?id=307753186
> >
> > As we all know these are no longer trusted by Mozilla, I reported them
> > nevertheless. No reply yet.
> >
> > Old bugs never die, I recommend every CA adds a check for the Debian
> > bug to their certificate issuance process.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissuance/non-compliance remediation timelines

[Wayne Thayer via dev-security-policy]

On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> So, how long is too long?
>

This is the crux of the issue for me. If a CA (that really should have
stopped responding 'good' for unknown certs back in 2013) needs to select,
purchase, and deploy an entirely new OCSP system, is 5 months a really long
time? From their perspective, probably not.

I don't believe there is a standard answer to this question that can apply
to a whole class of issues, but I do think we could do a better job of
communicating our expectations when a situation like this arises by making
a statement such as 'being a CA that has been granted the public's trust,
Mozilla expects problem X to be resolved in Y days'. Responsible CAs will
meet the deadline and thus distinguish themselves from CAs that simply
aren't taking the problem seriously.

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

Re: Certificate for com and it

[Wayne Thayer via dev-security-policy]

On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:
>
>> On 08/02/18 13:47, Hanno Böck wrote:
>>
>> OneCRL additions normally have an associated bug but I can't see one for
>> this...
>>
>
> https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed)
> suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.
>
> This bug explains the recent addition of this subordinate CA to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1397969

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

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wyane,
> resopnding to your notes:
>
> Section 4.9 states that in any case that Comsign is notified about a
> misissuance (no matter if it was notified by a subscriber or in any other
> way) Comsign shall revoke the certificate.
>
> I have re-read section 4.9 of the ComSign CPS and I still do not agree
with your interpretation. However, I also believe that your current
language complies with Mozilla policy and the BR's.

It is true that we didn’t update the version number and we have corrected
> it. Along with updating the CPS version management table as well.
>
> about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>
> To recap, this inclusion request is for the ComSign Global Root CA that
was created in 2011[1]. This root was first BR audited on 26-April 2015,
but 36 end-entity certificates were issued prior to that time [2] (all but
one has since expired). We also have some evidence [3] that ComSign
received an ETSI 101 456 audit in 2012. ComSign stated “Back then it seems
we didn’t have a WebTrust audit (I believe we started in 2015) but only
external CPA and governmental audits as are attached already.” However, I
am unable to locate any additional audit documentation covering 2011-2015.

about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>

ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
issue certificates. This version has not been supported since July 2013
[4]. This implies that all 36 certificates were issued using unsupported CA
software.

I’ve discovered that ComSign recently issued two new unconstrained
subordinate CAs [5] from this root that contain a non-critical
basicConstraints extension in violation of BR 7.1.2.2. Another
unconstrained subordinate CA has been used to issue email certificates that
contain encoding errors [6].

In addition, numerous problems with ComSign’s CPS have been discussed in
this thread.

So, like we mentioned earlier we would like to be approved in advance so we
> could start issuing as soon as the new system will be in use.
>

While I appreciate ComSign’s efforts to resolve issues that have been
identified, new ones continue to be found. I am not at all comfortable
recommending that this request proceed at this time, and I have also lost
confidence that trust can ever be established for this root given its
history. I support Ryan’s recommendation that this request be denied and
that ComSign be asked to submit a new root containing a new key pair that
has not been used with their outdated CA system.

I would appreciate your comments on this course of action.

Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=675060
[2] https://bugzilla.mozilla.org/attachment.cgi?id=8938861
[3] https://bug675060.bmoattachments.org/attachment.cgi?id=615121
[4] https://community.rsa.com/docs/DOC-73367
[5] https://crt.sh/?cablint=680=1631=2017-01-01
[6] https://crt.sh/?caid=14449=x509lint=2014-01-01
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Yair,

> Re Section 3.4, you seem to assume the domain holder is a ComSign
> > subscriber.  In case of misissuance, that may not be true.
> >>> I understand, for that we added on the CPS on section 3.4 the
> following:
> "For the handling of revocation requests by other than the Subscriber or
> his/her representative, refer to Section ‎4.9 below."
>
> Could you please explain how section 4.9 resolves this concern? My
understanding of section 4.9 of your CPS is that only the Subscriber or an
authorized representative may request revocation.

> > >After reviewing the January Communication we have removed the
> problematic
> > > methods from our CPS entirely.
>

Thank you, this is a good change. However, it appears that you have made
multiple modifications to your CPS without updating the version number or
change log as required by Mozilla policy section 3.3. The latest version is
dated January 31, 2018 but is still at version 4.1 as it was back in
December.

The software we are currently using is RSA CA 6.7 on Solaris.
> As we mentioned we are now under audit on the new Microsoft CA and in the
> process of moving to that software instead of our old software.
>

According to the link Ryan provided [1], this version lost extended support
in July 2013. Is it correct that you have been using an unsupported version
of CA system software for the past 4 1/2 years?

Wayne

[1] https://community.rsa.com/docs/DOC-73367
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
> > The subCAs that we know of that fall into this category belong to Google
> > and Apple. If there are any other subCAs that fall into this category,
> > please let us know immediately. Google has one such subCA; Apple has
> seven.
>
> Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted
> on 2017-10-17, has Mozilla learned about any additional subCAs that will
> require a similar treatment?
>
> The Chrome team has posted a set of subordinate CAs to whitelist [1] that
contains some differences from the list that Gerv posted. I will ask Apple,
Google, and DigiCert to confirm which subordinates need to be whitelisted.

[1]
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

I assume that the end of the primary development phase for Firefox 60,
> which is early March 2018, will be the deadline to add whitelisting for
> any such subCAs.
>
> Kai
> ___
> 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: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Friday was the deadline for responding to this survey. Responses are now
published at
https://wiki.mozilla.org/CA/Communications#January_2018_Responses

I would like to thank everyone who took the time to respond, and especially
those who provided detailed answers to Action 2 regarding methods 1 and 5.

The following CAs have not responded:

   - Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
   - GoDaddy
   - Disig, a.s.
   - Certinomis / Docapost
   - Cybertrust Japan / JCSI
   - Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
   - TurkTrust
   - Web.com
   - E-Tugra

I will allow a grace period of a few days and then will open incident bugs
for those CAs that still haven't responded.

- Wayne

On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The email has been sent, and we've published a blog post:
>
> https://blog.mozilla.org/security/2018/01/29/january-2018-ca
> -communication/
>
> On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote:
> > You can find a link to the final version of the survey at
> > https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
> >
> > We're planning to send this out to all CAs in the Mozilla program later
> > today. The deadline for responses has been set to 9-February.
> >
> > Thanks to everyone who contributed to this effort.
> >
> > - Wayne
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Japan GPKI Root Renewal Request

[Wayne Thayer via dev-security-policy]

All of my questions regarding the CP/CPS and audits have been answered to
my satisfaction. I am left with two concerns:

1. This root was signed on 12-March 2013. The first end-entity certificate
that I'm aware of was signed later in 2013. Mozilla began requiring BR
audits in 2014, but the first BR assessment for this root was on
30-September 2015. [1] The assessment shows 22 issues. [2] A PITRA was
finally performed on January 31, 2017 [3] and no qualifications were noted.
This was followed by a clean period-of-time audit. It is clear that
hundreds of certificates were issued in this certificate hierarchy while it
was not BR compliant, some of which have not yet expired.

2. A number of misissued certificates under this hierarchy have been logged
[4], some of which are still valid. Some of these contain significant
compatibility problems such as the lack of a SAN and the lack of an OCSP
URL. The good news is that all of the bad certificates were issued prior to
2017.

At a minimum, the unexpired misissued certificates should be revoked, just
as has been done by other CAs in the Mozilla program. However, given the
demonstrated lack of BR compliance from 2013-2016, we should consider
rejecting this request and requiring that a new root using a new key pair
be generated and submitted for inclusion.

Please be aware that trust in this root will be constrained to .go.jp
domains, significantly reducing the risk it presents to Mozilla users.

I would appreciate everyone's constructive feedback on these issues, and
any others that are relevant to this inclusion request.

- Wayne

[1] https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
[2] https://bug870185.bmoattachments.org/attachment.cgi?id=8667815
[3] https://bug870185.bmoattachments.org/attachment.cgi?id=8852738
[4]
https://crt.sh/?caid=1419=cablint,zlint,x509lint=2013-01-01

On Mon, Feb 5, 2018 at 10:05 PM, apca2.2013--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Below is the answer to the pointed out earlier.
>
> == Bad ==
> * CPS docs are not assigned a version number (Mozilla policy 3.3)
>
> We had set up CP / CPS version number assignment rules. Based on this, at
> present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is
> 1.07. We attached CP / CPS with version number.
>
>
> * I can’t find a current WebTrust for CAs audit statement - I've requested
> a translated copy in the bug. There may be confusion over the fact that two
> audits are required.
>
> Since the audit reports were posted on WebTrust's website as follows, we
> will report those URLs.
> WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
>
>
> * The translated WebTrust BR audit report does not include all the
> information required by Mozilla policy 3.1.4. Based on information in the
> bug I believe this meant to be a period-of-time audit, but it looks like a
> point-in time readiness audit.
>
> (Same as the above answer）
> Since the audit reports were posted on WebTrust's website as follows, we
> will report those URLs.
> WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
>
>
> == Meh ==
> * Full name of the BRs is cut off in section 1: “CA/Browser  Forum,
> Baseline Requirements for the Issuance and Management of Publicly.”
>
> At the next revision, we will modify the corresponding part of CP / CPS
> section 1 of application CA 2 (Root) and application CA 2 (Sub) as follows.
> Application CA 2 (Root / Sub) conforms to the Baseline Requirements of CA
> / Browser Forum published at https://www.cabforum.org/.
>
>
> * Revision history doesn’t state what was changed (Mozilla policy 3.3
> requires a “dated changelog” but doesn’t explicitly require a description
> of changes to be included)
>
> At the next revision, we will add a change history of application CA 2
> (Root) and application CA 2 (Sub).
>
>
> * Neither the CPS or the BR Self Assessment explain how GPKI identifies
> high-risk certificate requests
>
> We have confirmed that the subjects of the server certificates are limited
> to "go.jp" and that those are the web servers managed by the government.
> In addition, we check the case of phishing on the websites such as the
> Council of Anti-Phishing Japan etc. and refer them to the examination work.
>
>
> * There are separate CPS’s for the root and it’s subordinate CA. Some of
> the required information (CAA, domain validation methods) is only contained
> in the sub CA’s CPS.
>
> Confirmation of CAA records, verification of domains, etc. are performed
> in the operation of application CA 2 (Sub), since it is being carried out
> in the application, not application CA 2 (Root), but application CA 2 (Sub).
>
>
> * The CPS doesn’t contain an explicit open-source license statement as
> encouraged by Mozilla policy 3.3(3)
>
> The CP / CPS document created by us has no special restrictions.
>
>
> * A minimal description of the 

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Hi Yair,

On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wayne,
> Please realize our situation versus the Israeli market. We are the major
> certificate authority and we comply with every piece of local regulation,
> we are also members of international forums and trying to establish a CA in
> the UK with a new "international" root (Comsign International).This is our
> long term plan.
> Meanwhile we are in a tough task to move from the RSA old and unsupported
> CA software to a new MS CA. It isn’t simple and involves many aspects,
> locally and internationally. On the same time, we try to be certified to
> eIDAS in order to be included in the European Trust list.
> Mozilla is a mile stone that we MUST pass once and for all, as it prevents
> and holds us from supplying a lot of signing services to the Israeli
> market, especially the increasing requests for services over the mobile.
> So, while we try to go "hand by hand" with you and with the BR, if you now
> send us back with the ROOT we have, it actually eliminates all the work we
> are doing to be complied with Mozilla for a long period of time, as you
> mentioned in your message. We can estimate that we will fully switch to MS
> within 6 months or so, mainly because we wait for the final audit and the
> approval of the  Israeli Ministry of Justice, but if, as you suggest, you
> do not trust the ROOT (not only the CA software in which we are all on the
> same page with you), it is a much bigger problem, as you understand the
> meaning of such severe conclusion after all our efforts we did with Mozilla
> not to speak about the damage to our reputation that such a decision
> creates.
>
> That was the background. For the essence:
> 1."ComSign Global Root CA that was created in 2011 was first BR audited on
> 26-April 2015, but 36 end-entity certificates were issued prior to that
> time, all but one has since expired)."
> >>This one certificate expires at 3/2018 and we commit not to issue new
> SSL certificates until we are authorized with the new MS CA. However this
> point should not affect the integrity of the entire Root.
>
> 2."However, am unable to locate any additional audit documentation
> covering 2011-2015.".
> >>We've asked the auditor (CPA Shefler which is approved by Webtrust from
> ~mid 2015) to send us all the audits reports. As is already disclosed this
> ROOT has passed many Webtrust audits over the last years and can be
> considered audited –we have already disclosed all the certificates that
> were issued prior to our first Webtrust as you have asked earlier on this
> thread.
>
> 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
> issue certificates. This version has not been supported since July 2013
> [4]. This implies that all 36 certificates were issued using unsupported CA
> software."
> >>Correct. Wrong decision of Comsign, which we apologized for. However, we
> still believe is should not affect the entire ROOT.
>
> 4."I’ve discovered that ComSign recently issued two new unconstrained
> subordinate Cas [5] from this root that contain a non-critical
> basicConstraints extension in violation of BR 7.1.2.2.
> >>While we appreciate your point here, these subCA's are not issuing SSL
> certificates at all but client certificates only. We cannot revoke these
> subordinates that serve hundreds of thousands of customers. However, if you
> approve our root – we commit to disclose the new SSL subCA before we issue
> new SSL certificates, while we keep the BR rules strictly of course.
>
> This comment demonstrates a continued lack of knowledge of Mozilla
requirements. Specifically, section 1.1 places these intermediates in-scope
because they are capable of issuing SSL certificates, so they must comply
with the BRs.

5."Another unconstrained subordinate CA has been used to issue email
> certificates that contain encoding errors [6]."
> >>That subCA does not issue SSL certificates as we mentioned above, the
> encoding error was corrected long ago and is linked to the RSA software
> that we are replacing in any case.
>
> 6."In addition, numerous problems with ComSign’s CPS have been discussed
> in this thread".
> >>All these problems were corrected by us and approved by Mozilla
> representatives.
>
> Yes, these problems were corrected after being identified by Mozilla, but
that is not trustworthy behavior. How many problems remain that we haven't
identified? A CA earns trust by understanding and complying with
requirements without supervision.


> 7."While I appreciate ComSign’s efforts to resolve issues that have been
> identified, new ones continue to be found. I am not at all comfortable
> recommending that this request proceed at this time, and I have also lost
> confidence that trust can ever be established for this root given its
> history. I support Ryan’s recommendation that this request be denied and
> that ComSign be asked to submit a new 

Re: Public trust of VISA's CA

[Wayne Thayer via dev-security-policy]

On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg 
wrote:

>
> > On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > In the light of this, I believe it is reasonable to discuss the question
> > of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> > https://crt.sh/?id=896972 , which is the one includes in our store)
> > meets the criteria for inclusion in Mozilla's Root Store Policy, and
> > whether it is appropriate for them to continue to hold public trust.
> > Your comments are welcome.
>
> I don’t think this issue ever got a conclusion. It is clear to me that
> Visa should be removed from the Mozilla root program immediately.
>
> We did reach a conclusion on the original question that Gerv raised in
this thread: does Visa meet the following requirement from section 2.1 of
the Mozilla root store policy:

CAs whose certificates are included in Mozilla's root program MUST provide
some service relevant to typical users of our software products.

In the thread on this list titled "Updating Root Inclusion Criteria" it was
decided that we will not attempt to restrict organizations from
participating in the Mozilla CA program based on a judgement of their value
to our users.

Visa has been extremely unresponsive in general. The most recent case was
> their non-compliant OCSP responder: https://bugzilla.mozilla.org/s
> how_bug.cgi?id=1398261
>
> It took them five months to fix the problem, and there is still no
> incident report.
>
> Correct. Would a representative from Visa care to comment on this?

In their response to January CA Communication Action 2 (about insecure
> domain validation methods), they did not provide a comment response, but
> selected the option indicating they were using these vulnerable methods and
> required a date for an update in the comment field:
>
> > We have active (not expired or revoked) certificates issued using these
> methods. We will review our implementation for vulnerabilities and report
> our findings on the mozilla.dev.security.policy list by the date specified
> in the comments section below.
>
> Good point. I would appreciate a response from a Visa representative with
the date by which these findings will be reported.


> There are currently only 90 unexpired certificates issued by this CA known
> to CT: https://crt.sh/?Identity=%25=1414=expired (last time
> we looked, there were only 27 and two were revoked)
>
> Additionally, the telemetry shows an extremely small number of validations.
>
> It’s not clear to me from their responses whether they are even currently
> BR-compliant, and as of September 13, 2017 it seems like they weren’t:
>
> > Regarding BR compliance, we completed our initial BR audit in September
> of 2016.  Since that time, we have been addressing the observations noted
> by our external auditors.  This also would encompass any certificate issues
> that have been publically reported.  Understanding that such changes in
> adopting a new process will have business impact, it is difficult to
> provide an accurate timeline of complete compliance as we are required to
> assess the impact to our client and payment systems to avoid any
> operational impact.  We are committed to aligning with BR and Mozilla
> requirements as we have continuously move forward in making the necessary
> changes .
>
> The most recent BR audit report for the Visa eCommerce Root contains 3
qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

Given all this, I don’t think there is a lot of risk to Mozilla’s users
> with no benefit if Visa continues to be included in the root program.
>
> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public trust of VISA's CA

[Wayne Thayer via dev-security-policy]

On Tue, Feb 13, 2018 at 11:26 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
>
> > The most recent BR audit report for the Visa eCommerce Root contains 3
> qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf
>
> Does Mozilla have any guidelines or official position on what constitutes
> sufficient audit issues to result in sanctions?


As Gerv described in the other thread [1], Mozilla's current approach is to
document each issue and view them in aggregate, rather than defining a set
of penalties that apply in given situations. Mozilla has certainly required
actions from CAs as a condition to remaining in the program, but those
"sanctions" have been defined in the context of specific situations. While
I also find the idea of defining more generic penalties appealing on the
surface, I'm not convinced that it would lead to better outcomes for our
users.

Frankly I'm stunned that
> any CA in the Mozilla root program can apparently ignore the baseline
> requirements for approximately 4 years after their effective date, get an
> initial BR audit with multiple qualifications, and see no penalty from this
> behavior.


Their initial BR PITRA was in 2016. It lists 7 qualifications [2]

And this is disregarding several other BR violations found in the
> wild by independent researchers. I realize I'm banging the same drum as in
> my other thread, but without consistent enforcement of escalating penalties
> I don't believe we're teaching CAs anything other than that Mozilla will
> ultimately forgive almost any transgression. Unless you catch them on a bad
> day, in which case you might get distrusted entirely.
>
> In this particular case, my conclusion is that the existing Mozilla
process is working. We have documented a number of issues that when
considered in aggregate warrant an investigation.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/d-m48lVtYoQ/HvlXcfwWAQAJ
[2] https://bug1301210.bmoattachments.org/attachment.cgi?id=8795503

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

Re: Public trust of VISA's CA

[Wayne Thayer via dev-security-policy]

On Wed, Feb 14, 2018 at 10:47 AM, Tim Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote:
> > In this particular case, my conclusion is that the existing Mozilla
> > process is working. We have documented a number of issues that when
> > considered in aggregate warrant an investigation.
>
> Hi Wayne,
>
> Forgive me if I'm overinterpreting your comment, but: does this mean that
> an investigation is ongoing, or that Mozilla anticipates opening an
> investigation? If there is or will be an investigation, do you have a
> general sense of when to expect a result, and what that might look like?
>
> My comment means that I have acknowledged the issue and am looking into
it, but haven't yet committed Mozilla to a specific course of action or
timing.


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