Define/clarify policy for transfer of intermediate CA certificates

[Wayne Thayer via dev-security-policy]

This issue was brought up in the thread that kicked off the 2.6 root store
policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose
new unconstrained intermediate CA certificates within one week of creation.
Section 8 covers [in my opinion] transfers of roots but not intermediates.
This leaves a loophole for a CA to create a new intermediate CA
certificate, then transfer it without notice or approval. This problem also
applies to cross-signatures from one CA to another.

I am aware of three potential solutions:

1. In section 5.3.2, require CAs to also disclose a change in the ownership
or control of an unconstrained intermediate CA certificate within one week
of the change.

2. Modify section 8 to explicitly include transfers of trust via
intermediate CA certificates and cross signatures. Under section 8.1, this
would require notice and approval:

If the receiving or acquiring company is new to the Mozilla root program,
> there MUST be a public discussion regarding their admittance to the root
> program, which Mozilla must resolve with a positive conclusion before
> issuance is permitted.
>
3. Require organizations that are receiving subordinate CA certificates to
go through the whole Mozilla inclusion process as if they were applying for
a new root.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/122

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/
xGGGaI1_uo0/POMANRWRAAAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer  wrote:

> As an alternative to requiring newly-issued subCA Certificates to be
> listed in the relevant CP/CPS prior to issuing certificates, would it be
> reasonable for Mozilla to require the Certificate Policies extension in
> these certificates to contain a URL pointing to the relevant policy
> document(s)? I believe that most subCA certificates already contain this
> information.
>
> Section 7.1.2.2 of the BRs states that the
certificatePolicies:policyQualifiers:qualifier:cPSuri for a subCA
certificate should contain a pointer to the **root** CA's policies. If this
is correct, then my proposal doesn't solve the problem of requiring
disclosure of the policies that a new subordinate CA certificate is
operating under.

In theory, we could also permit three options - add the new subCA
> certificate to the relevant CP/CPS, include a Certificate Policies pointer,
> or publish an attestation, but I'd prefer a single, consistent mechanism
> that allows a relying party to determine which policies apply.
>
> Based on the feedback so far, none of these options is desirable. I
propose that we only make the change to section 5.3.2 of the Mozilla policy
that clarifies the audit requirements for new subCA certificates, as
follows:

If the subordinate CA has a currently valid audit report at the time of
> creation of the certificate, it MUST appear on the subordinate CA's next
> periodic audit reports.
>

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

Re: CCADB disclosure of id-kp-emailProtection intermediates

[Wayne Thayer via dev-security-policy]

Mozilla's April 15 deadline for disclosure of email intermediates that are
not technically constrained has now passed. I have created the following
bugs for the certificates listed at https://crt.sh/mozilla-disclos
ures#undisclosed

* Firmaprofesional: https://bugzilla.mozilla.org/show_bug.cgi?id=1455119
* (The "Buypass Class 2 CA 4" has been revoked and will be added to OneCRL)
* Certicamara: https://bugzilla.mozilla.org/show_bug.cgi?id=1455128
* SwissSign: https://bugzilla.mozilla.org/show_bug.cgi?id=1455132
* T-Systems: https://bugzilla.mozilla.org/show_bug.cgi?id=1455137

And for incomplete disclosure (no audit information in CCADB), I have
created bugs for the certificates listed at https://crt.sh/mozilla-disclos
ures#disclosureincomplete

* DocuSign: previously reported in https://bugzilla.mozilla.org/s
how_bug.cgi?id=155. Incident report submitted and remediation plan
proposed
* Camerfirma: https://bugzilla.mozilla.org/show_bug.cgi?id=1455147
* DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1455150 (DigiCert
notified me that they would not be able to meet the deadline, but they are
working to resolve these issues)
* Telia: https://bugzilla.mozilla.org/show_bug.cgi?id=1451953 was created a
few weeks ago. Telia states that they plan to revoke the two undisclosed
certificates in April.

- 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: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <r...@sleevi.com> 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?

On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > I think you should consider an an exception Issuing CAs including Name
>> > Constraints. This would keep allowing root signing services for
>> corporate
>> > CAs without forcing multiple CAs.
>> >
>>
>> Thank you for the suggestion. It seems reasonable to me. If no one
>> objects,
>> I will move the proposed language to section 5.3.2 so that it applies only
>> to unconstrained intermediates.
>>
>> - Wayne
>> ___
>> 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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 20/04/2018 21:59, Wayne Thayer wrote:
>
>> On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> I believe the wording "insecure electronic channels" leaves a lot of space
>>> for interpretation. In corporate PKIs for email encryption it is quite
>>> common to transfer centrally generated email encryption p12-files to
>>> mobile
>>> device management systems, email encryption gateways or directly to
>>> mobile
>>> devices using a wide variety of 'electronic channels'. From the proposed
>>> wording it doesn't seem to be clear which of those channels are
>>> 'insecure'
>>> and which not. Even if not that common, the same applies for email
>>> signature p12-files for e.g. email signature on mail gateways or mobile
>>> devices. Most of the mobile devices out in the field neither support
>>> hardware token, key-pair-generation in the mailer software nor
>>> installation
>>> of downloaded p12-files (prohibited by app sandboxing).
>>>
>>> Maybe it would be possible to restrict the new wording to the EKU
>>> kp-ServerAuth first and have a detailed discussion about email-encryption
>>> and user authentication with more interested parties in the next months?
>>>
>>>
>> Again, this is not new wording. It's already a requirement:
>> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practic
>> es#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
>>
>> Having said that, could we instead be more specific by replacing "insecure
>> electronic channels" with "unencrypted email"? Limiting the scope of this
>> statement to id-kp-serverAuth is meaningless since we forbid CA key
>> generation for server certificates.
>>
>>
> That would allow unencrypted HTTP, unencrypted FTP, unencrypted TFTP
> etc. etc.  It would also allow 40 bit encrypted connections (they are
> insecure but unencrypted).  The list of insecure electronic channels is
> infinite.
>
> The original intent appears to have been to forbid using email to transmit
PKCS#12 files because it includes the following bullet [1]:
* The distribution channels used (e.g. unencrypted email) may not be
adequately secured.

The original phrase "insecure electronic channels" does encompass more but
is also vague enough to be easily misinterpreted.

Perhaps the phrase "unencrypted electronic channels" is a better solution?
I would welcome other suggestions.

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_
Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:
> > Hi Ramiro,
> >
> > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via
> dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Hi Ryan
> > >
> > > Thanks again for your remarks.
> > > In the end I am going to learn something of PKI :-).
> > > Surely I do not get a full understanding of you solution, but public
> > > administration is requiring a EU qualified Web certificate this means
> that
> > > should be included in the EUTL. I do know other solution for a new
> root but
> > > a new conformity assessment.
> > >
> > > If the "2016" roots are included in the EUTL, then they can be used to
> > sign ("cross-sign") a new "2018" root (or roots) that will then inherit
> the
> > trust from the "2016" root. From the perspective of the EUTL, the new
> root
> > would look like a new intermediate CA certificate.
>
> Wayne, the EUTL do not include ROOTS, only SubCA. It doesn't works in this
> way. Our hypothetical new 2018 root should issue a SubCA for WEBSITE
> certificates and this SubCA should be included in the EUTL, previously we
> should pass a new conformity assessment and send it to our National
> Supervisor body..and so on.
>
> In that case, the new "2018" root(s) could be used to cross-sign the older
roots to provide a transition that allows your "2016" roots to be trusted
in Mozilla products until the "2018" SubCAs are added to the EUTL.

> >
> > Nevertheless, let me insist. In which aspects a new root 2018 improve our
> > > trustworthiness instead of the current root 2016?
> > >
> > > This is the wrong question to ask. For all the reasons stated in
> earlier
> > messages, the Mozilla community appears to have concluded that the 2016
> > roots are not trustworthy. If that is the case, then the proposal that
> you
> > create a new root answers the question that I think you should be asking:
> > "How can Camerfirma regain the community's trust?" Submitting a new root
> > that has been audited, has no history of misissuance, and complies in
> every
> > way with our policies has been proposed as one possible way to increase
> > confidence in your CA. If you have been following this mailing list, you
> > have seen that this same action has been recommended to other CAs that
> are
> > in this situation.
> >
>
> Wayne, all issues stated are already resolved, Moreover actually 2016 root
> is not affected by those problems. That's why I do not see the difference
> between 2016 root and a new 2018 root.
>
> Documented misissuance from the 2016 roots:
https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01

Moreover, all of the CPS issues that I identified apply to the 2016 roots,
and many of the other issues - such as CAA failures - apply equally to
these roots. So why do you believe that the '2016 root is not affected by
those problems'?

Nevertheless We offer a "Point in time audit" over 2016 root in order to
> provide to the community a clear assurance that all technical controls are
> in place and fulfill the BR requirements. Previously, to start from a clean
> point, We offer as well to revoke all WebSite certificates issued under
> this root.
>
> We think that this proposal should provide a similar situation that we
> would have if a new 2018 root were set up.
>
> Regards
> Ramiro
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

[Wayne Thayer via dev-security-policy]

On Thu, Mar 29, 2018 at 2:12 PM, Ryan Sleevi <r...@sleevi.com> wrote:

>
>
> On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer <wtha...@mozilla.com> wrote:
>
>> On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>>
>>>
>>> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>> When the Francisco Partners acquisition of Comodo was announced, it was
>>>> pointed out [1] that a strict reading of the current policy section 8.1
>>>> would have forced Comodo to stop issuing certificates for some period of
>>>> time:
>>>>
>>>> If the receiving or acquiring company is new to the Mozilla root
>>>> program,
>>>> > there MUST be a public discussion regarding their admittance to the
>>>> root
>>>> > program, which Mozilla must resolve with a positive conclusion before
>>>> > issuance is permitted.
>>>> >
>>>>
>>>> I propose that we update section 8.1 to distinguish between root
>>>> transfers
>>>> and acquisition of or investment in a CA organization, with the latter
>>>> cases allowing issuance to continue during the discussion period.
>>>>
>>>> During the earlier discussion on this topic [1], it was also proposed
>>>> that
>>>> we require the receiving or acquiring company to make no changes during
>>>> the
>>>> discussion period and that we require all material changes anticipated
>>>> as a
>>>> result of the investment or acquisition to be publicly disclosed by the
>>>> CA.
>>>>
>>>> This is: https://github.com/mozilla/pkipolicy/issues/109
>>>>
>>>> [1]
>>>> https://groups.google.com/d/msg/mozilla.dev.security.policy/
>>>> AvGlsb4BAZo/gQe5ggE6BQAJ
>>>
>>>
>>> I'm having a little bit of difficulty imagining what you see the change
>>> looking like. Do you have draft text in mind, to look for possible
>>> exploitable loopholes?
>>>
>>> Here's a proposal: https://github.com/mozilla/pki
>> policy/commit/565250b9bbc16c1a4e3d4165f0171e8702b2b21d
>>
>
> Thanks, that's much easier to visualize.
>
> I think it's a positive change, but it may be worth emphasizing that a
> complete change in ownership does not otherwise exempt a CA from the other
> reporting - such as changes in operational personnel, material changes in
> the CA's operations (CP/CPS), etc. This is covered by Section 8.2 and 8
> overall, so it may not bear mentioning explicitly, or it may be worth
> noting that the receiving or acquiring company will be bound by the policy,
> in full, including any notifications of further changes.
>

To address this comment, I added the statement "...it must comply with the
entirety of this policy...". With both changes, section 8.1 would read as
follows:

> This section applies when one company buys or takes a controlling stake in
> a CA, or when an organization buys the private key of a certificate in
> Mozilla's root program.
>
> Mozilla MUST be notified of any resulting changes in the CA's CP or CPS.
>
> If the receiving or acquiring company is new to the Mozilla root program,
> it must comply 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.
>
Unless there are further comments on this topic, I'll include this change
in version 2.6

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

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi  wrote:

>
> I think, for new CAs, the KGC report and the stated CP/CPS, combined with
> ensuring that the next audit that covers the period of time stated on the
> KGC report includes that certificate, seems like a reasonable balance.
>

I'll add this to the list for 2.6 and propose some language in a new
"Policy 2.6 Proposal" thread.

Thanks,

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: Require disclosure of S/MIME validation practices

[Wayne Thayer via dev-security-policy]

This change is made in the 2.6 branch:
https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b

We'll need to discuss a deadline for the CPS updates to be published.

- Wayne


On Mon, Mar 26, 2018 at 12:59 PM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> I like this one.
>
> It will be very useful as a starting point if we finally get a CABF S/MIME
> working
> group, which is likely to happen.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> > Thayer via dev-security-policy
> > Sent: Monday, March 26, 2018 2:50 PM
> > To: mozilla-dev-security-policy
> <mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: Policy 2.6 Proposal: Require disclosure of S/MIME validation
> practices
> >
> > Mozilla policy section 2.2(2) requires validation of email addresses for
> S/MIME
> > certificates, but doesn't require disclosure of these practices as it
> does
> for TLS
> > certificates.
> >
> > I propose adding the following language from 2.2 (3) (TLS) to 2.2(2)
> > (S/MIME):
> >
> > The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
> to
> > perform this verification.
> >
> > This is: https://github.com/mozilla/pkipolicy/issues/114
> >
> > ---
> >
> > This is a proposed update to Mozilla's root store policy for version 2.6.
> Please
> > keep discussion in this group rather than on GitHub. Silence is consent.
> >
> > Policy 2.5 (current version):
> > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> > ___
> > 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: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Tim,

On Fri, Mar 30, 2018 at 7:00 AM, crawfordtimj--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote:
> > On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > I think, for new CAs, the KGC report and the stated CP/CPS, combined with
> > ensuring that the next audit that covers the period of time stated on the
> > KGC report includes that certificate, seems like a reasonable balance.
>
> I think BR 6.1.1.1 is  a little confusing on when a root key generation
> observation report is required, because it uses the term “Root CA Key Pair”
> in a section that seems to be addressing CAs that are not root CAs.
>
> For other CA Key Pairs created after the Effective Date that are for the
> operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
>
> This part seems clear to me.

1. prepare and follow a Key Generation Script and
> 2. have a Qualified Auditor witness the Root CA Key Pair generation
> process or record a video of the entire Root CA Key Pair generation process.
>
>
If you are commenting on the word "Root" in #2, then I think this is meant
to apply to both Root and subordinate CA key pairs, so both instances of
the word "Root" should be struck.
___
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 audits back to first issuance

[Wayne Thayer via dev-security-policy]

On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi  wrote:

>
> I'm not fully sure I understand the proposal here.
>
> I would think that, for all roots created since 2012, the expectation
>
is that there is an unbroken series of audits, going from a Point in Time
> audit (of the policies and infrastructure) to a Root Key Generation
> Ceremony attestation (under the policies and practices) to a Period of Time
> audit, with the issuance of any supporting infrastructure appearing between
> the RKGC and the PoT and covered by the PoT audit.
>
> This expectation apparently isn't clear given the numerous inclusion
requests - for roots created before and after 2012 - we're seen that are
lacking historic audits - Japan GPKI and ComSign for instance.

I wasn't thinking about requiring the RKGC audit report as part of our
inclusion process, but we probably should (assuming those reports aren't
confidential).

Does that match your intent? Assuming I did not botch the audit timing
> issues here
>
> I think so. My intent is to make it clear that roots must meet our audit
requirements even before they are included, and I'm open to suggestions on
the best way to achieve that in our policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

[Wayne Thayer via dev-security-policy]

On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote:

>
> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> When the Francisco Partners acquisition of Comodo was announced, it was
>> pointed out [1] that a strict reading of the current policy section 8.1
>> would have forced Comodo to stop issuing certificates for some period of
>> time:
>>
>> If the receiving or acquiring company is new to the Mozilla root program,
>> > there MUST be a public discussion regarding their admittance to the root
>> > program, which Mozilla must resolve with a positive conclusion before
>> > issuance is permitted.
>> >
>>
>> I propose that we update section 8.1 to distinguish between root transfers
>> and acquisition of or investment in a CA organization, with the latter
>> cases allowing issuance to continue during the discussion period.
>>
>> During the earlier discussion on this topic [1], it was also proposed that
>> we require the receiving or acquiring company to make no changes during
>> the
>> discussion period and that we require all material changes anticipated as
>> a
>> result of the investment or acquisition to be publicly disclosed by the
>> CA.
>>
>> This is: https://github.com/mozilla/pkipolicy/issues/109
>>
>> [1]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/
>> AvGlsb4BAZo/gQe5ggE6BQAJ
>
>
> I'm having a little bit of difficulty imagining what you see the change
> looking like. Do you have draft text in mind, to look for possible
> exploitable loopholes?
>
> Here's a proposal:
https://github.com/mozilla/pkipolicy/commit/565250b9bbc16c1a4e3d4165f0171e8702b2b21d

On its face, it sounds reasonable, but it seems the wording will be tricky
> to get right.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Peter,

Are you advocating for option #2 (TSP self-attestation) because you think
that option #3 (audit) is unreasonable, or because you believe there is a
benefit to Mozilla's users in a self-attestation beyond what we get from
the existing requirement for CCADB disclosure?

On Fri, Mar 23, 2018 at 6:18 PM, Peter Bowen <pzbo...@gmail.com> wrote:

> On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > Recently I've received a few questions about audit requirements for
> > subordinate CAs newly issued from roots in our program. Mozilla policy
> > section 5.3.2 requires these to be disclosed "within a week of
> certificate
> > creation, and before any such subCA is allowed to issue certificates.",
> but
> > says nothing about audits.
> >
> > The fundamental question is 'when must a new subCA be audited?' It is
> clear
> > that the TSP's [1] next period-of-time statement must cover all subCAs,
> > including any new ones. However, it is not clear if issuance from a new
> > subCA is permitted prior to being explicitly included in an audit.
> >
> > I believe that it is common practice for TSPs to begin issuing from new
> > subCAs prior to inclusion in an audit. This practice is arguably
> supported
> > by paragraph 3 of BR 8.1 which reads:
> >
> > If the CA has a currently valid Audit Report indicating compliance with
> an
> >> audit scheme listed in Section 8.1, then no pre-issuance readiness
> >> assessment is necessary.
> >>
> >
> > When disclosing a new subCA, the TSP can select "CP/CPS same as parent"
> and
> > "Audits same as parent" in CCADB to indicate that the same policies apply
> > to the new subordinate as to the root.
> >
> > This issue was raised at the CA/Browser Forum meeting in October 2016
> [2].
> >
> > Three options have been proposed to resolve this ambiguity:
> > 1. Permit a new subCA to be used for issuance prior to being listed on an
> > audit report.
> > 2. Require the TSP to attest that the new subCA complies with a set of
> > existing policies prior to issuance [3].
> > 3. Require an audit report (point-in-time or period-of-time) covering the
> > new subCA before any issuance (possibly with an exception for test
> > certificates or certificates required for audit purposes).
> >
> > Please consider these options in the context of a TSP with a current
> audit
> > for the parent root that has issued a new subCA, and for which the new
> > subCA is operating under existing policies and in an existing operational
> > environment. If this is not the case, I would propose that a new audit
> > covering the subCA be required.
>
> Unsurprisingly, I support option #2.  However I think is it important
> that there are three distinct things that need to be covered:
>
> 1) Key generation for the new CA
> 2) Assertion of controls for the new CA
> 3) Issuance of a CA certificate, by an existing trusted CA, that names
> the new CA as the subject
>
> I does make sense to allow a slight delay in disclosure such that a
> single ceremony can be used to generate the key and issue a CA
> certificate, but a week seems plenty generous.
>
> Thanks,
> Peter
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

[Wayne Thayer via dev-security-policy]

Mozilla policy section 2.2(2) requires validation of email addresses for
S/MIME certificates, but doesn't require disclosure of these practices as
it does for TLS certificates.

I propose adding the following language from 2.2 (3) (TLS) to 2.2(2)
(S/MIME):

The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
to perform this verification.

This is: https://github.com/mozilla/pkipolicy/issues/114

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Require audits back to first issuance

[Wayne Thayer via dev-security-policy]

Mozilla began requiring BR audits for roots in our program in 2013 [1], but
we have a vague policy statement in section 3.1 regarding audit
requirements prior to inclusion:

Before being included and periodically thereafter, CAs MUST obtain certain
> audits…
>

BR section 8.1 contains the following paragraph:

If the CA does not have a currently valid Audit Report indicating
> compliance with one of the audit schemes listed in Section 8.1, then,
> before issuing Publicly-Trusted Certificates, the CA SHALL successfully
> complete a point-in-time readiness assessment performed in accordance with
> applicable standards under one of the audit schemes listed in Section 8.1.
> The point-in-time readiness assessment SHALL be completed no earlier than
> twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL
> be followed by a complete audit under such scheme within ninety (90) days
> of issuing the first Publicly-Trusted Certificate.
>

Unfortunately, the definition of Publicly-Trusted Certificates exempts
newly created roots from this requirement, and in practice we have seen
that violating this requirement does not prevent roots from receiving BR
audit statements. We continue to see inclusion requests for roots that do
not have an unbroken chain of BR audits back to first issuance.

I propose that we add a requirement to Mozilla policy section 3.1.3 for
roots to have contiguous audits beginning within 90 days of issuing the
first certificate. I chose 90 days to allow some time for issuing
subordinate CA certificates and test certificates in preparation for the
audit.
.
This is: https://github.com/mozilla/pkipolicy/issues/113

[1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/nIirftRqAgAJ

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Fwd: FW: Complying with Mozilla policy on email validation

[Wayne Thayer via dev-security-policy]

I'm forwarding this for Tim because the list rejected it as SPAM.



*From:* Tim Hollebeek
*Sent:* Monday, April 2, 2018 2:22 PM
*To:* 'mozilla-dev-security-policy' 
*Subject:* Complying with Mozilla policy on email validation





Mozilla policy currently has the following to say about validation of email
addresses in certificates:



“For a certificate capable of being used for digitally signing or
encrypting email messages, the CA takes reasonable measures to verify that
the entity submitting the request controls the email account associated
with the email address referenced in the certificate or has been authorized
by the email account holder to act on the account holder’s behalf.”



“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.”



“Before being included and periodically thereafter, CAs MUST obtain certain
audits for their root certificates and all of their intermediate
certificates that are not technically constrained to prevent issuance of
working server or email certificates.”



(Nit: Mozilla policy is inconsistent in it’s usage of email vs e-mail.  I’d
fix the one hyphenated reference)



This is basically method 1 for email certificates, right?  Is it true that
Mozilla policy today allows “business controls” to be used for validating
email addresses, which can essentially be almost anything, as long as it is
audited?



(I’m not talking about what the rules SHOULD be, just what they are.  What
they should be is a discussion we should have in a newly created CA/* SMIME
WG)



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

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> While Entrust happens to do this, as a relying party, I dislike frequent
> updates to CP/CPS documents just for such formal changes.
>
> This creates a huge loophole. The CP/CPS is the master set of policies the
TSP agrees to be bound by and audited against. If a TSP doesn't include a
new subCA certificate in the scope of their CP/CPS, then from an audit
perspective  there is effectively no policy that applies to the subCA.
Similarly, if the TSP claims to implement a new policy but doesn't include
it in their CP/CPS, then the audit will not cover it (unless it's a BR
requirement that has made it into the BR audit criteria).

This is because the CP/CPS is a lengthy legal document which relying
> parties are "supposed to" read and understand.  Thus each such needless
> change generates a huge wave of millions of relying parties being
> supposed to obtain and read through that document, a complete waste of
> our time as relying parties.
>
> I think you're confusing the Relying Party Agreement with the CP/CPS. Even
so, you've pointed out that it is absurd to use this as an argument against
regular CP/CPS updates.

TSPs are now required to maintain change logs in their CP/CPS.  Would not a
quick glance at that meet your needs?

It is much more reasonable, from a relying party perspective, for such
> informational details to be in a parallel document and/or be postponed
> until a scheduled annual or rarer document update (Yes I am aware of the
> BR that such needless updates be done annually for no reason at all).
>
> How would you distinguish between details and material changes? I would
argue that a new subCA certificate is more than an informational detail.

The point of the BR requirement is to create some documentation indicating
that a TSP is regularly reviewing and updating their CP/CPS.
___
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 audits back to first issuance

[Wayne Thayer via dev-security-policy]

Thanks Tim and Ryan for the information on WebTrust Root Key Generation
Ceremony audit reports. Can anyone say if an equivalent public-facing
report exists for ETSI audits? If so, I think we should require CAs to
provide these reports with their root inclusion requests.

Regarding the issue of requiring audits from the time of first issuance,
here's a specific proposal:

In section 2.3 (Baseline Requirements Conformance), add a new bullet that
states "Before being included, CAs MUST provide evidence that their root
certificates have continually, from the time of creation, complied with the
then current Mozilla Root Store Policy and CA/Browser Forum Baseline
Requirements."

- Wayne

On Fri, Mar 30, 2018 at 6:45 AM, crawfordtimj--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, March 29, 2018 at 10:59:10 AM UTC-5, Ryan Sleevi wrote:
> > On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Mozilla began requiring BR audits for roots in our program in 2013
> [1], but
> > > we have a vague policy statement in section 3.1 regarding audit
> > > requirements prior to inclusion:
> > >
> > > Before being included and periodically thereafter, CAs MUST obtain
> certain
> > > > audits…
> > > >
> > >
> > > BR section 8.1 contains the following paragraph:
> > >
> > > If the CA does not have a currently valid Audit Report indicating
> > > > compliance with one of the audit schemes listed in Section 8.1, then,
> > > > before issuing Publicly-Trusted Certificates, the CA SHALL
> successfully
> > > > complete a point-in-time readiness assessment performed in accordance
> > > with
> > > > applicable standards under one of the audit schemes listed in Section
> > > 8.1.
> > > > The point-in-time readiness assessment SHALL be completed no earlier
> than
> > > > twelve (12) months prior to issuing Publicly-Trusted Certificates and
> > > SHALL
> > > > be followed by a complete audit under such scheme within ninety (90)
> days
> > > > of issuing the first Publicly-Trusted Certificate.
> > > >
> > >
> > > Unfortunately, the definition of Publicly-Trusted Certificates exempts
> > > newly created roots from this requirement, and in practice we have seen
> > > that violating this requirement does not prevent roots from receiving
> BR
> > > audit statements. We continue to see inclusion requests for roots that
> do
> > > not have an unbroken chain of BR audits back to first issuance.
> > >
> > > I propose that we add a requirement to Mozilla policy section 3.1.3 for
> > > roots to have contiguous audits beginning within 90 days of issuing the
> > > first certificate. I chose 90 days to allow some time for issuing
> > > subordinate CA certificates and test certificates in preparation for
> the
> > > audit.
> > > .
> > > This is: https://github.com/mozilla/pkipolicy/issues/113
> > >
> > > [1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
> > > [2]
> > > https://groups.google.com/d/msg/mozilla.dev.security.
> policy/Mezqdljjerc/
> > > nIirftRqAgAJ
> >
> >
> >
> > I'm not fully sure I understand the proposal here.
> >
> > I would think that, for all roots created since 2012, the expectation is
> > that there is an unbroken series of audits, going from a Point in Time
> > audit (of the policies and infrastructure) to a Root Key Generation
> > Ceremony attestation (under the policies and practices) to a Period of
> Time
> > audit, with the issuance of any supporting infrastructure appearing
> between
> > the RKGC and the PoT and covered by the PoT audit.
> >
> > Does that match your intent? Assuming I did not botch the audit timing
> > issues here
>
> The standard audit cycle, we normally see for a brand new CA, is as
> follows:
>
> 1.  Draft CP/CPS
> 2.  Perform RKGC, observed and reported on by auditor
> 3.  Point in time reporting
> 4.  Period of time reporting
>
> Most CAs elect to perform a RKGC before a point in time engagement,
> because without any CA activities in place most of the WebTrust criteria
> would not be applicable at the point time of reporting.  As an example,
> much of the following sections would not be applicable:
>
> 4.0 – CA Key Lifecycle Management Controls
> 6.0 – Certificate Lifecycle Management
>
> These sections represent a substantial portion of the WebTrust Principles
> and Criteria.
> ___
> 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: FW: Complying with Mozilla policy on email validation

[Wayne Thayer via dev-security-policy]

On Tue, Apr 3, 2018 at 11:42 AM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Apr 3, 2018 at 12:19 PM, Ryan Hurst via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> >
> > For example, if we consider a CA supporting a large mail provider in
> > providing S/MIME certificates to all of its customers. In this model, the
> > mail provider is the authoritative namespace owner.
> >
>
> There may be interest in some of the other twists such a concept helps to
> illuminate.  MV (mail validated) versus IV (individual validated).  I'm
> aware that the BRs don't contemplate email certificates and standards
> pertaining to these, but one of the BR concepts is that Subject party data
> of an unvalidated nature not be included in the certificate.  For example,
> no O= component on certificates which were solely domain validated.
> Similarly, does or should Mozilla policy consider Subject parameters other
> than E= in the email program?
>
> A third party domain delegating via MX record email addresses of that
> domain does seem both point-in-time auditable and would generally prove
> that a party at the target MX server does or could choose to receive email
> to any address at that domain.  But even the domain serving the email
> address doesn't get us to CN=Real Name.  So, my question is whether the
> policy should incorporate standards similar to the BRs which require that
> those personal-level details be validated if included?
>
> Our policy covers this in section 2.2(1) :

*All information that is supplied by the certificate subscriber MUST be
verified by using an independent source of information or an alternative
communication channel before it is included in the certificate.*

>
> >
> > In the context of mail, you can imagine gmail.com or
> peculiarventures.com
> > as examples, both are gmail (as determined by MX records). It seems
> > reasonable to me (Speaking as Ryan and not Google here) to allow a CA to
> > leverage this internet reality (expressed via MX records) to work with a
> CA
> > to get S/MIME certificates for all of its customers without forcing them
> > through an email challenge.
> >
> > In this scenario, you could not rely on name constraints because the
> > onboarding of custom domains (like peculiarventures.com) happens real
> > time as part of account creation. The prior business controls text seemed
> > to allow this case but it seems the interpretation discussed here would
> > prohibit it.
> >
> >
> > Another case I think is interesting is that of a delegation of email
> > verification to a third-party. For example, when you do a OAUTH
> > authentication to Facebook it will return the user’s email address if it
> > has been verified. The same is true for a number of related scenarios,
> for
> > example, you can tell via Live Authentication and Google Authentication
> if
> > the user's email was verified.
> >
>
> Among other questions that raises, how do you determine and audit the
> trustworthiness of the third party to speak as to the email validation?  It
> seems the trend in the BR world of the WebPKI is to reduce reliance on
> third party validations and assertions.
>
>
> >
> > The business controls text plausibly would have allowed this use case
> also.
> >
> > I think a policy that does not allow a CA to support these use cases
> would
> > severly limit the use cases in which S/MIME could be used and I would
> like
> > to see them considered.
> >
> > Ryan Hurst
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FW: Complying with Mozilla policy on email validation

[Wayne Thayer via dev-security-policy]

On Tue, Apr 3, 2018 at 10:19 AM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Reading this thread and thinking the current text, based on the
> interpretation discussed, does not accommodate a few cases that I think are
> useful.
>
> For example, if we consider a CA supporting a large mail provider in
> providing S/MIME certificates to all of its customers. In this model, the
> mail provider is the authoritative namespace owner.
>
> In the context of mail, you can imagine gmail.com or peculiarventures.com
> as examples, both are gmail (as determined by MX records). It seems
> reasonable to me (Speaking as Ryan and not Google here) to allow a CA to
> leverage this internet reality (expressed via MX records) to work with a CA
> to get S/MIME certificates for all of its customers without forcing them
> through an email challenge.
>
> In this scenario, you could not rely on name constraints because the
> onboarding of custom domains (like peculiarventures.com) happens real
> time as part of account creation. The prior business controls text seemed
> to allow this case but it seems the interpretation discussed here would
> prohibit it.
>
> I agree that name constraints would be difficult to implement in this
scenario, but I'm less convinced that section 2.2(2) doesn't permit this.
It says:


*For a certificate capable of being used for digitally signing or
encrypting email messages, the CA takes reasonable measures to verify that
the entity submitting the request controls the email account associated
with the email address referenced in the certificate or has been authorized
by the email account holder to act on the account holder’s behalf.*

In this example, the entity submitting the request (Google) controls the
email account because it controls the server the MX record points to.

>
> Another case I think is interesting is that of a delegation of email
> verification to a third-party. For example, when you do a OAUTH
> authentication to Facebook it will return the user’s email address if it
> has been verified. The same is true for a number of related scenarios, for
> example, you can tell via Live Authentication and Google Authentication if
> the user's email was verified.
>
> The business controls text plausibly would have allowed this use case also.
>
> I'm not a fan of expanding the scope of such a vague requirement as
"business controls", and I'd prefer to have the CA/Browser Forum define
more specific validation methods, but if section 2.2(2) of our current
policy is too limiting, we can consider changing it to accommodate this use
case.

I think a policy that does not allow a CA to support these use cases would
> severly limit the use cases in which S/MIME could be used and I would like
> to see them considered.
>
> Ryan Hurst
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

There has been a lot of confusion about the transition to the new
standards, and I believe that this change makes it clearer that Mozilla no
longer accepts audits based on the older ETSI standards.

On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> European Conformity Assessment Bodies are nowadays issuing Audit
> Certificates aligned with EN 319 401, EN 319-411-1 and EN 319 411-2
> standards.
>
> There is no need to explicitly deny validity to previous standars, because
> as Jakob states, they can reflect the chain of audits.
>
> In fact, TS 102 042 and TS 101 456 are basically the same standards, but
> instead of changing only the version number, ETSI opted to renew the full
> reference code, more in the approach of IETF for RFCs.
>
> The Mozilla rule also is aligned with CAB Forum Baseline Requirements for
> the Issuance and Management of Publicly-Trusted Certificates and Extended
> Validation SSL Certificate Guidelines, and any change to those documents
> would need a ballot.
>
> This is the kind of confusion that I hope to avoid. Mozilla policy is not
aligned with the BRs now that Mozilla does not accept TS 102 042 and TS 101
456 audits.

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

Hi Ramiro,

On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan
>
> Thanks again for your remarks.
> In the end I am going to learn something of PKI :-).
> Surely I do not get a full understanding of you solution, but public
> administration is requiring a EU qualified Web certificate this means that
> should be included in the EUTL. I do know other solution for a new root but
> a new conformity assessment.
>
> If the "2016" roots are included in the EUTL, then they can be used to
sign ("cross-sign") a new "2018" root (or roots) that will then inherit the
trust from the "2016" root. From the perspective of the EUTL, the new root
would look like a new intermediate CA certificate.

Nevertheless, let me insist. In which aspects a new root 2018 improve our
> trustworthiness instead of the current root 2016?
>
> This is the wrong question to ask. For all the reasons stated in earlier
messages, the Mozilla community appears to have concluded that the 2016
roots are not trustworthy. If that is the case, then the proposal that you
create a new root answers the question that I think you should be asking:
"How can Camerfirma regain the community's trust?" Submitting a new root
that has been audited, has no history of misissuance, and complies in every
way with our policies has been proposed as one possible way to increase
confidence in your CA. If you have been following this mailing list, you
have seen that this same action has been recommended to other CAs that are
in this situation.


> Best Regards
> Ramiro
> ___
> 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

Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

Mozilla policy section 3.1.2.2 states:

ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> ending in July 2017 or earlier.
>

Now that we are past this deadline, I propose that we remove all references
to ETSI TS 102 042 and 101 456 from the policy.

This is: https://github.com/mozilla/pkipolicy/issues/108

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Permit issuance during change in ownership

[Wayne Thayer via dev-security-policy]

When the Francisco Partners acquisition of Comodo was announced, it was
pointed out [1] that a strict reading of the current policy section 8.1
would have forced Comodo to stop issuing certificates for some period of
time:

If the receiving or acquiring company is new to the Mozilla root program,
> there MUST be a public discussion regarding their admittance to the root
> program, which Mozilla must resolve with a positive conclusion before
> issuance is permitted.
>

I propose that we update section 8.1 to distinguish between root transfers
and acquisition of or investment in a CA organization, with the latter
cases allowing issuance to continue during the discussion period.

During the earlier discussion on this topic [1], it was also proposed that
we require the receiving or acquiring company to make no changes during the
discussion period and that we require all material changes anticipated as a
result of the investment or acquisition to be publicly disclosed by the CA.

This is: https://github.com/mozilla/pkipolicy/issues/109

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/AvGlsb4BAZo/gQe5ggE6BQAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma misissued certificates automated analysis results

[Wayne Thayer via dev-security-policy]

Thank you for sharing this information.

On Mon, Mar 26, 2018 at 9:24 AM, juanangel.martingomez--- via
dev-security-policy  wrote:

>
>
> We've done an automated analysis on 2018-03-13 of TSL/SSL certificates
> that have been issued by our CAs:
> - Camerfirma Corporate Server II - 2015
> - Camerfirma Corporate Server - 2009
> - AC CAMERFIRMA AAPP
>
> We discovered 81 certificates that we didn't discover in our previous
> manual analyzes of crt.sh. These misissued certificates were due to the
> fact that we had incorrect implementations of TSL/SSL certificates, each of
> the errors was previously corrected.
>
> The reasons why they are incorrect are:
> - (3) cablint ERROR commonNames in BR certificates must be from SAN entries
> - (1) cablint ERROR DNSName is not FQDN
> - (1) cablint ERROR DNSName is not in preferred syntax
> - (11) cablint ERROR Incorrectly encoded TeletexString in Certificate
> - (15) cablint FATAL ASN.1 Error in X520countryName: BER decoding failed
> at octet 0: Parse error
> - (30) cablint ERROR BR certificates must not contain directoryName type
> alternative name
> - (18) x509lint ERROR organizationName too long
> - (2) x509lint ERROR The string contains non-printable control characters
>
> For all of these certificates, the registration process of the domains and
> organizations included in them was carried out correctly.
>
> From the moment they were detected, we began the process of replacing them.
>
> There're 4 that have already expired.
>
> We've revoked 44 of the aforementioned certificates and we are in contact
> with the rest of the subscribing organizations to proceed with their
> substitution, given that most of them are Spanish public administration
> bodies that offer public services and they are unable to replace them in an
> agile way.
>
> I will expect this to be reflected on your next audit reports as a
violation of BR 4.9.1.1 (9).

All of these certificates are issued prior to the implementation of
> technical controls that eliminate the possibility of repeating the issuance
> of erroneous certificate with these errors.
>
> That is good news.

We've implemented at 2018-02-14 a technical control that prevents the
> issuance of a TSL/SSL certificate in case cablint or x509lint show an error
> of type 'FATAL' or 'ERROR' so it is expected that there are no new
> certificates with these errors issued by 'Camerfirma Corporate Server II -
> 2015'. 'AC CAMERFIRMA AAPP' & 'Camerfirma Corporate Server - 2009' are
> disabled for the issuance of certificates in our system.
>
> A report with the detected certificates is avaliable at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8962396
>
> Best Regards
> Juan Angel
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

[Wayne Thayer via dev-security-policy]

On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi  wrote:

>
> So, one aspect of this is the recently discussed risk - that is, a CA that
> provides value for only 10 users presents a substantial amount of risk to
> all Mozilla users, for both compromise and non-compliance. This is,
> admittedly, a subjective evaluation - but then again, so is trust. I'm
> curious whether the current "typical" language serves to establish a
> baseline bar for assesing the risk - that is, a CA that issues only one
> certificate a year, used by 100 Mozilla users, seems like a substantial
> risk to all Mozilla users.
>

Does the first sentence of section 7.1 address this concern? I proposed [1]
removing "benefits and" so that it reads:

7.1 Inclusions
>
> We will determine which CA certificates are included in Mozilla's root
> program based on the risks of such inclusion to typical users of our
> products.
>
 In other words, the proposed change to section 2.1(1) does not exclude
roots that fail to meet the "relevant to typical users" bar, but section
7.1 supports us in making decisions based on the risk to a typical user.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/commit/83b2164ff2594249800f40b0e7c00d0816ab77e7#diff-e516d71031639460d171d9f4d04a005b
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi  wrote:

>
> Looking through [1], it seems like the Compliance Date has only differed
> from the Publication Date once (with 2.0).
>
It's not clear to me that the 2.5 failure to adoption was related to
> ambiguity around compliance dates versus, say, CAs not being in compliance
> until directly chastised for non-compliance.
>
> I believe both causes factored into the 2.5 compliance issues, but agree
that this change only helps with ambiguity around Compliance Dates.

Thus, the deferral of 2 months is not entirely clear as to the reasoning.
> Could you speak more to the thinking behind that?
>
> To begin, I hope we can agree, even if we don't like it, that changes like
this often get done just before the deadline (I believe there is an
incentive for this behavior, but all that is necessary here is to accept
that it happens regularly). Then the question becomes "what is the
deadline?", and of course the answer is the Compliance Date. Then I ask how
the Compliance Date is set and communicated to CAs, and that's where I see
the problem. For the 2.5 version there was a discussion around phase-in
periods for specific changes [1], but as best I can tell the Publication
Date (and hence the Compliance Date) was not communicated in advance [2],
meaning that CAs had no deadline to work toward. In addition, there was no
indication that the policy changes were finalized prior to the Publication
Date, so CAs didn't have a stable policy to implement prior to the
Publication Date, at which point they were expected to already have
complied.

My thinking is that this situation encourages CAs to ignore the Compliance
Date and work on their own schedules, and that communicating a Compliance
Date that is some reasonable amount of time after the Publication Date
clarifies our expectations.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/VFvlhIFFVbA/tFD51RzMAQAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/lSyrFEkREZk/9c67Y7bNAQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TURKTRUST Non-compliance

[Wayne Thayer via dev-security-policy]

On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I think it's not going to be productive to spend a lot of time on the list
> debating whether or not a CA can opt out of full BR compliance by simply
> saying "we're winding down and won't issue certificates anymore". From
> Mozilla's perspective, any root in their trust stores needs to be held to
> the same standard.
>
> I agree. The prerequisites for recognizing a "wind-down CA" mode are at
least:
- BR updates that enable auditors to issue a report stating that the CA is
fully compliant with a "wind-down" mode of operations.
- Mozilla/Firefox CT policy/enforcement that ensures the CA can't simply
back-date certs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Wayne Thayer via dev-security-policy]

Jeremy filed the following incident report at
https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 :

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.

We received an email from Alex Cohen on March 9, 2018. It was posted
to the Mozilla list the next day

2.  A timeline of the actions your CA took in response.

a) 3/9/3018- Received an email from Alex cohen about the impacted certificates
b) 3/10/2018 - Revoked the certificates
c) 3/12/2018- Scanned database for any additional certificates. All
identified certificates were revoked
d) 3/12/2018 - Alex posted information to Mozilla list, and Jeremy
responded on what happened.
e) 3/14/2018 - Added error handling to detect when a tor descriptor is missing

Still to do: Add error handling to check that the cert has sufficient
tor descriptors - 1 per onion name.

3.  Confirmation that your CA has stopped issuing TLS/SSL certificates
with the problem.
DigiCert has stopped issuing onion certs that lack a descriptor

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.
20 certificates, all logged to CT, ranging from Oct 2017 to Mar 2018

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.https://crt.sh/?q=240277340 (revoked 26 October
2017)https://crt.sh/?q=261570255https://crt.sh/?q=261570338https://crt.sh/?q=261570380https://crt.sh/?q=261570384https://crt.sh/?q=261579788https://crt.sh/?q=261601212https://crt.sh/?q=261601280https://crt.sh/?q=261601281https://crt.sh/?q=261601284https://crt.sh/?q=261988060https://crt.sh/?q=326491168https://crt.sh/?q=326830043https://crt.sh/?q=328308725https://crt.sh/?q=328961187https://crt.sh/?q=329559222https://crt.sh/?q=330180704https://crt.sh/?q=351449233https://crt.sh/?id=351449246

6.  Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
> Looking into this, we did not correctly implement the ballot:
> 1. We didn't add a check to our backend system too verify the cert
> included a descriptor prior to issuance.
> 2. On the front end, we missed requiring a Tor descriptor prior to
> processing the order.
> 3. The validation team received insufficient training on the Tor
> descriptor requirement.

In reality, the issue was too much reliance on the human component of
asserting the Tor descriptors instead of having a technical control in
place. We have a central system that manages compliance. The checks
for onion certs were never added to this system. They exist now but
only to ensure a tor descriptor exists. We are still working on adding
checks to ensure at least one descriptor exists for each onion name.


7.  List of steps your CA is taking to resolve the situation and
ensure such issuance will not be repeated in the future, accompanied
with a timeline of when your CA expects to accomplish these things.

We revoked the certificates and added preliminary checking for Tor
descriptors. We are adding additional checks to ensure certs cannot
issue without them.



On Mon, Mar 19, 2018 at 5:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Interesting - this escaped our notice because it has a Tor descriptor.
> Unfortunately, it looks like the fetch function with v3 is not supported so
> we'll have to change how we pull and include the descriptor. Since the key
> is
> already in the cert, I agree there is nothing gain by including it, but I
> doubt there's strong incentives to change the guidelines right now. We'll
> modify to include it.
>
> -Original Message-
> From: Alex Cohn 
> Sent: Monday, March 12, 2018 6:55 PM
> To: Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert .onion certificates without Tor Service Descriptor
> Hash
> extension
>
> Thanks, Jeremy.
>
> I also found a certificate [1] with both 16-character.onion and
> 56-character.onion addresses [2] listed in the SAN. The v3 address is not
> included in the 2.23.140.1.31 extension, which seems to violate the same
> rule
> as below. However, v3 addresses include the service's entire public key in
> the
> address itself, so there's nothing to be gained by embedding a hash of that
> key in a certificate.
>
> I'm not sure what, if anything, needs to happen in this case. Thoughts?
>
> Alex
>
> [1] https://crt.sh/?id=351449246
> [2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt
>
> On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy
> 

Policy 2.6 Proposal: Update domain validation requirements

[Wayne Thayer via dev-security-policy]

Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4
domain validation methods. Now that 3.2.2.4.11 (“any other method”) has
been removed from the BRs and ballot 218 [1] has passed, the Mozilla policy
is out-of-date. I propose the following changes:

* Remove the reference to BR version 1.4.1 and instead require compliance
with the current version. With the adoption of ballot 190 [2], the
reference to version 1.4.1 is no longer needed.
* Remove the reference to "10" methods, since the number is likely to
change.
* Add a new bullet on IP Address validation that forbids the use of BR
3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
validation processes in the CA’s CP/CPS.
* Add the following language:

> Validation methods are occasionally found to contain security flaws. If
> this happens, Mozilla will communicate to CAs any disclosures or
> modifications it requires, up to and including discontinuing use of a
> method immediately.
>

I have intentionally not proposed a ban on methods 3.2.2.4.9 and 3.2.2.4.10
at this time. Work is underway in the IETF to fix method 10 [3], and I
suspect that the fix will be permitted under the existing 3.2.2.4.10
language. I’m proposing that we not make the use of any improved versions
of method 9 or 10 contingent on an update to our policy or on a BR change
that creates a new method number.

This is:
https://github.com/mozilla/pkipolicy/issues/121
https://github.com/mozilla/pkipolicy/issues/116
https://github.com/mozilla/pkipolicy/issues/115

[1] https://cabforum.org/2018/02/05/ballot-218-remove-
validation-methods-1-5/
[2] https://cabforum.org/2017/09/19/ballot-190-revised-
validation-requirements/
[3] https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

[Wayne Thayer via dev-security-policy]

A few months ago, we discussed our root inclusion criteria [1], and came to
a conclusion that I summarized and proposed in policy as follows:

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
>

Having just reviewed this again, I recommend that we also remove the word
“typical” from section 2.1(1) of the policy that reads:

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

This is: https://github.com/mozilla/pkipolicy/issues/118 and
https://github.com/mozilla/pkipolicy/issues/104

[1] https://groups.google.com/d/msg/mozilla.dev.security.
policy/GbXvh9ulboI/DWdJUc_cAQAJ

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

[Wayne Thayer via dev-security-policy]

This new version of the policy won’t be completed until after 15-April,
which is the revised deadline for disclosure and auditing of unconstrained
email subordinates. I propose removal of the following exception from
section 5.3.1:

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

This is: https://github.com/mozilla/pkipolicy/issues/120

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

Historically, the effective dates of new versions of the policy have been
maintained separately from the policy itself [1]. In our November
Communication, we learned that many CAs weren’t in compliance with policy
version 2.5 despite it having been in effect since June [2]. This proposal
is simply to add the Compliance Date to the policy itself, below the
version number, to make it more visible.

In addition, I propose that we adopt the norm of setting the Compliance
Date to 2 months after the Publication Date, to make it clearer that CAs
are expected to implement whatever changes are necessary no later than the
Compliance Date. This norm would not affect our ability to define more
specific Compliance Dates for specific changes to the policy.

This is: https://github.com/mozilla/pkipolicy/issues/117

[1] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
[2] https://groups.google.com/d/msg/mozilla.dev.security.policy/Bs3yRryKWFQ/
zJkUtz0GBAAJ

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
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]

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

TURKTRUST Non-compliance

[Wayne Thayer via dev-security-policy]

TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity certificates signed by this root [2]. The
audits for this root are either already expired (based on audit date) or
nearly expired (based on the ETSI certificate expiration date) [3] [4].

TURKTRUST announced the suspension of their SSL business in 2016 [5].

TURKTRUST failed to respond to the January 2018 CA Communication. After
repeated attempts, they did respond to my emails and posted a statement in
the bug [6] including the following:

The strategic decision mentioned above is actually suspending all SSL
> business supporting activities that incur direct costs for TURKTRUST,
> including suspending the ETSI and BR audits or OV and EV SSL related
> insurance policies. We have also ceased our investment and studies on CT
> and CAA requirements for the time being that are actually mandatory
> criteria set by the CA/Browser Forum.
>

TURKTRUST has chosen not to request removal of the root, but I believe this
is a clear case in which prompt removal of the root is necessary.

I would appreciate everyone's constructive input on what action should be
taken.

- Wayne

[1] https://crt.sh/?Identity=%25=5766=expired
[2] https://crt.sh/?Identity=%25=5767=expired

[3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
[4]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

[5] https://cabforum.org/pipermail/public/2016-September/008475.html

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi <r...@sleevi.com> wrote:

>
>
> On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>>
>> >
>> > Looking through [1], it seems like the Compliance Date has only differed
>> > from the Publication Date once (with 2.0).
>> >
>> It's not clear to me that the 2.5 failure to adoption was related to
>> > ambiguity around compliance dates versus, say, CAs not being in
>> compliance
>> > until directly chastised for non-compliance.
>> >
>> > I believe both causes factored into the 2.5 compliance issues, but agree
>> that this change only helps with ambiguity around Compliance Dates.
>>
>> Thus, the deferral of 2 months is not entirely clear as to the reasoning.
>> > Could you speak more to the thinking behind that?
>> >
>> > To begin, I hope we can agree, even if we don't like it, that changes
>> like
>> this often get done just before the deadline (I believe there is an
>> incentive for this behavior, but all that is necessary here is to accept
>> that it happens regularly). Then the question becomes "what is the
>> deadline?", and of course the answer is the Compliance Date. Then I ask
>> how
>> the Compliance Date is set and communicated to CAs, and that's where I see
>> the problem. For the 2.5 version there was a discussion around phase-in
>> periods for specific changes [1], but as best I can tell the Publication
>> Date (and hence the Compliance Date) was not communicated in advance [2],
>> meaning that CAs had no deadline to work toward. In addition, there was no
>> indication that the policy changes were finalized prior to the Publication
>> Date, so CAs didn't have a stable policy to implement prior to the
>> Publication Date, at which point they were expected to already have
>> complied.
>>
>> My thinking is that this situation encourages CAs to ignore the Compliance
>> Date and work on their own schedules, and that communicating a Compliance
>> Date that is some reasonable amount of time after the Publication Date
>> clarifies our expectations.
>
>
> So, in general, I think Mozilla policy has focused on actions CAs must
> take (such as notify Mozilla of incidents), rather than the profile of
> their certificates or a chance in scope of the BRs. The 10 blessed methods
> was an exception to that, as was the scope of audits for S/MIME - but those
> were exceptions, rather than the rule, and called out as such.
>
> I think it's reasonable - especially in light of the discussion being had
> regarding 2.6 and 3.2.2.4/3.2.2.5 - that when there are restrictions on
> the technical actions a CA must take or can use, that there be a phase in
> time, and what you say makes sense. But I think that's probably going to be
> the exception, and so it may be better to set the Compliance Date ==
> Publication Date by default, and then use the information gathering and
> discussion phase (which Mozilla policy requires all CAs to monitor) to
> identify if there are any surprises regarding phasing in changes.
>
> I am specifically thinking of CP/CPS updates, which were a major part of
the problem with version 2.5 compliance. There are a few proposals in the
2.6 queue that also require CP/CPS updates. Would you expect those to
trigger an exception as described above?

As a concrete example, consider the policy changes requiring CAs to follow
> m.d.s.p. That seems like something perfectly reasonable to expect immediate
> compliance to, and indeed, highly desirable (for any incidents that emerge
> within those two months until Compliance Date). Naively, it doesn't seem
> like it should take two months for a CA to be able to monitor m.d.s.p., or
> if it did, that may signal more problematic practices at play.
>

Again, the problem with this is that there is effectively no deadline when
policies are assumed to begin immediately upon publication. The same CAs
who take two months to begin monitoring m.d.s.p. when given a future
deadline are just as likely to begin monitoring it whenever they get around
to implementing the new policy during their next audit cycle if the
compliance deadline has already passed by the time they see that the policy
has been published.

>
>
To be clear, I'm fully onboard with integrating the compliance date to
> publication date, to avoid ambiguity. I am just putting forward the
> notation that, by default, Compliance Date == Publication Date, and then if
> there are reasonable concerns about the impact/challenges that 

Re: TURKTRUST Non-compliance

[Wayne Thayer via dev-security-policy]

Given that TURKTRUST has stated that the "TÜRKTRUST Elektronik Sertifika
Hizmet Sağlayıcısı H5" root is no longer being audited or complying with
new policies, I believe there is consensus that it should be removed from
the Mozilla root store. Kathleen will file a bug for that action.

Ryan suggested that the root also be added to OneCRL. I don't believe that
the current circumstances provide a strong argument for doing this, so
unless there is additional discussion I will not proceed with this proposed
action.

It has been proposed that we modify Mozilla policy to account for a
"wind-down" mode of operations. The counterpoint has been made that a root
hierarchy that is capable of issuance is as much of a risk as a root that
is issuing certificates. In this case the CA has stated that the decision
to suspend audits was based on the cost of those audits. I have doubts that
"wind-down" audits sufficient to address the risks inherent in a
non-issuing CA would be significantly less costly, even if the BRs made
provisions for them. Therefore, the only action I plan to take on this is
to ask the WebTrust Task Force for their opinion on "wind-down" audits, and
also to ask them if it is possible for a CA to obtain a period-of-time
audit for a hierarchy that hasn't issued any certificates in the period. I
will appreciate any additional suggestions that could help to resolve this
issue.

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

Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Recently I've received a few questions about audit requirements for
subordinate CAs newly issued from roots in our program. Mozilla policy
section 5.3.2 requires these to be disclosed "within a week of certificate
creation, and before any such subCA is allowed to issue certificates.", but
says nothing about audits.

The fundamental question is 'when must a new subCA be audited?' It is clear
that the TSP's [1] next period-of-time statement must cover all subCAs,
including any new ones. However, it is not clear if issuance from a new
subCA is permitted prior to being explicitly included in an audit.

I believe that it is common practice for TSPs to begin issuing from new
subCAs prior to inclusion in an audit. This practice is arguably supported
by paragraph 3 of BR 8.1 which reads:

If the CA has a currently valid Audit Report indicating compliance with an
> audit scheme listed in Section 8.1, then no pre-issuance readiness
> assessment is necessary.
>

When disclosing a new subCA, the TSP can select "CP/CPS same as parent" and
"Audits same as parent" in CCADB to indicate that the same policies apply
to the new subordinate as to the root.

This issue was raised at the CA/Browser Forum meeting in October 2016 [2].

Three options have been proposed to resolve this ambiguity:
1. Permit a new subCA to be used for issuance prior to being listed on an
audit report.
2. Require the TSP to attest that the new subCA complies with a set of
existing policies prior to issuance [3].
3. Require an audit report (point-in-time or period-of-time) covering the
new subCA before any issuance (possibly with an exception for test
certificates or certificates required for audit purposes).

Please consider these options in the context of a TSP with a current audit
for the parent root that has issued a new subCA, and for which the new
subCA is operating under existing policies and in an existing operational
environment. If this is not the case, I would propose that a new audit
covering the subCA be required.

This is #32 on the policy issues list [4].

I would like to request everyone's input on this topic. Based on our
discussion, I may propose that we address this issue in policy version 2.6.

- Wayne

[1] To avoid confusion, I've chosen to use the term Trust Service Provider
(TSP) to refer to the CA organization.
[2] https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-
39-minutes/#Disclosure-of-Subordinate-CAs

[3] https://cabforum.org/pipermail/public/2016-September/008464.html
[4] https://github.com/mozilla/pkipolicy/issues/32

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

Re: Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

[Wayne Thayer via dev-security-policy]

Hearing no objections, I've added this change to the 2.6 branch:
https://github.com/mozilla/pkipolicy/commit/5490d165f0d9b55cb75e5851303a21f9a250e199

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

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

[Wayne Thayer via dev-security-policy]

I've made the additional change proposed above to the 2.6 branch:
https://github.com/mozilla/pkipolicy/commit/13ce71ab3936e721236b8c9f8753f253fb7f3750


On Tue, Mar 20, 2018 at 2:23 PM, Ryan Sleevi <r...@sleevi.com> wrote:

> Ah, good point. Yeah, I think that's a perfectly reasonable change.
>
> On Tue, Mar 20, 2018 at 2:45 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>>
>> >
>> > So, one aspect of this is the recently discussed risk - that is, a CA
>> that
>> > provides value for only 10 users presents a substantial amount of risk
>> to
>> > all Mozilla users, for both compromise and non-compliance. This is,
>> > admittedly, a subjective evaluation - but then again, so is trust. I'm
>> > curious whether the current "typical" language serves to establish a
>> > baseline bar for assesing the risk - that is, a CA that issues only one
>> > certificate a year, used by 100 Mozilla users, seems like a substantial
>> > risk to all Mozilla users.
>> >
>>
>> Does the first sentence of section 7.1 address this concern? I proposed
>> [1]
>> removing "benefits and" so that it reads:
>>
>> 7.1 Inclusions
>> >
>> > We will determine which CA certificates are included in Mozilla's root
>> > program based on the risks of such inclusion to typical users of our
>> > products.
>> >
>>  In other words, the proposed change to section 2.1(1) does not exclude
>> roots that fail to meet the "relevant to typical users" bar, but section
>> 7.1 supports us in making decisions based on the risk to a typical user.
>>
>> - Wayne
>>
>> [1]
>> https://github.com/mozilla/pkipolicy/commit/83b2164ff2594249
>> 800f40b0e7c00d0816ab77e7#diff-e516d71031639460d171d9f4d04a005b
>> ___
>> 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: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Apologies. By choosing to use the term TSP when referring to an
organization operating a PKI, I thought I had made my meaning clear. I now
realize I inferred "certificate" when I used the term "subordinate CA". I
meant "subordinate CA certificate" in all cases where I wrote "subordinate
CA" or "subCA".

For reference, there has been an ongoing CA/Browser Forum discussion aimed
at disambiguating the term "CA":
https://cabforum.org/pipermail/policyreview/2016-May/000291.html

On Fri, Mar 23, 2018 at 4:08 PM, David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 3/23/2018 11:34 AM, Wayne Thayer wrote:
> > Recently I've received a few questions about audit requirements for
> > subordinate CAs newly issued from roots in our program. Mozilla policy
> > section 5.3.2 requires these to be disclosed "within a week of
> certificate
> > creation, and before any such subCA is allowed to issue certificates.",
> but
> > says nothing about audits.
>
> "CA" = "certification authority"
>
> Do you really mean "subordinate certification authorities newly issued
> from roots"?  If so, what does that mean?  Or do you mean "subordinate
> certificates newly issued from roots"?
>
> I do not really want to be picky.  However, when dealing with something
> as important as Internet security, being picky is mandatory.
>
> --
> David E. Ross
> 
>
> President Trump:  Please stop using Twitter.  We need
> to hear your voice and see you talking.  We need to know
> when your message is really your own and not your attorney's.
> ___
> 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: Policy 2.6 Proposal: Update domain validation requirements

[Wayne Thayer via dev-security-policy]

I've drafted these changes:
https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8

On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek 
wrote:

>
> > * Add a new bullet on IP Address validation that forbids the use of BR
> > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
> > validation processes in the CA’s CP/CPS.
>
> This is a bit premature.  Most CA's IP validation procedures still fall
> under
> any other method, and the draft ballot that we've been trying to pass
> for a year or so is not done yet (I was writing it when the Validation
> Summit started taking over my life...)  There's a good chance we will
> get a ballot passed on this issue this summer, but there's also a good
> chance that work on improving the non-IP validation methods will be
> prioritized above it.
>
> It might make sense, though, to require that if you use 3.2.2.4.8, you
> cannot use 3.2.2.5(4).  That would eliminate the ability to use .5(4) to
> validate domain names.
>
> My commit includes this compromise.

The IP validation disclosure language is fine and would actually help
> get a ballot passed.  I've been trying to get everyone to disclose their
> IP validation practices and whether they issue IP certificates, but it
> turns out that "the CABF Validation Chair is politely asking for your
> cooperation" has some positive impact, but is mostly ignored.
>
> This is the new 2.2 (4) in my commit.

I think disclosure and eliminating the loophole that allows IP validation
> method risk to bleed into domain names is a good place to start.
>
> -Tim
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

On Wed, Mar 21, 2018 at 2:43 AM, Ryan Sleevi <r...@sleevi.com> wrote:

>
>
> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>>
>> > I am specifically thinking of CP/CPS updates, which were a major part of
>> the problem with version 2.5 compliance. There are a few proposals in the
>> 2.6 queue that also require CP/CPS updates. Would you expect those to
>> trigger an exception as described above?
>>
>
> Yup, I think it totally makes sense to phase those in, since they first
> need to be finalized (via Publication) before CAs can fully update to be
> conformant.
>

Assuming those CP/CPS requirements make it into the 2.6 version, I will
plan to propose setting the Compliance Date for this specific version to be
2 months after the Publication Date, while not changing the default of
setting them to the same date for future versions of the policy. I think
that addresses both of our concerns.

I think we both agree that compliance with 2.5 was a problem that we'd
>> like to address. I've put forth the argument that having Compliance Date >
>> Publication Date could help to improve that. Do you disagree with my
>> assertion, or simply feel that on balance it is better to have new
>> policies
>> enacted sooner but with less compliance? Maybe a better solution would be
>> to ask CAs to attest to their compliance via a survey each time we publish
>> a new policy version?
>
>
> I don't think having Compliance Date > Publication Date will, in general,
> help for situations of CAs being non-compliant. I think it will help with
> some things - if their non-compliance was due to, for example, updating
> systems or CP/CPSes - but I think it will harm other things - e.g. CAs
> monitoring m.d.s.p. or disclosing certain things.
>
> Regarding CAs attesting to compliance, I think that will help, but not
> because of the Compliance Date or Publication Date. Rather, it will help
> because no matter what we do or say, there are a subset of CAs who simply
> will not and do not spend time following m.d.s.p. and only reply to emails
> and only after several emails have gone by and only after being shamed at
> the risk of distrust.
>

I agree, and will plan to send a CA Communication when the new version is
published.
___
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 domain validation requirements

[Wayne Thayer via dev-security-policy]

Tim,

On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek 
wrote:

>
> > * Add a new bullet on IP Address validation that forbids the use of BR
> > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
> > validation processes in the CA’s CP/CPS.
>
> This is a bit premature.  Most CA's IP validation procedures still fall
> under
> any other method, and the draft ballot that we've been trying to pass
> for a year or so is not done yet (I was writing it when the Validation
> Summit started taking over my life...)  There's a good chance we will
> get a ballot passed on this issue this summer, but there's also a good
> chance that work on improving the non-IP validation methods will be
> prioritized above it.
>
> This seems to contradict your comment in issue 116 [1]:

I think the solution to Ryan's issue is to remove 3.2.2.5 (4). The VWG is
> currently discussing changes to 3.2.2.5 (in order to remove 3.2.2.5 (4)),
> and we haven't heard of any CA that is using it, though we should check the
> smaller ones.
>
It's possible 3.2.2.5 (4) could be removed with an aggressive timeline if
> it's really true no one is using it.
>
It would be great to hear from CAs on the impact they would feel from
Mozilla banning 3.2.2.5(4) prior to passage of the VWG ballot you mentioned.

- Wayne

[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: TURKTRUST Non-compliance

[Wayne Thayer via dev-security-policy]

Jakob,

On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/03/2018 01:23, Wayne Thayer wrote:
>
> Note, that if it is reasonably certain/validated that the only activity
> is maintaining CRLs/OCSP for the remaining unexpired certificates, then
> most of the updated BR requirements (such as CAA, CT and stricter
> validation methods) become noops, since no validations are being done,
> no CAA strings are accepted, no new certificates are issued etc.
>
> I agree in practice, but if a WebTrust audit were to be conducted it would
contain a number of qualifications, or as is the case here, no ETSI audit
statement would be issued.

We may thus be looking at the 12 months of an orderly shutdown of a
> CA, as per section 5.8 of the standard CPS template, and might
> reasonably consider accepting the lack of normal activity levels for
> such a situation.  The BRs and Mozilla policy seem silent on the
> subject,
>
> Are you suggesting that we delay removal of this root until all leaf
certificates expire?

Are you suggesting that the BRs be modified so a CA that has ceased
issuance can obtain a clean audit report without meeting all current BR
requirements?

The only critical thing that seems to be missing is a BR audit report to
> confirm that no issuance is taking place and the revocation management
> and CA private key protection is still being done properly.
>
> Continued audit reports are indeed critical to maintaining trust in a CA
even after it has ceased issuance.

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

Re: Logius PKIoverheid response to Action #2 in the January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Thank you for the response Jochem. I am glad to hear that Logius has
evaluated the risk and, given the passage of ballot 218, is moving to other
methods of domain validation.

- Wayne

On Fri, Mar 16, 2018 at 5:55 AM, Berge, J. van den (Jochem) - Logius via
dev-security-policy  wrote:

> Dear MSDP community,
>
> As requested by Mozilla in the CA Communication survey we've reviewed our
> implementation of BR 3.2.2.4.1 and 3.2.2.4.5. PKIoverheid only issues OV/EV
> certificates to subscribers for which the applicant representative has to
> have had a face-to-face check to confirm the identity of the representative
> (regardless of which method from 3.2.2.4 is used). The applicant
> representatives are defined beforehand by the applicant (authority is
> granted by a managing director, who's authority is checked against the
> national trade register). The issuing TSPs all use a secured environment in
> which the subscriber can order certificates. PKIoverheid certificates are
> mainly issued to Dutch subscribers. The Dutch Chamber of Commerce (de facto
> the national agency as referred in BR 3.2.2.1) only allows unique
> organization names, and as mentioned before, the TSP has a complete file of
> the applicant and it representative(s). In case that there is doubt about
> the authority of the applicant (whether us
>  ing method 3.2.2.4.1 or 3.2.2.4.5), another method from 3.2.2.4 is used
> instead. Therefore, the scenario as described earlier on the web (for
> instance, the Stripe, Inc. case) is, in our eyes, very unlikely. However,
> the PKIoverheid TSPs are now moving away from these methods per ballot 218.
>
> Please let me know if you have any questions.
>
>
> Kind regards,
>
> Jochem van den Berge
>
> Logius PKIoverheid
> Public Key Infrastructure for the Dutch government
> 
> Logius
> Ministry of the Interior and Kingdom Relations (BZK)
> Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
> PO Box 96810 | 2509 JE | The Hague
> 
> jochem.vanden.be...@logius.nl
> http://www.logius.nl
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
> ___
> 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: Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

I would summarize this discussion as follows:
- we'll add the Compliance Date to the policy document [1].
- the existing norm of setting the Compliance Date equal to the Publication
Date will remain.
- during final review of new versions of the policy, we will discuss any
changes that need to be made to the Compliance Date for the entire version
or individual changes.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/commit/60e340635e31651208ea1c92f4e37295e6285950#diff-b7447c83436e3b067c828eb47cb80282
)

On Wed, Mar 21, 2018 at 10:09 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 21/03/2018 10:43, Ryan Sleevi wrote:
>
>> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> I think it's reasonable - especially in light of the discussion being had
>>>> regarding 2.6 and 3.2.2.4/3.2.2.5 - that when there are restrictions on
>>>> the technical actions a CA must take or can use, that there be a phase
>>>> in
>>>> time, and what you say makes sense. But I think that's probably going to
>>>>
>>> be
>>>
>>>> the exception, and so it may be better to set the Compliance Date ==
>>>> Publication Date by default, and then use the information gathering and
>>>> discussion phase (which Mozilla policy requires all CAs to monitor) to
>>>> identify if there are any surprises regarding phasing in changes.
>>>>
>>>> I am specifically thinking of CP/CPS updates, which were a major part of
>>>>
>>> the problem with version 2.5 compliance. There are a few proposals in the
>>> 2.6 queue that also require CP/CPS updates. Would you expect those to
>>> trigger an exception as described above?
>>>
>>>
>> Yup, I think it totally makes sense to phase those in, since they first
>> need to be finalized (via Publication) before CAs can fully update to be
>> conformant.
>>
>>
>> As a concrete example, consider the policy changes requiring CAs to follow
>>>
>>>> m.d.s.p. That seems like something perfectly reasonable to expect
>>>>
>>> immediate
>>>
>>>> compliance to, and indeed, highly desirable (for any incidents that
>>>>
>>> emerge
>>>
>>>> within those two months until Compliance Date). Naively, it doesn't seem
>>>> like it should take two months for a CA to be able to monitor m.d.s.p.,
>>>>
>>> or
>>>
>>>> if it did, that may signal more problematic practices at play.
>>>>
>>>>
>>> Again, the problem with this is that there is effectively no deadline
>>> when
>>> policies are assumed to begin immediately upon publication. The same CAs
>>> who take two months to begin monitoring m.d.s.p. when given a future
>>> deadline are just as likely to begin monitoring it whenever they get
>>> around
>>> to implementing the new policy during their next audit cycle if the
>>> compliance deadline has already passed by the time they see that the
>>> policy
>>> has been published.
>>>
>>>
>> I'm not sure I understand this point. The deadline is immediate. I was
>> trying to highlight that with an immediate deadline, there's no excuse for
>> taking two months to monitor m.d.s.p. - but that's ok, because it doesn't
>> seem reasonable to take two months to begin with. Any CA out of compliance
>> is in an egregious breach of confidence at that point - especially if they
>> wait until their next audit cycle.
>>
>>
>> I think we both agree that compliance with 2.5 was a problem that we'd
>>> like to address. I've put forth the argument that having Compliance Date
>>> >
>>> Publication Date could help to improve that. Do you disagree with my
>>> assertion, or simply feel that on balance it is better to have new
>>> policies
>>> enacted sooner but with less compliance? Maybe a better solution would be
>>> to ask CAs to attest to their compliance via a survey each time we
>>> publish
>>> a new policy version?
>>>
>>
>>
>> I don't think having Compliance Date > Publication Date will, in general,
>> help for situations of CAs being non-compliant. I think it will help with
>> some things - if their non-compliance was due to, for example, updating
>> systems or CP/CPSes - but I think it will harm other things - e.g. CAs
>> monitoring m.d.s.p. or disclosing certain things

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

Thanks everyone for your input on this topic. The consensus seems to be
that allowing WebExtensions to muck with certificate validation decisions
is a bad idea. The bug [1] has been updated with that sentiment and a link
to this discussion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
___
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]

Update:

Mozilla is moving forward with our implementation of the consensus plan for
Symantec roots [1]. With the exception of whitelisted subordinate CAs using
the keys listed on the wiki [2], Symantec certificates are now blocked by
default on Nightly builds of Firefox. The preference
"security.pki.distrust_ca_policy" can be used to override these changes. A
custom error message is also being implemented [3]. These changes are part
of Firefox 60, which is scheduled to be released in May [4].

There are still a lot of websites using Symantec certificates, but the
number are declining rapidly. Lists of affected sites and regularly updated
metrics are available via bug 1434300 [5].

- Wayne

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/
90qkf8jsAQAJ
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1441223
[4] https://wiki.mozilla.org/RapidRelease/Calendar
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1434300
___
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 Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie 
wrote:

> Hi Wayne,
>
> Is the Firefox 60 update in May the same as the combination of the April
> and October Chrome updates, in that all Symantec certificates will be
> untrusted on this date (5 months before Chrome)?
>
> Sorry for not making that clear Doug. Firefox is implementing the
consensus plan as originally described, meaning that Firefox 60 only blocks
Symantec certificates issued prior to 1-June 2016. We plan to remove that
restriction in Firefox 63.

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

AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT -
2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented
in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=986854

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

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

* Root Certificate Download URL:
http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/

* CP/CPS:
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_v_1_2_1_EN.pdf

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

* EV Policy OIDs: 1.3.6.1.4.1.17326.10.16.3.5.1 (CCR2016),
1.3.6.1.4.1.17326.10.8.12.1.2 (GCSR2016)

* Test Websites
  * CCR2016:
https://cev.camerfirma.com expired
https://cevrv.camerfirma.com revoked
https://cevok.camerfirma.com valid

  * GCSR2016:
https://csev.camerfirma.com expired
https://csevrv.camerfirma.com revoked
https://csevok.camerfirma.com valid

* CRL URLs:
CCR2016: http://crl.camerfirma.com/chambersofcommerceroot-2016.crl
GCSR2016: http://crl.camerfirma.com/globalchambersignroot-2016.crl

* OCSP URLs:
http://ocsp.camerfirma.com/

* Audit: Annual audits are performed by AUREN according to the WebTrust for
CA, EV, and BR audit criteria.
WebTrust: https://bugzilla.mozilla.org/attachment.cgi?id=8890729
BR: https://bugzilla.mozilla.org/attachment.cgi?id=8890727
EV: https://bugzilla.mozilla.org/attachment.cgi?id=8890726


I’ve reviewed the CPS, BR Self Assessment, and related information for the
CCR2016 and GCSR2016 inclusion requests that are being tracked in this bug
[1] and have the following comments:

==Good==
* Subordinate CAs issued under these roots are constrained to specific
purposes via EKU.
* Audit reports include English translations and contain most of the
required information, with the exception of SHA-256 fingerprints and the
full address of the auditor.
* The CA hierarchies and applicable usages and policies are clearly
described in section 1.2 of the CPS.

==Meh==
* Camerfirma has had a number of recent compliance issues as listed below:
Resolved:
* Non-BR-compliant OCSP responders:
https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
* CAA checking failure:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871
* Duplicate SANs and without localityName or stateOrProvinceName:
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067
* Invalid DNS Names:
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 (just resolved today)
Still Open:
* Non-printable characters in OU field:
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 (this issue was
reported by Camerfirma)
* CPS [5] section 1.2.1.1 appears to exempt test certificates from BR
requirements.
* Section 3.1.8.2.2 of the CPS implies that CAA checking is done manually.
While this isn’t forbidden, it is easily susceptible to errors.
* CPS section 1.2.1.4.1.3 states that the GCSR2016 “is only used for the
purpose of carrying out the accreditation processes with different
browsers.” We recently decided to relax the requirements for inclusion, but
this statement does imply that there is no value to Mozilla users in
enabling the websites trust bit for this root.
* CPS section 1.5.5 indicates that delegated RAs are permitted, but it does
not clearly indicate that domain validation functions may not be delegated.
* CPS section 2.5.3 states that “Camerfirma currently offers the OCSP
service free-of-charge but reserves the right to invoice for these
services.” If OCSP service were to be blocked for all but paying users, I
believe that would be a BR violation.

==Bad==
* The inclusion request references a much older CPS [3] that doesn't list
the 2016 versions of these roots or comply with current policies. I only
reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the
older roots that are currently included. I believe this is a compliance
issue with the currently included AC Camerfirma roots.
* I am unable to locate a BR audit for the GCSR2016, but the websites trust
bit has been requested. I first thought that this root was not intended for
serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC
CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root.
Both roots are covered by the latest EV audit.
* Last year, Camerfirma signed a contract with StartCom as a delegated RA.
While I don’t believe the Startcom distrust plan [2] specifically forbade
this, it was found that Camerfirma was not performing domain validation on
the OV certificates [4] as required by the BRs.
* The BR section 2.2 requirement that “The CA SHALL publicly give effect to
these Requirements and represent that it will adhere to the latest
published version” is not clearly stated in the CPS. Also, the final
paragraph of section 1.2 implies that the CPS takes precedence over BR

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:
>
> [snipped]
>
> NOTE: The fact that I have snipped some of the items under "==Bad=="
> does not mean I consider them unimportant. However, the items on
> which I comment I consider to be most important.
>
> > ==Bad==
> > * The inclusion request references a much older CPS [3] that doesn't list
> > the 2016 versions of these roots or comply with current policies. I only
> > reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover
> the
> > older roots that are currently included. I believe this is a compliance
> > issue with the currently included AC Camerfirma roots.
>
> Is the above not sufficient to terminate the public review?
>
> My comment may be confusing. The newer CPS specifically covers the roots
we're discussing, and the CPS is compliant with policy with the exception
of things noted in other comments. I would like Camerfirma to comment on my
conclusion about the older CPS and it's applicability to the older roots.

[snipped]
>
> > * Last year, Camerfirma signed a contract with StartCom as a delegated
> RA.
> > While I don’t believe the Startcom distrust plan [2] specifically forbade
> > this, it was found that Camerfirma was not performing domain validation
> on
> > the OV certificates [4] as required by the BRs.
>
> I would strongly suggest that further action be deferred until the cited
> contract can be confirmed to have been terminated.
>
> I would like to hear from Camerfirma on this, but StartCom did announce
that they have "terminated the company":
https://groups.google.com/d/msg/mozilla.dev.security.policy/DxbMjAN7VbY/VJ0W9LQhBwAJ


> [snipped]
>
> > * There are a few published, misissued, and currently unrevoked
> > certificates in the CCR2016 hierarchy:
> > https://crt.sh/?caid=50473=cablint,zlint,x509lint;
> minNotBefore=2011-01-01
>
> If Camerfirma had been already approved and its root added to the RSS
> database, would not the above item be sufficient to remove that root?
>
> It would be treated as an incident, but in isolation seems unlikely to
rise to the level of root removal.

[snipped]
> --
> David E. Ross
> 
>
> President Trump:  Please stop using Twitter.  We need
> to hear your voice and see you talking.  We need to know
> when your message is really your own and not your attorney's.
> ___
> 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: potential audit delay due to issue with CPA Canada

[Wayne Thayer via dev-security-policy]

If you have the letters from your auditor, you can upload them as an
attachment to a Bugzilla bug, then submit the links in your CCADB audit
case. It's preferable to be able to verify the audit letters via the seal
on the WebTrust site, but Mozilla doesn't require it - we can contact the
auditor directly for confirmation.

- Wayne

On Mon, Feb 26, 2018 at 8:29 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, February 26, 2018 at 8:30:54 PM UTC-6, jo...@letsencrypt.org
> wrote:
> > We (ISRG / Let's Encrypt) have completed our 2017 WebTrust audits, the
> letters are written and signed, but CPA Canada is unable to process our
> final seals due to a personnel issue on their end. Nobody who can sign off
> is available, and apparently it could take another 2+ weeks for them to
> resolve the issue, which could bring us close to the deadline.
> >
> > What would the root programs like us to do if CPA Canada is not able to
> perform in the required amount of time? I expect in the worst case the
> seals would be less than a month late.
> >
> > -Josh Aas
>
> It has been pointed out to me that Section 8.6 of the BRs says:
>
> "In the event of a delay greater than three months, and if so requested by
> an Application Software Supplier, the CA SHALL provide an explanatory
> letter signed by the Qualified Auditor."
>
> That being the case, we will provide the explanatory letter if one is
> requested.
> ___
> 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: Code signing and malware

[Wayne Thayer via dev-security-policy]

The article also claims that bad actors are selling EV SSL certificates
that they obtain for real companies without their knowledge:

"to guarantee the issuance and lifespan of the products, all certificates
are registered using the information of real corporations. With a high
degree of confidence, we believe that the legitimate business owners are
unaware that their data was used in the illicit activities. It is important
to note that all certificates are created for each buyer individually with
the average delivery time of two to four days."

Wayne

On Mon, Feb 26, 2018 at 2:27 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I just came across this:
>
> https://www.recordedfuture.com/code-signing-certificates/
>
> I think the most important part of it is: "we confirmed with a high degree
> of certainty that the certificates are created for a specific buyer per
> request only and are registered using stolen corporate identities"
>
>
> Kurt
> ___
> 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: Need remove OISTE WISeKey Global Root GA CA?

[Wayne Thayer via dev-security-policy]

The test site for the root referenced in bug 1172819 is working fine in
Firefox: https://gbvalidssl.hightrusted.com/

I am not able to locate any gov.sc websites properly configured for HTTPS
to test.

- Wayne

On Sat, Feb 24, 2018 at 3:45 AM, westmail24--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1172819#c9
>
> I tested the root certificate is OISTE WISeKey Global Root GA CA on gov.sc
> websites and it does not work anymore: red SSL icon is displayed.
>
> I contacted with WISeKey via i...@wisekey.com one week ago on this issue,
> but the answer was not received.
> ___
> 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: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> > <dev-security-policy@lists.mozilla.org> wrote:
> >
> >> This capability existed in the legacy Firefox extension system that
> >> was deprecated last year. It was used to implement stricter security
> >> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> >> such as Certificate Transparency and DANE.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
>

In the bug I referenced as [2], people said that they specifically need to
be able to override "negative" certificate validation decisions, so they
may not see this as a compromise. I think an example would be a site
serving a self-signed certificate for a DANE add-on to validate.

>
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
>
> I assume that by "downgrade", Hanno meant "change the UI to indicate a bad
cert" and by "upgrade" he meant "indicate a valid cert in the UI when
validation has failed".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com>
wrote:

>
> > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> This request has been in public discussion for more than 6 months, so I
> >> would like to make a decision soon. If you have comments or concerns
> with
> >> this request, please post them here by 6-March 2018.
> >
> > Given the misissued certificates in CT under the existing root, I
> believe this request should be rejected, and a new clean root with audits
> should be required before moving forward.
> >
>
This course of action doesn't seem consistent with our treatment of the
many included CAs that have experienced these problems.


> > The errors in the issued certificates indicate a lack of technical
> controls in addition to improperly implemented certificate profiles. Given
> this, an explanation should also be provided of what changes have been made
> to the issuance environment to ensure these types of mistakes will not
> happen under the new root.
>
> I just took a closer look at the thread, and it appears that some
> misissuance was pointed out in July and most of the controls that were
> suggested as a solution relied on humans. These controls appear to have
> predictably failed, as multiple misissued certificates are from this fall,
> well after the fixes should have been in place.
>
> Olfa's most recent response indicates that additional/technical controls
were added this week. However, I'm not convinced that they are adequate.
___
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 Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > "I would like to again point out that simply waiting for misissued
> > certificates to expire is not an acceptable response."
> >
> > This is a misunderstanding.
> > We are preparing to revoke certificates immediately, rather than waiting
> > for certificates issued prior to 2017 to expire.
> > However, even if we revoke those certificates, if your judgment is not
> > affected and our request is rejected, there is no point in doing it.
> >
>
> So, to be clear, you would only revoke misissued certificates if required
> to do so by Mozilla -- not because they represent control failures, or in
> order to demonstrate to other root programs your CA's responsiveness and
> the seriousness with which you take control failures.
>
>
> > Please let us know if our request will be accepted by revoking all the
> > certificates we issued prior to 2017.
>
> My comment was intended to point out that you are violating BR section
4.9.1.1(9) by not revoking these certificates. My comments were not
intended to imply that revoking these certificates would change Mozilla's
decision to deny this inclusion request.

>
> > Thank you
> > APCA
> >
>
___
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]

To conclude this discussion, Mozilla is denying the Japanese Government
ApplicationCA2 Root inclusion request.  I'd like to thank everyone for your
constructive input into the discussion, and I'd like to thank the Japanese
Government representatives for their patience and work to address issues as
they have been discovered. I will be resolving the bug as "WONTFIX".

The Japanese Government PKI may submit a newly generated root and key-pair
for inclusion, and this submission can be made using the existing bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=870185).

On Thu, Feb 22, 2018 at 11:57 PM, apca2.2013--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We are a certificate authority controlled by the Government of Japan and
> issued only for servers operated by the government.
>
> For certificates that you point out concerning, they will expire and will
> be reissued, so we think that the problem will be solved.
>
> I would like to again point out that simply waiting for misissued
certificates to expire is not an acceptable response.


> We will continue to take BR audits in the future so we will operate as a
> secure certification authority and we appreciate your continued support.
>
> - 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: Require CAs to support problem reports via email

[Wayne Thayer via dev-security-policy]

On Fri, Apr 20, 2018 at 12:33 PM, Wayne Thayer  wrote:

> At this point we have a few choices:
>
> 1. Do nothing about requiring email as a problem reporting mechanism.
> Instead, take on the related issues of disclosure of the reporting
> mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or
> both.
> 2. Go ahead with the proposal to require email, but allow CAs to require
> some special, but standardized identifier be placed in the message that
> they can filter on. For example, CAs could ignore messages sent to their
> problem reporting address unless the subject contains the phrase "problem
> report".
> 3. Develop some new problem reporting mechanism that solves the problems
> with email and forms. For example, we could require CAs to accept problem
> reports posted to this list, but build in some additional time in which to
> "receive" the report by reading list messages. Or we could require CAs to
> accept problem reports via Bugzilla. We already see problems being reported
> via these mechanisms and require CAs to monitor both of them, just not on a
> 24x7 basis.
>
> The first option ('do nothing') is currently in the lead, so I would
> especially like to hear from anyone who wants to argue for a different
> solution.
>
>
This discussion has resulted in no agreed-upon changes to the Mozilla
policy. I will close the issue on GitHub [1], and I also plan to propose a
CAB Forum ballot that includes the requirement for CAs to disclose their
problem reporting mechanism in section 1.5.2 of their CPS.

- Wayne

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

Re: Unrevoked/unexpired certificate with Debian Weak Key

[Wayne Thayer via dev-security-policy]

I searched through the list of certificates that Rob provided and didn't
find any new issues (no valid certificates and none that had been issues
since Jan 1, 2017 and not previously disclosed.

I've requested an incident report from QuoVadis for the one new certificate
that Hanno identified via
https://bugzilla.mozilla.org/show_bug.cgi?id=1472052

- Wayne

On Mon, Jun 18, 2018 at 6:57 AM Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sorry -- digging into that 500 was on my plate, but there was a logging bug
> on errors... and then some poor docs for the framework I'm using... and
> before you know it, the yak stack was piled high. I'll cycle around to that
> again this evening.
>
> Alex
>
> On Mon, Jun 18, 2018 at 9:53 AM Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote:
> > > On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling
> > >> I'm currently running the check against all of the certs on the crt.sh
> > >> DB.  I'll report back once this has completed.
> > >
> > > Hi Rob,
> > >
> > > Did your checks find anything else in the end?
> >
> > Hi Daniel.  Thanks for the reminder.  :-)
> >
> > I found a total of 1,589 certs on the crt.sh DB with Debian weak keys,
> > and I did intend to publish a report.  I figured that creating a new
> > batch on misissued.com would be the best way to present the data, but
> > that gives me an HTTP 500 response whenever I try to submit the list of
> > crt.sh IDs.
> >
> > Until misissued.com lets me submit the list, you can find the list of
> > affected certs in a table on the crt.sh DB called "has_debian_weak_key".
> >
> > --
> > Rob Stradling
> > Senior Research & Development Scientist
> > Email: r...@comodoca.com
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

GlobalSign Root CA - R6 Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the GlobalSign Root CA - R6 as documented
in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390803
This is an RSA-4096 / SHA-384 root that GlobalSign states “…will replace
older, expiring roots that have smaller key sizes in the future.”

* BR Self-Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8941595

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

* Root Certificate Download URL:
http://secure.globalsign.com/cacert/root-r6.crt

CP/CPS:
** CP:
https://downloads.globalsign.com/acton/attachment/2674/f-0b47/1/-/-/-/-/GlobalSign_CP_v5.8.pdf
** CPS:
https://downloads.globalsign.com/acton/attachment/2674/f-0b46/1/-/-/-/-/GlobalSign_CA_CPS_v8_8_RELEASED.pdf

* 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:
** https://valid.r6.roots.globalsign.com/
** https://revoked.r6.roots.globalsign.com/
** https://expired.r6.roots.globalsign.com/

* CRL URL: http://crl.globalsign.com/root-r6.crl

* OCSP URL: http://ocsp2.globalsign.com/rootr6

Audit: Annual audits are performed by BDO and Ernst & Young according to
the WebTrust for CA, BR, and EV audit criteria.
* WebTrust: https://cert.webtrust.org/SealFile?seal=2287=pdf

* BR:
** April 1, 2016 - March 31, 2016:
https://bug1390803.bmoattachments.org/attachment.cgi?id=8980269 (EY - clean)
** April 1, 2016 - March 31, 2017:
https://downloads.globalsign.com/acton/attachment/2674/f-08b8/1/-/-/-/-/GlobalSign-WTBR-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf
(BDO - qualified)
** April 1, 2017 - September 18, 2017:
https://downloads.globalsign.com/acton/attachment/2674/f-0960/1/-/-/-/-/GlobalSign-WTEY-Indp-Assurance-Report-FINAL-2017.pdf
(EY - clean)

* EV: https://cert.webtrust.org/SealFile?seal=2288=pdf (BDO - clean)

I’ve reviewed the CP and CPS, BR Self Assessment, and related information
for the GlobalSign Root CA - R6 inclusion request that is being tracked in
this bug and have the following comments:

==Good==
* While this root was created in 2014, it does not appear to have been used
beyond issuing test certificates.
* The CP and CPS state “GlobalSign CA expressly forbids the use of chaining
services for MITM (Man in the Middle) SSL/TLS deep packet inspection.“
* I found GlobalSign’s CP and CPS well structured and easy to understand
(despite the fact that some sections, such as 3.2.2.4 and 3.2.2.5 fail to
align with the BRs).
* CPS section 3.2.8 documents email address validation methods in
compliance with the new 2.6 version of the Mozilla root store policy

==Meh==
* The 2016-2017 BR audit contains two qualifications. One is described as
follows:

Management discovered a bug that allowed orders that are re-issued with
modified domains within the Subject Alternative Name field of the
certificate to not include the Key Usage (KU) or Extended Key Usage (EKU)
extensions. This occurred between August 29 , 2016 and September 19, 2016.
Management noted 68 Certificates were affected, 4 of these are extended
validation certificates and 64 are organization validation certificates.
Management was not able to revoke all certificates within 24 hours, due to
customer requirements.

GlobalSign disclosed this problem at the time [1]. The other qualification
in the report is related to data backups. GlobalSign had another BR audit
conducted later in 2017, resulting in a clean report.
* GlobalSign was the subject of 4 misissuance bugs in 2017, as follows. All
have been resolved and this root was not involved in any of them.
** Bug 1353833 - GlobalSign: Incapsula issued a certificate for
non-existing domain (testslsslfeb20.me)
** Bug 1390997 - GlobalSign: Non-BR-Compliant Certificate Issuance -
metadata-only subject fields
** Bug 1393555 - GlobalSign: Non-BR-Compliant Certificate Issuance --
double-dots in dnsName
** Bug 1393557 - GlobalSign: Non-BR-Compliant Certificate Issuance -- RSA
key smaller than 2048 bits
* Minor CP and CPS issues were identified, noted in the bug, and fixed by
GlobalSign in the current versions.
* CPS section 3.2.7 indicates that GlobalSign uses “any other method” for
IP address validation. GlobalSign responded as follows In the bug: The only
“any other method” GlobalSign uses is email/phone verification via IANA
(ARIN RIPE, APNIC, LACNIC, AFRINIC) IP whois information.
* CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be
deprecated method 1 for domain validation. GlobalSign responded as follows
in the bug: We still use Method 1 in some cases, and are working to put new
processes in place to fully disable Method 1 by August.
* Earlier this year, there was a discussion related to forward-dating the
notBefore date in a certificate [2] that is valid for 3 years. This was
determined not to be a policy violation.

==Bad==
* CA generation of SSL key pairs is a Forbidden Practice [3]. Sections
6.2.10 of the CP and CPS state 

Re: Google Trust Services Root Inclusion Request

[Wayne Thayer via dev-security-policy]

A few additional points:

First off, thank you Rob and James for calling out unacceptable list
behavior. Personal attacks will not be tolerated from anyone on this list.

On Thu, Sep 27, 2018 at 10:26 AM Ryan Sleevi  wrote:

>
> On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley 
> wrote:
>
>> Oh – I totally agree with you on the Google inclusion issue. Google meets
>> the requirements for inclusion in Mozilla’s root policy so there’s no
>> reason to exclude them. They have an audited CPS, support a community
>> broader with certs than just Google, and have operated a CA without
>> problems in the past. The discussion on Mozilla’s independence is important
>> IMO where a) a Mozilla competitor as a module peer and b) having that same
>> person also belong to a CA. There are legit concerns. Has any other CA
>> served as a module owner? If not, why? I know Tim Hollebeek would be
>> interested in being a peer. If he’s not permitted to be a peer, why not?
>>
>
> Again, I don't think there is or should be a ban on module peers being
employed by a CA.


> I think this again conflates peership with ownership, and it's good to
> revisit what policies are actually specified by how it works.
>
> I disagree with you as to the independence discussion being valuable,
> because that conclusion rests on a misunderstanding about module ownership
> and peership. Again,
> https://www.mozilla.org/en-US/about/governance/policies/module-ownership/
> addresses these concerns. It also is conflating MoCo and MoFo, which I know
> was a topic that Gerv was particularly sensitive to.
>
> To your second part, the selection of peers,
> https://wiki.mozilla.org/Modules addresses this - "A peer is a person
> whom the owner has appointed to help them." and "Owners may add and remove
> peers from their modules as they wish, without reference to anyone else"
>
>
My observation is that peers are appointed in recognition of the level of
work they've done for the module. Peer appointments are announced on the
Mozilla governance list, and I believe that a search of recent peer
announcements [1] supports my observation. If members of this list think
there is someone whose contributions should be recognized by making them a
peer, please let Kathleen and me know. Employees of CAs often have the
knowledge needed to make meaningful contributions here, and we welcome
their contributions.

[1]
https://groups.google.com/forum/#!searchin/mozilla.governance/peer%7Csort:date

To be fair, separating out Ryan as a Google browser representative and Ryan
>> as a module peer is…hard. Perhaps, he specifically is seen as more
>> influential (from my point of view) than others simply because of his dual
>> role.
>>
>
> What is difficult separating out? You're intimating at some degree of
> influence that is not transparent, but that's not supported by any
> evidence. You're also intimating influence over Mozilla somehow, but that
> seems like the separation would be easy.
>
>
>> As I said before, Ryan’s a good module peer so I don’t disagree with your
>> conclusion or any decision to keep him in that spot. But I think openness
>> should include respectful conversation on the impact of influences,
>> perceived or real, on the Mozilla direction.  What might help alleviate
>> concerns is to describe how you (as a module owner) are going to ensure
>> that if Ryan is reviewing and approving code or CA policies, they won’t be
>> unfairly biased towards google or against its competitors? Maybe that’s a
>> bad question, but I’m spit-balling on how we can move past speculation to
>> address concerns raised.
>>
>
> Considering that all of this happens in the open, on m.d.s.p., what are
> you using to support your thinking that there's some undue influence? Do
> you believe that if the title peer is removed, the relationship changes?
> Between questions asked and concerns raised? You're not just spit-balling,
> you're intimating that the speculation has a reasonable foundation that
> requires redress, but you're not actually addressing why that speculation
> is seen as reasonable. That things happen here, transparently, should
> itself serve to demonstrate the speculation as unfounded. Further, the
> influence or lack of influence is based on the discussions that happen
> here, and that regardless of any influence that may be perceived, the
> community discussion that Wayne facilitates as Module Owner provides ample
> opportunity to explore or influence in any other preferable direction.
>
> Just want to point out that Kathleen is currently still the CA Certificate
Policy Module Owner.

But let's humour the specious reasoning here, and imagine there was some
> undue influence on the peership
> - One scenario is that such influence is exercised, and that there isn't a
> public review or discussion phase to 'undo' that influence, and that's bad.
> That's not a failure of peership though, that's a failure of Module
> Ownership
> - Another scenario is that such influence is 

Re: Visa Issues

[Wayne Thayer via dev-security-policy]

Visa has filed a bug [1] requesting removal of the eCommerce root from the
Mozilla root store. Visa has also responded to the information requested in
the qualified audits bug [2], but it's unclear if or when they will respond
to the issues list presented in this thread. Two weeks have passed since I
posted the issues list, and I see no reason to delay the complete distrust
of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
removal of the root from NSS version 3.40 . Visa is still welcome to
respond to the issues list, but I think the removal of Visa's only included
root, and thus Visa, from the Mozilla CA Certificate Program implies that
this discussion has reached a conclusion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c2
[3] https://wiki.mozilla.org/Release_Management/Calendar

On Sun, Sep 23, 2018 at 1:15 PM Ryan Sleevi  wrote:

>
>
> On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Visa recently delivered new qualified audit reports for their eCommerce
>> Root that is included in the Mozilla program. I opened a bug [1] and
>> requested an incident report from Visa.
>>
>> Visa was also the subject of a thread [2] earlier this year in which I
>> stated that I would look into some of the concerns that were raised. I've
>> done that and have compiled the following issues list:
>>
>> https://wiki.mozilla.org/CA:Visa_Issues
>>
>> While I have attempted to make this list as complete, accurate, and
>> factual
>> as possible, it may be updated as more information is received from Visa
>> and the community.
>>
>> I would like to request that a representative from Visa engage in this
>> discussion and provide responses to these issues.
>>
>> - Wayne
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851
>> [2]
>>
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ
>
>
> I've not seen Visa engage in this discussion. The silence is rather
> deafening, and arguably unacceptably so.
>
> With respect to the Qualified Audit, Visa's response as to the substance
> of the issue is particularly unsettling.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c3 demonstrates that
> they've not actually remediated the qualification, that they've further
> failed to meet the BRs requirements on revocations by any reasonable
> perspective, and they don't even have a plan yet to remedy this issue.
>
> Examining the bug itself is fairly disturbing, and the responses likely
> reveal further BR violations. For example, the inability to obtain evidence
> of domain validation information reveals that there are further issues with
> 2-7.3 - namely, maintaining those logs for 7 years. The response to 2-7.3
> suggests that there are likely more endemic issues around the issuance.
>
> Given the past issues, the recently identified issues (that appear to have
> been longstanding), and the new issues that Visa's PKI Policy team is
> actively engaging in, I believe it would be appropriate and necessary to
> consider removing trust in this CA.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 46 Certificates issued with BR violations (KIR)

[Wayne Thayer via dev-security-policy]

Thank you for the incident report. I have posted it to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497

On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 Wayne Thayer Oct 1, 2018
>
> 2.A timeline of the actions your CA took in response.
>
> A. Oct 2, 2018 - Investigation began.
> B. Oct 4, 2018 - Found impacted certificate policy templates.
> C  Oct 4, 2018 - All the certificates owners were contacted and agreed on
> issuance new BR compliant certificates in time convenient for them,
>   preferably not later than by the end of this year and revocation
> current ones.
> D. Oct 8, 2018 - Fixed impacted certificate policy templates.
> E. Oct 8, 2018 - This disclosure.
>
> Ongoing:
> F. Replacement of impacted certificates
> G. Training of periodic certificate policy templates validation.
>
> 3.Confirmation that your CA has stopped issuing TLS/SSL certificates
> with the problem.
>
> Confirmed.
>
> 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 46 certificates.  The certificates were issued between Feb 20,
> 2017 and Sep 25, 2018.
>
> 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.
>
> Added as attachment
>
> https://crt.sh/?caid=15985=cablint,zlint,x509lint=2017-01-01
>
> 6.Explanation about how and why the mistakes were made or bugs
> introduced, and how they avoided detection until now.
>
> The the incident concerns 46 certificates in the vast majority issued on
> KIR S.A. internal system purposes.
> The root cause of this issue was human error in certificate policy
> templates.
>
> "Human error" is not a sufficient response to this questions. Please
describe the process in place for modifying policy templates and how it
failed to catch this problem.

>
> Remediation items:
>
> 1. Reviewed all certificate policy templates for ensuring that all of them
> are BR comliant.
> 2. All the certificates owners were contacted and agreed on issuance new
> BR compliant certificates in time convenient for them, preferably not later
> than by the end of this year and revocation current ones.
> 3. Added procedural step for periodic certificate policy templates
> validation.
>
> None of these remediation items will prevent future problems of this
nature. How will you improve your processes to prevent future misissuance?

I assume that KIR S.A. has not implemented pre-issuance linting. Why not?
Is there a plan to implement pre-issuance linting? When?

>
> We have by the way question about error: ERROR: The 'Organization Name'
> field of the subject MUST be less than 64 characters.
> According to https://www.ietf.org/rfc/rfc5280.txt and the note from this
> RFC 'ub-organization-name INTEGER ::= 64. For UTF8String or UniversalString
> at least four times the upper bound should be allowed. So what is the max
> length of this field  for UTF8String?
>
> Page 113 of RFC 5280 limits the length of the field to 64 characters
regardless of the data type:

-- Naming attributes of type X520OrganizationName:
--   X520OrganizationName ::=
--  DirectoryName (SIZE (1..ub-organization-name))
--
-- Expanded to avoid parameterized type:
X520OrganizationName ::= CHOICE {
  teletexString TeletexString
  (SIZE (1..ub-organization-name)),
  printableString   PrintableString
  (SIZE (1..ub-organization-name)),
  universalString   UniversalString
  (SIZE (1..ub-organization-name)),
  utf8StringUTF8String
  (SIZE (1..ub-organization-name)),
  bmpString BMPString
  (SIZE (1..ub-organization-name))  }
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Wayne Thayer via dev-security-policy]

Thank you for this report Fotis.

On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Summary
> ---
>
> A number of Qualified Web Authentication Certificates have been issued
> with incorrect qcStatements encoding. A small survey displays that all
> certificates issued by a specific SubCA are affected by this issue
> (https://crt.sh/?CN=%25=1481). The CA has been notified about
> this, but more than a week has passed and it has not yet provided any
> feedback, while it continues to issue such malformed certificates (e.g.
> https://crt.sh/?id=816495298).
>
> Technical details
> -
>
> According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
> (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
> (QCStatement claiming that the certificate is a EU qualified certificate
> of a particular type), the QCStatement QcType with OID
> id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
> issued for a particular purpose (e-sign, e-seal, qualified web
> authentication certificate). Every certificate containing this
> QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
> purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
> T-Systems International GmbH has failed to follow this specification,
> and instead issues certificates having id-etsi-qct-web as a QCStatement.
> Such a certificate can be found at https://crt.sh/?asn1=795148644. You
> can compare this with https://crt.sh/?asn1=844599393 which has the
> QcType QCStatement correctly encoded.
>
> Disclosure to CA timeline
> -
>
> - 2 October 2018: First notification to the CA, with a detailed
> description of the issue.
> - 2 October 2018: Reply by a CA representative that they will look at it.
> - 8 October 2018: Second notification and request for feedback.
>
> No further communication has taken place.
>
> Impact to WebPKI
> 
>
> Two issues can be identified.
>
> The first issue is the incorrect encoding of the QCStatement. My
> assessment is that this problem does not affect the WebPKI, since as far
> as I can tell, no browsers decode or utilize the QCStatements extension.
>
> The second issue is the failure of the CA to identify the problem, reply
> in time, possibly revoke the problematic certificates and at least
> momentarily pause the issuance of new certificates until the issue is
> resolved. I consider this a serious issue that displays problematic
> practices within the CA.
>
> I share your concern for the CA's responsiveness, but I'm not seeing
anything that would make this a violation of the BRs or Mozilla's policies.

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

Re: Violation report - Comodo CA certificates revocation delays

[Wayne Thayer via dev-security-policy]

I just poked Comodo in the bug -
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006

CT Logs are designed such that certificates cannot be removed from them.
The evidence will not disappear once the certificates expire.

On Wed, Oct 10, 2018 at 5:26 PM please please 
wrote:

> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
> --
> *From:* please please 
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> --
> *From:* Wayne Thayer 
> *Sent:* September 17, 2018 20:09
> *To:* pleaseiwantt...@hotmail.com
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> aware that Comodo CA took more than 5 days to revoke certificates they had
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
> and all of its subdomains was on September 8 at 4:37 UTC. I did not get a
> reply until September 9 at 15:53 UTC stating that the certificates have
> been revoked. Not only was this past the 24 hours requirement, but it was
> also false, as only the most recent certificates had been revoked, not all
> of them. I mentioned to them their mistake on September 10 at 5:55 UTC with
> a full list of affected certificates just in case my initial request was
> unclear to them, and never got a reply back. I did, however, notice that
> the certificates eventually got revoked on September 13 at 16:04 UTC
> according to their Certificate Transparency logs, a fact that I only
> discovered on September 15. Assuming the log is correct, that would be a
> delay of more than 3 days after notifying them of the incomplete
> revocation, more than 5 days after my initial request to them, and more
> than a week until I finally noticed the problem was fixed. It's also worth
> noting that throughout this entire series of events, Comodo CA never
> requested proof of domain ownership beyond the evidence I initially
> provided, so that cannot explain the delays.
>
> One detail that I'm not sure about is why my initial evidence for domain
> ownership was apparently sufficient for 

Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Wayne Thayer via dev-security-policy]

This request is for inclusion of these four emSign roots operated by
eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337

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

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

* Root Certificate Download URL: https://repository.emsign.com/

* CP/CPS: https://repository.emsign.com/cps/CP-CPS-v1.04.pdf

* This request is to include the roots with the email and websites trust
bits enabled and with EV treatment.

* EV Policy OID: 2.23.140.1.1

* Test Websites
https://testevg1.emSign.com
https://testevg1e.emsign.com
https://testevg1r.emsign.com
https://testevg3.emSign.com
https://testevg3e.emsign.com
https://testevg3r.emsign.com
https://testevc1.emSign.com
https://testevc1e.emsign.com
https://testevc1r.emsign.com
https://testevc3.emSign.com
https://testevc3e.emsign.com
https://testevc3r.emsign.com

* CRL URLs:
http://crl.emsign.com?RootCAG1.crl
http://crl.emsign.com?RootCAG3.crl
http://crl.emsign.com?RootCAC1.crl
http://crl.emsign.com?RootCAC3.crl

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

* Audit: Point-in-time audits were performed by BDO Malaysia according to
the WebTrust for CA, BR, and EV audit criteria.
WebTrust:
https://repository.emsign.com/downloads/auditreports/1-A-CA_opt.pdf
BR: https://repository.emsign.com/downloads/auditreports/2-A-SSL_opt.pdf
EV: https://repository.emsign.com/downloads/auditreports/3-A-EVSSL_opt.pdf

emSign expects to receive period-of-time audit reports covering February to
September 2018 in the next week. I request that an emSign representative
post links to those reports to this thread when they are available.

I’ve reviewed the CPS, BR Self Assessment, and related information for
inclusion of the four emSign roots that is being tracked in this bug and
have the following comments:

==Good==
* Roots were signed earlier this year and a RKGC report was provided [1].
* CPS section 1.4.2 forbids the use of emSign certificates for MITM.

==Meh==
* The CPS allows “external issuing CAs” but does not clearly state that the
requirements of BR section 1.3.2 will be met. emSign made the following
comment in response to this concern: “In the CP/CPS, there is reasonable
definition for both External Issuing CAs and External RAs. Section 1.1 of
CP/CPS also promises that BR supersedes this document.”
* It is not clear from emSign’s response in their application if they have
implemented pre-issuance linting: “Certificate issuance of emSign goes
through stringent checks, and application has validated controls to meet
the BR and RFC requirements for standards. emSign continues to implement
additional tools (as recommended) in order to enhance the pre-issuance
checks.”
* CPS section 3.2.7 clearly defines data reuse requirements for certificate
renewal. CPS section 3.2.8 implied by omission that re-keying could be done
without revalidation of information even if it was more than 825 days old.
This has been addressed in the current version of the CPS.

==Bad==
* Version 1.03 of the CPS allowed emSign to violate the BR requirements for
CAA validation. Section 4.2.4 stated: “If a CAA record exists and does not
list emSign PKI based Issuing CAs as an authorized CA, Issuing CA shall
verify that the applicant has authorized issuing CA to issue, despite
existence of CAA record.” This sentence has been removed from the current
CPS.
* One of the domain validation methods in CPS section 10.1 was not
specified in enough detail to allow a reader to determine if it meets BR
requirements: “Relying on publicly available records from the Domain Name
Registrar, such as WHOIS or other DNS record information.” This has been
improved in the current version of the CPS, however I would prefer to see a
more detailed description of each domain validation methods with references
to the BR method numbers.
* CPS section 10.6 described “Device Certificates” as “Includes TLS/SSL
Certificates for internal use”, then went on to omit any description of
domain validation procedures. If these TLS certificates chain to an
included root as would be implied by including them in this CPS, then they
must not allow internal names and must conform to BR domain verification
rules. The reference to “TLS/SSL Certificates for internal use” was removed
from the current version of the CPS.
* Mozilla policy 2.2(2) requires the CPS to describe how email address
validation is performed for emailProtection (S/MIME) certificates. The
statement “or any other reliable means” in section 10.7 does not meet this
requirement. emSign improved this description in the latest version of the
CPS, but the “or any other reliable means” language remains.
* Mozilla policy 2.2(4)  requires the CPS to describe how IP address
validation is performed for TLS certificates. The statement “or any other
equivalent procedure, which proves the applicant’s right to use the IP”
that was in sections 10.1-10.3 did 

Re: Certum CA - Unallowed key usage for EC public key (Key Encipherment)

[Wayne Thayer via dev-security-policy]

Wojciech,

Thank you for the incident report. I believe it does a good job of
explaining how you will prevent this specific problem from happening again,
but it does not address the broader problem of misissuance and Certum's
failure to detect it. How can the Mozilla community be assured that Certum
will detect and prevent all types of certificate misissuance in the future?

- Wayne

On Wed, Oct 10, 2018 at 8:03 AM Wojciech Trapczyński via
dev-security-policy  wrote:

> Please find our incident report below.
>
> 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.
>
>  From Bugzilla bug 1495518 created by Wayne Thayer on October 1 2018 at
> 18:42 GMT.
>
> 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.
>
> Oct 1, 2018 18:42 GMT - The Bugzilla bug 1495518 was created.
> Oct 2, 2018   - We analyzed this case and found the reason for
> misissues. We started to prepare the fix. We found all affected
> certificates. We informed our customers about this bug and necessity to
> revoked certificates.
> Oct 3, 2018 12:00 GMT - We deployed fix on production.
>
> 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.
>
> Oct 3, 2018 at 12:00 GMT.
>
> 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.
>
> Total number of affected valid certificates: 43. All certificates,
> except two, already have been revoked. These two certificates will be
> revoked by the end of this week.
>
> 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.
>
> In attachement.
>
> 6. Explanation about how and why the mistakes were made or bugs
> introduced, and how they avoided detection until now.
>
> We did not properly choose the profile name for certification request
> with EC public key in our software. Instead of choose EC profile where
> Key Encipherment value in Key Usage extension is disallowed we choose
> RSA profile where Key Encipherment value in Key Usage extension is
> allowed. The bug was not found by our tests suite because we did not
> have scenario for such case.
>
> 7. List of steps your CA is taking to resolve the situation and ensure
> such issuance will not be repeated in the future, accompanied with a
> timeline of when your CA expects to accomplish these things.
>
> - We have fixed our software. Now, if a certification request contains
> EC public key only EC certificate profile is allowed to use.
> - We have added the appropriate test case. Now, for every software
> release we check that appropriate profile is chosen for given type of
> public key.
> - We have added an additional protection at the certificate profile
> level in the CA issuing system. Now, the CA system for issuing
> certificates will block the issuance of the certificate if it receives
> unmatched combination of public key and profile.
> ___
> 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: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Wayne Thayer via dev-security-policy]

Thanks Ryan. It's not entirely obvious, but I understand your logic and it
makes sense. If anyone disagrees, please speak up. Meanwhile, I've opened a
misissuance bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498463

- Wayne

On Thu, Oct 11, 2018 at 3:39 PM Ryan Sleevi  wrote:

>
>
> On Fri, Oct 12, 2018 at 2:32 AM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Thank you for this report Fotis.
>>
>> On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Summary
>> > ---
>> >
>> > A number of Qualified Web Authentication Certificates have been issued
>> > with incorrect qcStatements encoding. A small survey displays that all
>> > certificates issued by a specific SubCA are affected by this issue
>> > (https://crt.sh/?CN=%25=1481). The CA has been notified about
>> > this, but more than a week has passed and it has not yet provided any
>> > feedback, while it continues to issue such malformed certificates (e.g.
>> > https://crt.sh/?id=816495298).
>> >
>> > Technical details
>> > -
>> >
>> > According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
>> > (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
>> > (QCStatement claiming that the certificate is a EU qualified certificate
>> > of a particular type), the QCStatement QcType with OID
>> > id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
>> > issued for a particular purpose (e-sign, e-seal, qualified web
>> > authentication certificate). Every certificate containing this
>> > QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
>> > purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
>> > T-Systems International GmbH has failed to follow this specification,
>> > and instead issues certificates having id-etsi-qct-web as a QCStatement.
>> > Such a certificate can be found at https://crt.sh/?asn1=795148644. You
>> > can compare this with https://crt.sh/?asn1=844599393 which has the
>> > QcType QCStatement correctly encoded.
>> >
>> > Disclosure to CA timeline
>> > -
>> >
>> > - 2 October 2018: First notification to the CA, with a detailed
>> > description of the issue.
>> > - 2 October 2018: Reply by a CA representative that they will look at
>> it.
>> > - 8 October 2018: Second notification and request for feedback.
>> >
>> > No further communication has taken place.
>> >
>> > Impact to WebPKI
>> > 
>> >
>> > Two issues can be identified.
>> >
>> > The first issue is the incorrect encoding of the QCStatement. My
>> > assessment is that this problem does not affect the WebPKI, since as far
>> > as I can tell, no browsers decode or utilize the QCStatements extension.
>> >
>> > The second issue is the failure of the CA to identify the problem, reply
>> > in time, possibly revoke the problematic certificates and at least
>> > momentarily pause the issuance of new certificates until the issue is
>> > resolved. I consider this a serious issue that displays problematic
>> > practices within the CA.
>> >
>> > I share your concern for the CA's responsiveness, but I'm not seeing
>> anything that would make this a violation of the BRs or Mozilla's
>> policies.
>
>
> The BRs requires certificates to comply with RFC 5280, and that all
> extensions meet the requirements of 7.1.2.4 of the BRs. Mozilla Root CA
> Policy 5.2 prohibits both incorrect extensions and invalid DER encoding.
> These two entries are distinct in policy, as the “invalid DER” rule
> unambiguously sets restrictions on the encoding rules being adhered to,
> while the “incorrect extensions” addresses any semantic violation of the
> encoding (since both of those cases are possible to encode in DER, but
> their extension definition says you MUST NOT encode entries like that
> because they do not conform to the extension’s textual definition.
>
> The expectation is that if there is a defined ASN.1 module for the
> extension being included within a certificate, the CA will observe that
> encoding (Moz Policy 5.2 - “invalid DER”) and semantics (“incorrect
> extensions”) as defined by the entity responsible for that OID namespace
> (BRs 7.1.2.4), and as stated in the CA’s CP/CPS (BRs & Moz Policy).
>
> I don’t think 7.1.2.4, or Section 5.2 

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Wayne Thayer via dev-security-policy]

Nick - I expect an emSign representative to respond to all of your
questions, but their information request indicates that they have been
operating the Indian Government Root for more than 10 years and have issued
over 35 million certificates:
https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223

- Wayne

On Thu, Oct 11, 2018 at 2:07 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 11 Oct 2018 13:06:46 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
>
> > This request is for inclusion of these four emSign roots operated by
> > eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337
>
> I would like to read more about eMudhra / emSign.
>
> I have never heard of this entity before, perhaps because they're
> Indian (if I understand correctly) but perhaps because they're just
> entirely new to this business.
>
> Of course just being new isn't inherently disqualifying, but it'd be
> good to understand things like:
>
> - Who (human individuals) is behind this outfit, are there people we've
> dealt with before in any key roles? (For example I hope we can agree
> that individuals from previously distrusted CAs as leadership would
> be a potential red flag) Are there people involved who've done this or
> something similar before?
>
> - Does this entity or a legally related entity already operate a
>   business in this space that has a record we can look at such as:
>   Indian RA for another Certificate Authority, CA in another PKI, or
>   more distantly somewhat similar businesses such as making identity
>   documents, or payment card systems.
>
> - How did they come to decide to set up a new root CA for the Web PKI?
>
> Running a trustworthy CA is pretty hard, so I am at least a little bit
> sceptical of the idea that people I've never hard of can wake up one
> morning and decide "Hey let's run a CA" and do a good job, whether in
> India, Indianapolis or Israel.
> ___
> 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: Misissuance and BR Audit Statements

[Wayne Thayer via dev-security-policy]

Comodo responded to my question about disclosure of incidents to their
auditor with the following statement [1]:

It turns out that we did not disclose these to EY.  That was down to
Comodo CA not offering the evidence of these events during the audit
evidence gathering phase. It was not our intention to mislead and we
regret this short-coming on our part.
We have amended our own internal audit process to make sure these are
gathered up as part of the evidence pack to go to the auditors in
future audit cycles.

I think we should make it a Mozilla program requirement that CAs disclose
incidents and misissuance to their auditors [2].

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1472993#c15
[2] https://github.com/mozilla/pkipolicy/issues/154

On Wed, Aug 15, 2018 at 12:09 PM Wayne Thayer  wrote:

> I went ahead and noted these DigiCert audits as a concern on the CCADB
> record for Scott S. Perry CPA, PLLC.
>
> I do think it's important for CAs to disclose these issues to their
> auditors, but I also expect auditors to discover them.
>
> - Wayne
>
> On Wed, Aug 15, 2018 at 8:21 AM Ben Wilson 
> wrote:
>
>> Re-sending
>>
>> -Original Message-
>> From: Ben Wilson
>> Sent: Wednesday, August 15, 2018 8:34 AM
>> To: 'r...@sleevi.com' ; Wayne Thayer <
>> wtha...@mozilla.com>
>> Cc: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: RE: Misissuance and BR Audit Statements
>>
>> Thanks, Ryan and Wayne,
>>
>> Going forward we'll work to improve our management letter disclosures to
>> include reported mis-issuances during the audit period.
>>
>> Sincerely yours,
>>
>> Ben
>>
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ryan Sleevi via dev-security-policy
>> Sent: Monday, August 13, 2018 3:57 PM
>> To: Wayne Thayer 
>> Cc: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: Re: Misissuance and BR Audit Statements
>>
>> Wayne,
>>
>> Thanks for raising this. I definitely find it surprising to see nothing
>> noted on Comodo's report, as you call out.
>>
>> As another datapoint, consider this recent audit that is reported to be
>> from DigiCert, by way of Amazon Trust Services' providing the audits for
>> their externally operated sub-CAs in [A]. The scope of the WebTrust BR
>> audit report in [B] contains in its scope "DigiCert ECC Extended Validation
>> Server CA" of hash
>> FDC8986CFAC4F35F1ACD517E0F61B879882AE076E2BA80B77BD3F0FE5CEF8862,
>> which [C]. During that time, this CA issued a cert [D] as part of their
>> improperly configured Onion issuance in [E], which was remediated in early
>> March, within the audit period for [B]. I couldn't find it listed in the
>> report.
>>
>> Looking over that period, there were two other (resolved) DigiCert
>> issues, [F] and [G], which affect the CAs listed in scope of [B].
>>
>> I was a bit surprised by this, as like you, I would have expected these
>> to be called out by both Management's Assertion and the auditor.
>> http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf
>> provides some of the illustrative reports, but it appears to only provide
>> templates for management on the result of obtaining a qualified report.
>>
>> [A] https://bugzilla.mozilla.org/show_bug.cgi?id=1482930
>> [B] https://bug1482930.bmoattachments.org/attachment.cgi?id=8999669
>> [C] https://crt.sh/?id=23432431
>> [D] https://crt.sh/?id=351449246
>> [E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192
>> [F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600
>> [G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29
>>
>> On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Given the number of incidents documented over the past year [1][2] for
>> > misissuance and other nonconformities, I would expect many of the 2018
>> > period-of-time WebTrust audit statements being submitted by CAs to
>> > include qualifications describing these matters. In some cases, that
>> > is exactly what we’re seeing. One of many positive examples is
>> > Deloitte’s report on Entrust [3] that includes 2 of the 3 issues
>> documented in Bugzilla.
>> >
>> > Unfortunately, we are also beginning to see some reports that don’t
>> > meet my expectations. I was surprised by GlobalSign’s clean reports
>> > [4] from Ernst & Young, but after examining their i

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

Having given this some more thought, I suggest the following changes:

* Forbid "no stipulation" altogether. While there are a few sections where
it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
Certificate Applications), I don't see a requirement for more descriptive
language to be much of a burden (e.g. 4.2.3 could simply state: "we process
applications in a commercially reasonable time but do not publish specific
SLAs"). In the case of a CP that delegates requirements to one or more
CPSs, it is also more informative to state "Refer to CPS section" than to
use "No stipulation". Finally, if we continue to allow "No stipulation", we
really won't know if a CA is aware of this discussion and is using the term
properly.

* Section 1.1 of the BRs describes the reason that some sections are left
blank:

In accordance with RFC 3647 and to facilitate a comparison of other
certificate policies and CPSs (e.g. for policy mapping), this document
includes all sections of the RFC 3647 framework. However, rather than
beginning with a “no stipulation” comment in all empty sections, the
CA/Browser Forum is leaving such sections initially blank until a decision
of “no stipulation” is made.
Some of the blank sections also cover important information (e.g. 3.3.1
Identification and Authentication for Routine Re-key). We shouldn't allow
"No stipulation" for these either.

* Add a requirement that language that only applies to certificates that
are out-of-scope for Mozilla policy must be clearly marked as such. Many
CP/CPSs cover document signing and other certificate usages, but they often
aren't explicit about policies that aren't permitted for TLS and/or email
certificates. For example, it's permissible for a CP/CPS to describe
procedures for certificate suspension in 4.9.15, but it should clearly
state that suspension will not be used with TLS certificates.

* Finally, I think we need some effective date for these as required
practices. One approach would be to require compliance for any CP/CPS dated
after Dec 31, 2018.

- Wayne

On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have updated the section as follows:
> - Removed the sentence that was trying to limit the use of "No
> Stipulation". Hopefully the clarification about what these words mean is
> sufficient.
> - Added bullet points
> - Added "Sections MUST not be left blank. ..."
>
>
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
>
>
> I continue to appreciate your feedback on this new section.
>
> Thanks,
> Kathleen
>
>
> ___
> 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: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

I've filed a bug to track this misissuance and subsequent failure to
report: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593

On Fri, Oct 19, 2018 at 6:22 AM identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> dev-security-policy wrote:
> > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> dev-security-policy wrote:
> > > > > 5.Explanation about how and why the mistakes were made, and not
> caught and
> > > > > fixed earlier.
> > > > >
> > > > > IdenTrust: The certificate was generated for a server within
> IdenTrust.
> > > > > The certificate contained internal domain names which were not
> reachable
> > > > > externally.  Two domain names in the SAN (
> Autodiscover.identrus.int and
> > > > > Mercury.identrus.int) were included at that time.  When the
> certificate
> > > > > was generated, these domains were internally hosted domains.
> > > >
> > > > This doesn't explain why the mistakes were made, nor does it explain
> why
> > > > they were not caught and fixed earlier.
> > >
> > > IdenTrust:IdenTrust has strict procedures regarding issuance of
> publicly
> > > trusted website certificates.  However at the time of this certificate
> > > issuance (2015) the procedures did allow ability to request exceptions
> for
> > > IdenTrust internal deployments that were not accessible externally.
> >
> > On what date was this exception-requesting element added to IdenTrust's
> > procedures?
> >
> > Please share the criteria which were used to evaluate exception requests.
> >
> > How many times has the procedure for requesting an exception been used?
> How
> > many times has the exception been granted?  I think it would be best if
> all
> > certificates issued under this exception process were made public, to
> ensure
> > that there is full transparency around the extent to which this exception
> > process was used.
> >
> > Finally, can you speak to why the BR requirements around internal names
> and
> > certificate expiry dates wasn't followed in this case?
> >
> > > However due to human error in implementation the server was made
> available
> > > external to our network.  Also due to human error, the IT staff failed
> to
> > > request certificate revocation when the certificate was no longer
> needed.
> >
> > Speaking of revocation, can you explain why this certificate wasn't
> caught
> > by the requirement to revoke all certificates containing internal names
> by
> > 2016-10-01?
> >
> > > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated
> the
> > > website certificate approval procedures to eliminate the ability to
> > > request exceptions to the standard domain validation\verification
> > > procedures.  Please note that these website issuance procedures apply
> to
> > > all applications regardless of the TLD(s) requested in the certificate
> > > application.
> >
> > Correct me if I'm wrong, but does this mean that until the date you
> > specified above, it was procedurally possible for IdenTrust to issue a
> > certificate for *any* domain based on the invocation of this exception?
> > Under which subsection of BR section 3.2.2.4 does IdenTrust believe this
> > procedure was permitted as of the date of the procedure update?
> >
> > - Matt
> IdenTrust: We acknowledge the request for more information and are
> actively working on getting the necessary details to accurately respond.
>  We will respond as soon as we can.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

I'm with Jakob on this, but the point is moot because Kathleen chose not to
adopt that suggestion. Instead, using "no stipulation" is a SHOULD NOT
until we update the root store policy. I would encourage CAs to update
their CPSs proactively to comply with this, but there isn't yet a deadline.

- Wayne

On Wed, Oct 24, 2018 at 7:25 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That may be true, but I don't see any upside for using that date.  If you
> need
> to make a minor CPS update in early January for any reason, you now have
> additional work.
>
> I think late December policy changes should be avoided as a general rule.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  >
> > On Behalf Of Jakob Bohm via dev-security-policy
> > Sent: Wednesday, October 24, 2018 9:44 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Cc: Jakob Bohm 
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> > On 24/10/2018 00:08, Tim Hollebeek wrote:
> > > I agree with you, but December 31 is a particularly horrible compliance
> > deadline.  Perhaps January 31?
> > >
> >
> > Note that the requirement applies only to CP/CPS dated after that date.
> > So it is really Dec 31 + the time until the CP/CPS is updated for some
> other
> > reason.  This is different than many other policy requirements, and a
> > welcome reduction in administrative overhead for all concerned (including
> > root programs and relying parties).
> >
> > For example, it a CA updated their CP/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Wayne
> > >> Thayer via dev-security-policy
> > >> Sent: Monday, October 22, 2018 6:00 PM
> > >> To: Kathleen Wilson 
> > >> Cc: mozilla-dev-security-policy
> > >> 
> > >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> > >> use it in CP/CPS?
> > >>
> > >> Having given this some more thought, I suggest the following changes:
> > >>
> > >> ...
> > >>
> > >> * Finally, I think we need some effective date for these as required
> > practices.
> > >> One approach would be to require compliance for any CP/CPS dated
> > >> after Dec 31, 2018.
> > >>
> > >> - Wayne
> > >>
> > >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> > >> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > >>
> > >>> I have updated the section as follows:
> > >>> - Removed the sentence that was trying to limit the use of "No
> > >>> Stipulation". Hopefully the clarification about what these words
> > >>> mean is sufficient.
> > >>> - Added bullet points
> > >>> - Added "Sections MUST not be left blank. ..."
> > >>>
> > >>>
> > >>>
> > >> https://clicktime.symantec.com/a/1/Xh-
> > rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> > >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> > WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> > >> UBJ2Lqfz4GYYK9b1-
> > 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> > >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> > PUFpXdUPJHpMF3mizDn82r
> > >>
> > k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> > WaoM-
> > >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> > oCmWpmJtDsMG
> > >>
> > HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> > QfVhB_kA
> > >> _fCU3vcSLkeOXiJOLq-
> > YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg=htt
> > >>
> > ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> > ices%
> > >> 23CP.2FCPS
> > >>> _Structured_According_to_RFC_3647
> > >>>
> > >>>
> > >>> I continue to appreciate your feedback on this new section.
> > >>>
> >
> >
> > Enjoy
> >
> > Jakob
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

[Wayne Thayer via dev-security-policy]

I believe that the discussion over Certigna's reported CAA misissuance
[1][2] has reached an end, even though some questions remain unanswered. If
anyone has additional comments or concerns about this inclusion request,
please respond by Friday 26-October. This request [3] has been in
discussion since April 2017 and I would like to bring it to a conclusion
soon.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683

On Wed, Sep 12, 2018 at 11:44 PM Wayne Thayer  wrote:

> On Tue, Sep 11, 2018 at 12:37 AM josselin.allemandou--- via
> dev-security-policy  wrote:
>
>> Hello,
>>
>> Thanks Wayne and Devon for your reply.
>>
>> We took the time to respond because we wanted to verify through an audit
>> that the SSL certificate requests processed since September 8th were in
>> compliance with the CA/B Forum requirements for DNS CAA record checks.
>>
>> >
> Excellent!
> >
>
>> In general, this has been the case, because we have only one case, where
>> the request was authorized by a Registration Officer, despite the alert
>> that had been raised on this subject.
>>
>> We checked the logs of the controls carried out and re-rolled these
>> controls on all the SSL certificates issued since September 8th and confirm
>> that only this certificate was the object of a failure. We have created an
>> incident as required (see URL:
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/mVD1QoGXBOQ)
>> for this certificate which has not yet been deployed and used by the
>> applicant. I confirm that we proceeded to the revocation of this
>> certificate which is now included in our CRL with the following serial
>> number: 476abeb2bc78d588ef4b8f27dbd25f6a (see
>> http://crl.certigna.fr/servicesca.crl).
>>
>> Note that this incident will not be able to happen again by means of our
>> new practices that automatically block and without possible bypass by the
>> RA, any certificate request for which the DNS CAA record controls induce
>> that the CA is not allowed to issue. These practices are described in the
>> latest updated versions of our CP/CPS.
>>
>> >
> I will respond to this in the separate thread for the incident report.
> >
>
>> We have updated our CPs and CPSs to address the different points reported
>> by Devon:
>> -   We clarified the roles and controls performed by the RA and the
>> DRAs;
>> -   We updated the practices implemented for the control of DNS CAA
>> records;
>> -   We have specified the conditions of generation and signature of
>> certificates by the root CA. As a reminder, these certificates are
>> exclusively reserved for the intermediary authorities of our organization
>> and are handled through Key Ceremonies involving several trusted roles
>> knowing that our root CAs are Offline, and are not intended for customers
>> request.
>>
>> Could you tell us if you would like additional information and if these
>> provided to CP/CPS are sufficient for you?
>>
>> >
> Devon confirmed to me that he is satisfied with these updates.
> >
>
>> Thanking you in advance for your help and your reply.
>>
>> Best regards
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> > I believe that the discussion over Certigna's reported CAA misissuance
> > [1][2] has reached an end, even though some questions remain unanswered.
> If
> > anyone has additional comments or concerns about this inclusion request,
> > please respond by Friday 26-October. This request [3] has been in
> > discussion since April 2017 and I would like to bring it to a conclusion
> > soon.
> >
> > - Wayne
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> >
>
> If there remain unresolved issues, should not approval be withheld?
>
> Certigna has completed their remediation, but a large number of questions
were asked during the discussion of the misissuance. I think it is fair to
say that Certigna was unwilling or unable to answer many of them, and when
this became apparent, I asked for the questioning to stop. Therefore, I
consider the issue to be resolved, but not necessarily resolved to our
satisfaction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/24/2018 1:07 PM, Wayne Thayer wrote:
> > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> >>> I believe that the discussion over Certigna's reported CAA misissuance
> >>> [1][2] has reached an end, even though some questions remain
> unanswered.
> >> If
> >>> anyone has additional comments or concerns about this inclusion
> request,
> >>> please respond by Friday 26-October. This request [3] has been in
> >>> discussion since April 2017 and I would like to bring it to a
> conclusion
> >>> soon.
> >>>
> >>> - Wayne
> >>>
> >>> [1]
> >>>
> >>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> >>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> >>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> >>>
> >>
> >> If there remain unresolved issues, should not approval be withheld?
> >>
> >> Certigna has completed their remediation, but a large number of
> questions
> > were asked during the discussion of the misissuance. I think it is fair
> to
> > say that Certigna was unwilling or unable to answer many of them, and
> when
> > this became apparent, I asked for the questioning to stop. Therefore, I
> > consider the issue to be resolved, but not necessarily resolved to our
> > satisfaction.
> >
>
> If Mozilla is not satisfied with how the misissuance was resolved, why
> would the root be included in Mozilla's NSS?
>
> It's fairly common for a CA to fail to meet our expectations for root
cause analysis, and I suspect that we would tolerate this one if it had
been discovered, say, a year ago rather than during the inclusion
discussion. I'm not arguing for ignoring it, but when I consider the
entirety of the evidence presented, it's not obvious to me that this should
be rejected either. That's part of the reason why I asked for additional
comments.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma's CP & CPS disclosure

[Wayne Thayer via dev-security-policy]

Camerfirma has delivered point-in-time audits as required by Mozilla in
response to the annual audit statements we received in July containing
multiple qualifications. The new audit statements along with the history of
this issue can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=1478933

In my opinion, Camerfirma has completed their remediation of this issue.
Please comment here or in the bug if you have any concerns.

- Wayne

On Thu, Sep 27, 2018 at 12:42 AM Ramiro Muñoz 
wrote:

> Hi Wayne
>
> All problems have already been resolved from our side and we wait for the
> PIT audit planned for the next week.
> We will be able to provide the PIT before October 31th.
>
> Best regards
> Ramiro Muñoz Muñoz
> AC Camerfirma SA.
> CTO, Exploitation Manager, CISA.
> +34 619 746 291 · rami...@camerfirma.com.
> https://www.linkedin.com/in/ramirom.
> 
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> contener
> información CONFIDENCIAL, siendo para uso exclusivo del destinatario,
> quedando prohibida su divulgación copia o distribución a terceros. Si Vd.
> ha
> recibido este mensaje erróneamente, se ruega lo notifique al remitente y
> proceda a su borrado.
> De conformidad con lo establecido en el Reglamento UE 2016/679 de 27 de
> abril de 2016 General de Protección de Datos, se le informa que la empresa
> AC CAMERFIRMA, S.A. tratará la información que nos facilita con el
> exclusivo
> fin de cumplir con las obligaciones derivadas de la relación comercial o
> contractual adquirida con usted y que sus datos no podrán ser objeto de
> otro
> tratamiento ni de cesión a terceros salvo en los casos en que exista una
> obligación legal.
> Usted tiene derecho a obtener confirmación acerca del tratamiento de sus
> datos personales, y a ejercer sus derechos de acceso, rectificación,
> supresión, limitación y portabilidad en el tratamiento, dirigiéndose a AC
> CAMERFIRMA, S.A., mediante comunicación escrita remitida a la dirección C/
> Ribera del Loira 12 (28042) Madrid, o a la dirección electrónica
> jurid...@camerfirma.com o a través de la web de incidencias disponible en
> la
> página web http://webcrm.camerfirma.com/incidencias/incidencias.php
>
> [EN]
> This message, and if applicable, any file attached to it, may contain
> CONFIDENTIAL information for the exclusive use of the recipient, being
> prohibited its disclosure copy or distribution to third parties. If you
> have
> received this message incorrectly, please notify the sender and proceed
> with
> its deletion.
> In accordance with the provisions of the EU Regulation 2016/679 of April
> 27,
> 2016 General Data Protection, you are informed that the company AC
> CAMERFIRMA, S.A. will treat the information you provide us with the sole
> purpose of complying with the obligations derived from the commercial or
> contractual relationship acquired with you and that your data will not be
> subject to another treatment or assignment to third parties except in cases
> where there is an legal obligation.
> You have the right to obtain confirmation about your personal data
> treatement, and to exercise your rights of access, rectification, deletion,
> limitation and portability, contacting AC CAMERFIRMA, SA, by written
> communication sent to the address C / Ribera del Loira 12 (28042) Madrid,
> or
> to the legal address jurid...@camerfirma.com or through the website
> http://webcrm.camerfirma.com/incidencias/incidencias.php
>
>
> -Mensaje original-
> De: dev-security-policy
> [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne
> Thayer via dev-security-policy
> Enviado el: jueves, 27 de septiembre de 2018 0:38
> Para: Ramiro Muñoz Muñoz 
> CC: mozilla-dev-security-policy
> 
> Asunto: Re: AC Camerfirma's CP & CPS disclosure
>
> Hello Ramiro,
>
> On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer  wrote:
>
> > Thank you for this response Ramiro. I have copied this to the bug [1]
> > and have described Mozilla's expectations for point-in-time audits
> > that confirm that these issues have been resolved.
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933
> >
> > On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via dev-security-policy
> > < dev-security-policy@lists.mozilla.org> wrote:
> >
> >>
> >> 7- List of steps your CA is taking to resolve the situation and
> >> ensure such issuance will not be repeated in the future, accompanied
> >> with a timeline of when your CA expects to accomplish these things.
> >>
> >> AC Camerfirma has made changes in the CP/CPS to fix the
> >> inconsistences found by the auditor and wil

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Questions about blank sections, thinking of a potential future
> requirement. Sections such as 1.INTRODUCTION would remain blank as they are
> more titles than components, correct?
> If no sections are allowed to be blank does this include both levels of
> components such as 1.4 and 1.4.1?
>
> I would argue that higher level sections (e.g. 1.4)  aren't blank if they
include subsections (e.g. 1.4.1). If there are no subsections under a
section (e.g. 1.1 or 2), then the section should not be blank.

Also, what is the opinion on adding sections to the CP/CPS that are not
> included in the RFC?
>
> Good question. My opinion is that it's okay to add sections as long as
they come after RFC 3647 defined sections and thus don't change the RFC
numbering. I've noted this in the policy issue -
https://github.com/mozilla/pkipolicy/issues/158

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Wayne Thayer via dev-security-policy]

On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 26/10/2018 01:13, Ryan Sleevi wrote:
> > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 25/10/2018 23:10, Wayne Thayer wrote:
> >>> On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
> >>> dev-security-policy@lists.mozilla.org> wrote:
> >>>
>  Questions about blank sections, thinking of a potential future
>  requirement. Sections such as 1.INTRODUCTION would remain blank as
> they
> >> are
>  more titles than components, correct?
>  If no sections are allowed to be blank does this include both levels
> of
>  components such as 1.4 and 1.4.1?
> 
>  I would argue that higher level sections (e.g. 1.4)  aren't blank if
> >> they
> >>> include subsections (e.g. 1.4.1). If there are no subsections under a
> >>> section (e.g. 1.1 or 2), then the section should not be blank.
> >>>
> >>> Also, what is the opinion on adding sections to the CP/CPS that are not
>  included in the RFC?
> 
>  Good question. My opinion is that it's okay to add sections as long as
> >>> they come after RFC 3647 defined sections and thus don't change the RFC
> >>> numbering. I've noted this in the policy issue -
> >>> https://github.com/mozilla/pkipolicy/issues/158
> >>>
> >>
> >> Would it be OK (I think it should) to place new sublevel sections under
> >> appropriate higher level sections, after the RFC section numbers run out
> >> at that level?
> >
> >
> > Can you explain why that is valuable?
> >
> > What purpose do you believe the CP/CPS structure serves? One of the goals
> > of developing the structure in the RFC was to identify the common
> sections
> > applicable to all CAs, with a consistent structure, to allow easy
> > comparison between policies. Indeed, early audit processes proposed
> making
> > these policies machine readable and templated, to expedite comparisons.
> >
>
> I is quite obvious that the 15 year old RFC3647 doesn't cover all the
> issues that need to be covered in a modern CP/CPS, the BRs already add
> many subsections not in the RFC.  I was giving concrete examples about
> what kinds of sections to add.
>
> However my question wasn't if additional sections could be added, this
> was already asked by someone obviously intending to do so.
>
> I was asking if such new sections could be placed where they would make
> the most logical sense rather than being confined to a section 10
> appendix.  I then gave examples of how some commonly occurring issues
> (such as a single CP/CPS covering both WebPKI and non-WebPKI roots)
> would fit more neatly earlier in a policy document.
>
> My response stating that I think this is okay was intended to include
adding new subsections to the end of any of the existing sections. I do
share some concern with this because it has and will continue to result in
information being placed into new sections rather than appropriate existing
sections. However, I also think there are legitimate reasons for adding
sections, and it makes more sense to logically group them with similar
content than at the end of the doc.

>
>
> 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: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

I am recommending denial of this request.

It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
I'm not going to argue this point and claim that these certificates were
misissued because 'identrust.int' and 'identrus.int' were not registered
domain names.

Under the assumption that these are Internal Names, none of these
certificates were issued after the BR deadline of 1-November 2015. From
this I would infer that Identrust was aware of the requirements. Three of
the disclosed certificates were not expired or revoked prior to the BR
Internal Name deadline of 1-October 2016:
https://crt.sh/?id=7852280
https://crt.sh/?id=882509134
https://crt.sh/?id=882509077

This happened in spite of well documented incidents in which other CAs
failed to revoke certificates containing Internal Names [1]. One of these
three certificates was revoked on 22-February 2018, corresponding with the
date Nick Hatch reported it to Identrust. Identrust did not disclose the
incident, nor - given that the other two were never revoked - did they
apparently perform a scan of their certificates to identify any others.
This calls into question Identrust's ability to adhere to the BRs, their
remediation practices, and their willingness to publicly disclose incidents.

Identrust has requested that Mozilla grant EV indication to the Commercial
Root CA 1 - the same root involved in this incident. Identrust's actions in
this incident are troubling and provide justification for denying the
higher level of trust implied by EV.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ

On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> dev-security-policy wrote:
> > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> dev-security-policy wrote:
> > > > > 5.Explanation about how and why the mistakes were made, and not
> caught and
> > > > > fixed earlier.
> > > > >
> > > > > IdenTrust:
> The certificate was generated for a server within IdenTrust.
> > > > > The certificate contained internal domain names which were not
> reachable
> > > > > externally.  Two domain names in the SAN (
> Autodiscover.identrus.int and
> > > > > Mercury.identrus.int) were included at that time.  When the
> certificate
> > > > > was generated, these domains were internally hosted domains.
> > > >
> > > > This doesn't explain why the mistakes were made, nor does it explain
> why
> > > > they were not caught and fixed earlier.
> > >
> > > IdenTrust:IdenTrust has strict procedures regarding issuance of
> publicly
> > > trusted website certificates.  However at the time of this certificate
> > > issuance (2015) the procedures did allow ability to request exceptions
> for
> > > IdenTrust internal deployments that were not accessible externally.
> >
> > On what date was this exception-requesting element added to IdenTrust's
> > procedures?
> IdenTrust:
> At this point we are unable to ascertain the exact date the
> exception-requesting element was added.  We can confirm the that the
> exception-requesting element pre-dates 2012.
>
> > Please share the criteria which were used to evaluate exception requests.
> IdenTrust:
> The criteria for the exception is  that Registration desk, upon request of
> IdenTrust IT Staff, can request to risk management an exception to complete
> an attempted Verification of Domain through external registrars for domain
> name that is IdenTrust owned domain equivalent for servers that will not be
> accessible externally.
>
> > How many times has the procedure for requesting an exception been used?
> How
> > many times has the exception been granted?  I think it would be best if
> all
> > certificates issued under this exception process were made public, to
> ensure
> > that there is full transparency around the extent to which this exception
> > process was used.
> IdenTrust:
> The exception request has been used on the issuance of the 13 certificates
> listed below, now in CT logs.  Please note that majority of the
> certificates listed were issued pre-2012.
> https://crt.sh/?id=514746
> https://crt.sh/?id=7852280
> https://crt.sh/?id=882509134
> https://crt.sh/?id=882509077
> https://crt.sh/?id=882509158
> https://crt.sh/?id=882509159
> https://crt.sh/?id=882597656
> https://crt.sh/?id=882509100
> https://crt.sh/?id=882509154
> https://crt.sh/?id=882509101
> https://crt.sh/?id=882597659
> https://crt.sh/?id=882509103
> https://crt.sh/?id=882509147
>
> > Finally, can you speak to why the BR requirements around internal names
> and
> > certificate expiry dates wasn't followed in this case?
> IdenTrust:
> As noted the exception request procedure pre-dates 2012.  Our best
> determination is that the 

Re: Questions regarding the qualifications and competency of TUVIT

[Wayne Thayer via dev-security-policy]

I am particularly disturbed by three points made by TUVIT during this
discussion:

1. A malformed qcStatement extension is a minor non-conformity because
there is no known security risk - This argument is incredibly dangerous and
harmful. It implies that all sorts of well-defined requirements can be
ignored if the CA and/or auditor decide that there is no risk in doing so.

2. Citing ISO 17065 as requiring non-conformities be kept confidential -
adding on Ryan's comments, we're seeing increasing disclosure of audit
findings (another example:
https://netlock.hu/download/etsi-certification-netlock/?wpdmdl=57340),
leading me to believe that this is TUVIT's own interpretation of the
confidentiality requirements. I don't believe that TUVIT needs "the
establishment of rules with in the CAB/Forum for making such kind of
incidents public" in order to begin making these disclosures.

3. The argument that T-Systems has 3-months to revoke these certificates -
while I understand that under ETSI TSPs have 3 months to correct minor
non-conformities, using that as an excuse to ignore CAB Forum revocation
requirements is unacceptable, and perhaps explains why we see such poor
compliance with this requirement. If this is indeed the accepted
interpretation (please confirm), then I will look for ways to fix this via
Mozilla policy.

- Wayne

On Fri, Nov 2, 2018 at 8:25 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Nov 2, 2018 at 10:24 AM Wiedenhorst, Matthias via
> dev-security-policy  wrote:
>
> > Auditor and Reviewer, as stated on
> >
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018072001_Audit_Attestation_E_Deutsche-Telekom-Root-CA-2_20180718_s.pdf
> > - the parties tasked with ensuring that the audit is meaningfully able to
> > ensure the criteria were met and the testing procedures were able to meet
> > those requirements.
> >
> > Auditors and reviewers need to be distinguished: ISO/IEC 17065 §7.5.1
> > forbids that the person(s) performing the review is involved in the audit
> > process.
> >
>
> Indeed - and yet do you agree that the Reviewer is tasked with reviewing
> the audit methodology and artifacts to ensure it appropriately meets the
> objectives expected and required? A multi-party failure to assure the
> necessary assurance is just that - a multi-party failure.
>
> >Issue A) As part of their initial response to my complaint, TUVIT, by way
> > >of Matthias Wiedenhorst (Head of Certification Division TSP) stated "As
> a
> > >very first, quick cross check with our audit evidence record, I can only
> > >say that we did check issued certificates from within the declared
> period
> > >and that they did contain the proper qcStatement-6.3 /
> id-etsi-qcs-QcType
> > >3". However, this statement was in direct conflict with the TSP's own
> > >investigation and incident report, provided at
> > >https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 , which states
> > the
> > >mistake was introduced during the development of support - that is, no
> > such
> > >properly issued certificates were issued.
> >
> > We do not understand why the important fact that Matthias was not in
> > office and replied what he remembered from an audit that was month ago is
> > not mentioned here. In addition, he replied that he would verify and come
> > back as soon as possible (when he is in office again). That actually
> > happened, see below.
> >
> > Wrong or misleading information - which was only corrected upon specific
> > questioning and a request for proof or evidence of the claim - has been
> > used to disqualify CAs in the past. This statement was made after the TSP
> > had themselves already investigated and confirmed this was not possible.
> >
> > The same standard being applied to CA incident reports is being proposed
> > here - that incomplete and improper investigations raise serious
> questions.
> >
> > Let’s stay with present case (not with the past): In his email, Matthias
> > said that he is not in his office and will begin to investigate the
> > situation as soon as possible. We think that it is clear, that further
> > information contained in the email cannot be based on the result of the
> > investigation. Back in his office after looking into the audit logs and
> > verifying the qcStatement he gave the proper answer.
> >
>
> I appreciate the attempt to narrowly scope the issue, but that is equally
> an attempt to deflect or ignore the ample set of past precedent and
> expectations. As such, I reject the premise that this should be considered
> without regard to past failures by CAs or other auditors - as an auditor
> being entrusted to report truthfully and faithfully to the community about
> a CAs compliance with its own CP, CPS, and the appropriate supervisory
> framework, auditors are expected to consider the best practices and
> precedents in their activities and actions.
>
> With respect to your suggestion that the information can not be 

Re: Certigna Root Renewal Request

[Wayne Thayer via dev-security-policy]

Having received no further comments, I am recommending approval of
Certigna's inclusion request.

I would first like to thank Certigna for their patience as this request
spent a long time waiting on Mozilla.

The disregard for CAB Forum requirements shown by Certigna's CAA exception
process is a very serious issue, as is the incomplete response we received
from Certigna. If not for the fact that few other issues were identified,
and that the CAA requirement is relatively new and apparently not well
understood, I may not have recommended approval. Certigna should be aware
that any future policy violations will be judged more severely than they
might seem given the existence of this CAA misissuance.

- Wayne

On Wed, Oct 24, 2018 at 4:56 PM Wayne Thayer  wrote:

> On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 10/24/2018 1:07 PM, Wayne Thayer wrote:
>> > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
>> >>> I believe that the discussion over Certigna's reported CAA misissuance
>> >>> [1][2] has reached an end, even though some questions remain
>> unanswered.
>> >> If
>> >>> anyone has additional comments or concerns about this inclusion
>> request,
>> >>> please respond by Friday 26-October. This request [3] has been in
>> >>> discussion since April 2017 and I would like to bring it to a
>> conclusion
>> >>> soon.
>> >>>
>> >>> - Wayne
>> >>>
>> >>> [1]
>> >>>
>> >>
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
>> >>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
>> >>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
>> >>>
>> >>
>> >> If there remain unresolved issues, should not approval be withheld?
>> >>
>> >> Certigna has completed their remediation, but a large number of
>> questions
>> > were asked during the discussion of the misissuance. I think it is fair
>> to
>> > say that Certigna was unwilling or unable to answer many of them, and
>> when
>> > this became apparent, I asked for the questioning to stop. Therefore, I
>> > consider the issue to be resolved, but not necessarily resolved to our
>> > satisfaction.
>> >
>>
>> If Mozilla is not satisfied with how the misissuance was resolved, why
>> would the root be included in Mozilla's NSS?
>>
>> It's fairly common for a CA to fail to meet our expectations for root
> cause analysis, and I suspect that we would tolerate this one if it had
> been discovered, say, a year ago rather than during the inclusion
> discussion. I'm not arguing for ignoring it, but when I consider the
> entirety of the evidence presented, it's not obvious to me that this should
> be rejected either. That's part of the reason why I asked for additional
> comments.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions regarding the qualifications and competency of TUVIT

[Wayne Thayer via dev-security-policy]

In addition, I take exception to the statement that open criticism is a bad
approach and the implication that private discussions are the best way to
make improvements. This is clearly not Mozilla's philosophy.

I do believe that we all need to be careful to follow Mozilla forum
etiquette [1] and community participation guidelines [2], particularly the
section titled "Be Direct but Professional". However, transparent
discussions are a core Mozilla Principle [3]:

"Transparent community-based processes promote participation,
accountability and trust."

I look forward to more open and constructive discussions aimed at improving
the quality and transparency of CA audits, regardless of the audit scheme.

- Wayne

[1] https://www.mozilla.org/en-US/about/forums/etiquette/
[2] https://www.mozilla.org/en-US/about/governance/policies/participation/
[3] https://www.mozilla.org/en-US/about/manifesto/

On Mon, Nov 5, 2018 at 1:55 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Nov 5, 2018 at 3:28 PM Nick Pope via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > It is very unfortunate that at this time the owners of root store
> programs
> > openly criticise one of the main auditors working on improvements to
> > European based audits.  After a number of years of audits of European CAs
> > based on ETSI EN 319 403 being recognised as meeting the requirements of
> > publicly trusted certificates, ETSI is working and with European auditors
> > on further updates to improve the acceptability of European audits to
> root
> > store programs.   It seems to be going against this initiative to suggest
> > draconian measures of excluding TUVIT audit from the root programs whose
> > impact are totally out of proportion the possible impact of the issues
> > raised.
> >
> > I suggest that the providers of root stores to return to the negotiations
> > for further improving European based audits that I understood had started
> > at the recent CA/Browser forum.  The current approach of making public
> > criticisms against those who are trying to make improvements to the
> > European CA audits is making the current direct discussions with root
> store
> > providers difficult to progress.  So unless it is the objective to
> > deliberately exclude European CAs from their root programs, which I
> believe
> > is not the case, I suggest that we return to the direct discussions with
> > the providers of root store on how to further improve European audits so
> > that can better take into account the root program requirements.
> >
> > Nick Pope, Vice-Chair ETSI TC on Electronic Signatures and [Trust]
> > Infrastructures
> >
>
> Respectfully, comments like this unfortunately bring even greater concern
> with respect to the ETSI process.
>
> A significant number of improvements have been made to the ecosystem by
> recognizing when mistakes are made and taking steps to improve. It has now
> seen both TUVIT and the Vice-Chair of the ETSI TC on ESI instead suggest
> these are not mistakes and downplay their significance. This prevents
> meaningful improvements, because it fails to recognize that there exist
> fundamental issues.
>
> I am all in favor of ensuring that all accepted audit schemes meet the
> necessary level of robustness for the community. Much work has been done
> with WebTrust, through their active engagement with Browsers to ensure that
> the needs of the consumers are being met. ETSI has only recently begun to
> recognize these issues, and while we are indeed seeing the beginnings of
> fruitful engagement, we should not suggest that such seeds are a reasonable
> justification to ignore gross negligence in security-critical functions OR
> the deeply concerning dismissiveness of those concerns.
>
> I'm sure you can understand it would be deeply offensive if, on the basis
> of such collaborations with WebTrust, it be suggested that no WebTrust
> auditor be disqualified. Similarly, I'm sure you can understand it would be
> deeply offensive to the purpose, values, and goals to suggest that because
> CAs participate in m.d.s.p., they should be excluded from accountability.
> At the end of the day, browsers are accountable to ensuring their users are
> secure, and regardless of how productive our conversations may be, if the
> level of security is not met, it's entirely appropriate and necessary to
> take steps to protect users.
>
> I hope that, as Vice-Chair of the ETSI TC on ESI, and on behalf of
> auditors, careful introspection is performed in comparing how these
> statements sound when compared with CAs that have been distrusted due to
> gross negligence and misissuance. Failures to acknowledge or recognize the
> problem, failures to have implemented reasonable steps to resolve such
> issues, repeated failures to achieve the necessary level of security, do
> more to harm the brand of that organization and its products than
> statements suggesting 

CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
creating a sunset period for TLS certificates containing an underscore
("_") character in the SAN. This practice was widespread until a year ago
when it was pointed out that underscore characters are not permitted in
dNSName name forms, and ballot 202 was proposed to create an exception to
RFC 5280 that would allow the practice to continue. When that ballot
failed, some CAs stopped allowing underscore characters in SANs and others
continued. Ballot SC12 is intended to resolve this inconsistency and
provide clear guidance to auditors.

The sunset period defined by ballot SC12 is very short. Today Mozilla sent
an email to all CAs in our program informing them of this change and asking
them to take any steps necessary to comply [2].

- Wayne

[1]
https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
[2]
https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

On Mon, Nov 12, 2018 at 6:18 PM Man Ho via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> When the ballot said "... would result in a valid domain label", does it
> mean that "... would result in a valid domain name of the applicant,
> that has passed the same level of domain authorization (DV, OV, EV) check?
>
> No, this does not mean that the CA needs to perform domain validation on
the FQDN with underscores replaced by hyphens. It means that underscores
are only permitted in certain positions within the domain label, as
discussed in the lead-up to ballot 202 (this language is copied directly
from ballot 202). For example:
https://cabforum.org/pipermail/public/2017-May/011186.html

Secondly, is it necessary for CAs to state their practice of handling
> underscore domain name in CPS?
>
> No, that is not a Mozilla requirement.

- Man Ho
>
> On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
> > As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> > creating a sunset period for TLS certificates containing an underscore
> > ("_") character in the SAN. This practice was widespread until a year ago
> > when it was pointed out that underscore characters are not permitted in
> > dNSName name forms, and ballot 202 was proposed to create an exception to
> > RFC 5280 that would allow the practice to continue. When that ballot
> > failed, some CAs stopped allowing underscore characters in SANs and
> others
> > continued. Ballot SC12 is intended to resolve this inconsistency and
> > provide clear guidance to auditors.
> >
> > The sunset period defined by ballot SC12 is very short. Today Mozilla
> sent
> > an email to all CAs in our program informing them of this change and
> asking
> > them to take any steps necessary to comply [2].
> >
> > - Wayne
> >
> > [1]
> >
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> > [2]
> >
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)

[Wayne Thayer via dev-security-policy]

I've added a page to our wiki that describes how Firefox determines if a
particular website received the EV UI:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs

I mentioned this at the last CA/Browser Forum meeting and I hope it is
useful to CAs - especially those who are dealing with cross-signing and
legacy hierarchies.

Since there were no comments about requiring the use of the CA/Browser
Forum EV OID, we've left it as 'strongly encouraged', but I added it to our
issues list for the Root Store Policy:
https://github.com/mozilla/pkipolicy/issues/160

- Wayne

On Thu, Sep 20, 2018 at 1:55 PM Wayne Thayer  wrote:

> Hi Nick,
>
> Good question. Mozilla is currently strongly encouraging CAs to use the
> CAB Forum EV OID, but not requiring it. I would be interested to hear
> arguments for or against requiring the use of the CAB Forum EV OID in
> future Mozilla root store updates. Requiring this might eventually solve
> some of the problems we're seeing when roots are acquired or cross-signed
> [1]. To be clear, at this time I'm only thinking about new inclusions or EV
> enablement, not changing OIDs for existing EV capable roots.
>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486838
>
> On Thu, Sep 20, 2018 at 1:49 AM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tue, 18 Sep 2018 17:53:34 -0700
>> Wayne Thayer via dev-security-policy
>>  wrote:
>>
>> > ** EV Policy OID: 2.23.140.1.1
>>
>> This reminds me of a question I keep meaning to ask. I know Microsoft
>> has been trying to get CAs to use 2.23.140.1.1 for EV and knock it off
>> with the arbitrary policy OIDs, does Mozilla have any policy on that?
>>
>>
>>
>> ___
>> 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

New Auditor Compliance Dashboard + Bugzilla Change

[Wayne Thayer via dev-security-policy]

The recent auditor discussions on this list have highlighted the fact that
we haven't done a good job of tracking auditor concerns. Easily searchable
records of past CA issues in Bugzilla help us to identify patterns of CA
behavior, and we should have the same for auditors. with that in mind, I
have two announcements:

* Rename Bugzilla Component
CA issues have been filed under the NSS component "CA Certificate
Mis-issuance" in Bugzilla. "Mis-issuance" was inaccurate since the category
is used for all types of CA issues - audits, OCSP responders, etc. We also
want to use this component for auditor compliance issues, so we have just
renamed it to "CA Certificate Compliance". Please be aware of this change
when creating new, or searching for existing CA compliance bugs.

* Create Auditor Compliance Dashboard:
https://wiki.mozilla.org/CA/Auditor_Compliance
I've created a new page on our wiki that describes how to create an auditor
compliance bug and that will summarize existing bugs. It also lists the one
auditor location that Mozilla has disqualified. Please let me know if you
find errors or omissions on this page.

I am planning to begin creating auditor compliance bugs when issues are
discovered that should have been found and reported by auditors. I may also
go back and create some bugs to document past issues. Please be aware that
these bugs are for tracking purposes and the simple act of creating one
should not be interpreted as an attack aimed at discrediting or
disqualifying any auditor. It is being done in the spirit of transparency
with the intent of working collaboratively with auditors to improve the
quality and consistency of the audit information received by Mozilla.

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

Re: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

I agree with Tim on the interpretation and can confirm that my intent was
as Tim described.

Perhaps the confusion is over the purpose of the <30 day exception. It
wasn't to exempt legacy certificates near the end of their lifetime from
being revoked. It was to allow subscribers to begin using 30-day duration
certificates prior to 15-January without having to replace them on the 15th.

On Wed, Nov 14, 2018 at 4:20 PM Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Validity period is a defined term in the BRs and refers to the time
> between issuance and expiry.  Since the new language uses that term without
> any modifiers like "remaining", it seems clear to me that both of those
> example certificates would need to be revoked.
> 
> From: dev-security-policy 
> on behalf of Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> Sent: Wednesday, November 14, 2018 5:37:20 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: CA Communication: Underscores in dNSNames
>
> Hi Wayne, I wanted to get some clarification.
>
> For example, let's say that a Subscriber has a 1 year certificate which
> expires on 30 January 2019. On 15 January 2019, the remaining validity
> period is less than 30 days; as such, I interpret that the certificate does
> not have to be revoked.
>
> On the other hand, if the Subscriber has a 1 year certificate which
> expires on 31 March 2019, then on 15 January 2019, the remaining validity
> period is greater than 30 days, so this certificate must be revoked.
>
> Is the above interpretation correct?
>
> Thanks, Bruce.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
>
> https://scanmail.trustwave.com/?c=4062=qqPs2ylE2M0AE1hucuCDnbrKTL8yhgbe2AJ51iwegw=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions regarding the qualifications and competency of TUVIT

[Wayne Thayer via dev-security-policy]

It should come as no big surprise that I have documented this issue as our
first auditor compliance bug[1]:
https://bugzilla.mozilla.org/show_bug.cgi?id=1507376

I only included a brief summary of this discussion (and a link to it).
Others are welcome to comment if you feel that I have omitted crucial
information, but please don't start a parallel discussion in the bug.

Ryan and Jacob: in my opinion, you have both remained reasonably respectful
in the midst of a contentious discussion. Thank you very much for that.

While I see some small steps being made toward a common understanding of
the issue, there is still fundamental and subjective disagreement on the
severity, and it's not clear to me that this thread is headed toward any
sort of a constructive conclusion.

I would greatly appreciate everyone's input on the actions (if any, other
than documenting the issue) that Mozilla should take as a result of this
discussion.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MOdS7CH_kU8/Kcl6E9-ZAgAJ

On Wed, Nov 14, 2018 at 5:27 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Once again, you snipped most of what I wrote.
>
> Also not sure why your post has double reply marking.
>
> On 13/11/2018 18:20, Ryan Sleevi wrote:
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

It might be helpful for me to provide a better explanation of the thinking
that went into my recommendation:

The timeline of the Internal Name incident is as follows:
* Identrust appears to have stopped issuing certificates containing .INT
names prior to the BR deadline.
* They then failed to revoke existing certificates prior to the BR
deadline. This is reasonably explained as a mistake - a number of CAs
missed this deadline.
* Any CA following this list at the time should have seen the discussion
about this and taken the initiative to ensure they were in compliance.
Mozilla policy didn't require CAs to follow this list at that time, but
doing so was certainly recognized as a wise thing to do. For unknown
reasons, Identrust didn't get the message.
* In Feb 2018, an unexpired certificate containing a .INT name was reported
to Identrust. They revoked the certificate, but didn't report the incident,
and didn't revoke the other two non-expired certificates.
* In October, that one certificate was reported to this list, and Identrust
provided an incident report and disclosed two other certificates that
should have been revoked in February.

My conclusion from this chain of events is that Identrust plausibly made
two mistakes back in 2016 that left these certificates unrevoked, but was
made aware of the problem in February. At that point, Identrust failed to
investigate further and to disclose the problem. My recommendation stems
primarily from Identrust's actions in Feb which concealed the problem from
the community. I can't speak to their intentions, but I have difficulty
viewing this as a(nother) mistake. I think we've been very clear on our
expectations for CAs to disclose and remediate problems [1] and there have
been abundant examples on this list to learn from. If a CA fails to
disclose a problem and then later gets caught, a strong(er) reaction is
warranted because the CA has violated our trust, regardless of the severity
of the problem.

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident


On Wed, Nov 7, 2018 at 4:30 PM identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:
> > I am recommending denial of this request.
> >
> > It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
> > I'm not going to argue this point and claim that these certificates were
> > misissued because 'identrust.int' and 'identrus.int' were not registered
> > domain names.
> >
> > Under the assumption that these are Internal Names, none of these
> > certificates were issued after the BR deadline of 1-November 2015. From
> > this I would infer that Identrust was aware of the requirements. Three of
> > the disclosed certificates were not expired or revoked prior to the BR
> > Internal Name deadline of 1-October 2016:
> > https://crt.sh/?id=7852280
> > https://crt.sh/?id=882509134
> > https://crt.sh/?id=882509077
> >
> > This happened in spite of well documented incidents in which other CAs
> > failed to revoke certificates containing Internal Names [1]. One of these
> > three certificates was revoked on 22-February 2018, corresponding with
> the
> > date Nick Hatch reported it to Identrust. Identrust did not disclose the
> > incident, nor - given that the other two were never revoked - did they
> > apparently perform a scan of their certificates to identify any others.
> > This calls into question Identrust's ability to adhere to the BRs, their
> > remediation practices, and their willingness to publicly disclose
> incidents.
> >
> > Identrust has requested that Mozilla grant EV indication to the
> Commercial
> > Root CA 1 - the same root involved in this incident. Identrust's actions
> in
> > this incident are troubling and provide justification for denying the
> > higher level of trust implied by EV.
> >
> > - Wayne
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ
> >
> > On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> > > dev-security-policy wrote:
> > > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer
> wrote:
> > > > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> > > dev-security-policy wrote:
> > > > > > > 5.Explanation about how and why the mistakes were made, and not
> > > caught and
> > > > > > > fixed earlier.
> > > > > > >
> > > > > > > IdenTrust:
> > > The certificate was generated for a server within IdenTrust.
> > > > > > > The certificate contained internal domain names which were not
> > > reachable
> > > > > > > externally.  Two domain names in the SAN (
> > > Autodiscover.identrus.int and
> > > > > > > Mercury.identrus.int) were included at that time.  When the
> > > 

Re: How harsh (in general) should Mozilla be towards CAs?

[Wayne Thayer via dev-security-policy]

I'm not convinced there is an answer here. It seems that most would agree
with the premise that we should consider the circumstances and context for
an issue and make a balanced assessment. That leaves the matter of what
this means in practice up for debate. Often, it appears to be a debate
between a strict application of the rules and the seemingly harmless effect
of the particular violation. Unfortunately the "no harm no foul" logic
leads to (takes us back to?) a situation where the rules are suggestions
and any CA can claim that any violation is okay, so long as they 'assessed
the risk'. So I view the 'balance' being between the 'moral hazard' of
excusing a violation and the belief that a violation is harmless in
practice.

As previously mentioned, a secondary consideration when assessing a
seemingly trivial violation is how it reflects on a CA's ability to follow
any rules. I agree that a single failure doesn't necessarily mean the CA is
incompetent, but when we see a pattern of "minor" violations occurring, we
have a problem. Another factor to consider is how 'new' a particular issue
is. The first CA to be called out for making a mistake is less culpable
than those who have ignored the warnings.

I also believe that violations in the context of a new inclusion request
should be treated more seriously because the costs to the ecosystem are
much lower if problems are addressed before a root is included.

- Wayne

On Fri, Nov 9, 2018 at 7:10 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/11/2018 15:52, Hanno Böck wrote:
> > On Fri, 9 Nov 2018 14:56:41 +0100
> > Jakob Bohm via dev-security-policy
> >  wrote:
> >
> >> However there are also some very harsh punishments handed out, such as
> >> distrusting some CAs (most notably happened to Symantec and WoSign,
> >> but others are also teetering), and distrusting auditors (most notably
> >> happened to the branch of Ernst & Young that audited the bad parts of
> >> those two).
> >>
> >> A line of arguments often seen is that someone failed once to do
> >>  completely right, therefore they cannot be trusted to do
> >> anything similar to  right at all, therefore they should no
> >> longer be trusted.
> >
> > I don't think anyone ever said something like that. Particularly
> > I'm not aware of any recent incident where a CA failed *once* and got
> > distrusted.
> >
>
> All 3 lines of reasoning I mentioned (with variations from case to case)
> can be found in two of the most recent threads on this list.
>
> > In the cases you mention - Symantec and Wosign - there were multiple
> > issues. In both cases there was also plenty of opportunity for the
> > affected CAs to explain and improve things before a distrust was
> > even considered. It was repeated failures and a long list of issues
> > that led to the distrust.
> >
>
> I am not saying those two didn't deserve it.  I was just replying to a
> claim that only mild punishments have been used.  I also noted that some
> other CAs are currently being removed or pressured to remove themselves
> for various reasons.
>
> However since the successful distrust of WoSign and Symantec, some here
> seem to have gotten "the taste for blood" and are threatening the same
> punishments for much smaller issues.
>
>
> 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: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

On Wed, Nov 14, 2018 at 9:47 AM Vincent Lynch  wrote:

> Was looking for some quick clarification on interpretation of this bit:
>
> *"All certificates containing an underscore character in any dNSName entry
> and having a validity period of more than 30 days MUST be revoked prior to
> January 15, 2019."*
>
> This language refers to the TOTAL validity period of the certificate, not
> the REMAINING validity, correct?
>
> Correct.

So, for example, a certificate with a NotBefore: 2/1/18 and NotAfter:
> 1/30/19 would have to be revoked?
>

Yes.

Only certificates with a TOTAL validity of <30 days (example, NotBefore:
> 12/20/18, NotAfter: 1/19/19) would be allowed to naturally expire?
>
> Yes. The thinking here is that many organizations don't pay attention to
certificate sunsets (e.g. sha-1) until it affects them directly. By
requiring them to replace their certificates while still allowing some time
to transition away from them via 30-day duration certificates, the hope is
that we will avoid the urgent calls for exceptions we've seen with past
sunset periods.

Thanks,
>
> Vincent
>
> On Mon, Nov 12, 2018 at 4:19 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
>> creating a sunset period for TLS certificates containing an underscore
>> ("_") character in the SAN. This practice was widespread until a year ago
>> when it was pointed out that underscore characters are not permitted in
>> dNSName name forms, and ballot 202 was proposed to create an exception to
>> RFC 5280 that would allow the practice to continue. When that ballot
>> failed, some CAs stopped allowing underscore characters in SANs and others
>> continued. Ballot SC12 is intended to resolve this inconsistency and
>> provide clear guidance to auditors.
>>
>> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
>> an email to all CAs in our program informing them of this change and
>> asking
>> them to take any steps necessary to comply [2].
>>
>> - Wayne
>>
>> [1]
>>
>> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
>> [2]
>>
>> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
> --
> Vincent Lynch
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

Since there haven't been any further comments regarding my recommendation
to deny this request, I would like to ask for feedback on next steps that
Identrust can take in the event of a denial. I believe that Identrust would
still like to pursue EV recognition in Firefox, but I think it's unlikely
that we would approve another request for this root or the other roots they
operate under the same CP/CPS and audits without some evidence that the
issues discussed in this request have been resolved.

Identrust could:
* wait for some period of time during which no new issues are found (1
year?) and reapply for EV indication.
* obtain clean Point-in-Time audit reports and reapply.
* create a new root and apply for EV indication as part of the inclusion
request. Assuming that the new root is cross-signed, we might need to
enable EV for the current root (Commercial Root CA 1) to make the new root
useful for EV issuance.

I think it is reasonable for Identrust to ask how they should proceed, and
I would greatly appreciate everyone's input on this question.

To be clear, the results of this discussion (if any) will only be
suggestions that may improve our trust in Identrust. Mozilla reserves the
right to deny any future requests from Identrust or any CA despite having
followed any or all suggestions that are made.

- Wayne

On Fri, Nov 9, 2018 at 9:26 AM Wayne Thayer  wrote:

> It might be helpful for me to provide a better explanation of the thinking
> that went into my recommendation:
>
> The timeline of the Internal Name incident is as follows:
> * Identrust appears to have stopped issuing certificates containing .INT
> names prior to the BR deadline.
> * They then failed to revoke existing certificates prior to the BR
> deadline. This is reasonably explained as a mistake - a number of CAs
> missed this deadline.
> * Any CA following this list at the time should have seen the discussion
> about this and taken the initiative to ensure they were in compliance.
> Mozilla policy didn't require CAs to follow this list at that time, but
> doing so was certainly recognized as a wise thing to do. For unknown
> reasons, Identrust didn't get the message.
> * In Feb 2018, an unexpired certificate containing a .INT name was
> reported to Identrust. They revoked the certificate, but didn't report the
> incident, and didn't revoke the other two non-expired certificates.
> * In October, that one certificate was reported to this list, and
> Identrust provided an incident report and disclosed two other certificates
> that should have been revoked in February.
>
> My conclusion from this chain of events is that Identrust plausibly made
> two mistakes back in 2016 that left these certificates unrevoked, but was
> made aware of the problem in February. At that point, Identrust failed to
> investigate further and to disclose the problem. My recommendation stems
> primarily from Identrust's actions in Feb which concealed the problem from
> the community. I can't speak to their intentions, but I have difficulty
> viewing this as a(nother) mistake. I think we've been very clear on our
> expectations for CAs to disclose and remediate problems [1] and there have
> been abundant examples on this list to learn from. If a CA fails to
> disclose a problem and then later gets caught, a strong(er) reaction is
> warranted because the CA has violated our trust, regardless of the severity
> of the problem.
>
> [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident
>
>
> On Wed, Nov 7, 2018 at 4:30 PM identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:
>> > I am recommending denial of this request.
>> >
>> > It was not uncommon for CAs to treat the .int TLD as an Internal Name,
>> so
>> > I'm not going to argue this point and claim that these certificates were
>> > misissued because 'identrust.int' and 'identrus.int' were not
>> registered
>> > domain names.
>> >
>> > Under the assumption that these are Internal Names, none of these
>> > certificates were issued after the BR deadline of 1-November 2015. From
>> > this I would infer that Identrust was aware of the requirements. Three
>> of
>> > the disclosed certificates were not expired or revoked prior to the BR
>> > Internal Name deadline of 1-October 2016:
>> > https://crt.sh/?id=7852280
>> > https://crt.sh/?id=882509134
>> > https://crt.sh/?id=882509077
>> >
>> > This happened in spite of well documented incidents in which other CAs
>> > failed to revoke certificates containing Internal Names [1]. One of
>> these
>> > three certificates was revoked on 22-February 2018, corresponding with
>> the
>> > date Nick Hatch reported it to Identrust. Identrust did not disclose the
>> > incident, nor - given that the other two were never revoked - did they
>> > apparently perform a scan of their certificates to identify any others.
>> > This calls into question Identrust's ability to adhere to 

Re: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

It was pointed out that the email I sent to CAs stated that the effective
date of the ballot (once it completed the IPR review period) will be
December 10, **2019**. The year is obviously wrong and contradicts the rest
of the message. The correct effective date is December 10, **2018**. All of
the relevant compliance dates in the email are correct, so I'm not planning
to resend the CA communication.

- Wayne

On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
>> > As you may be aware, the CA/Browser Forum recently passed ballot SC12
>> [1]
>> > creating a sunset period for TLS certificates containing an underscore
>> > ("_") character in the SAN. This practice was widespread until a year
>> ago
>> > when it was pointed out that underscore characters are not permitted in
>> > dNSName name forms, and ballot 202 was proposed to create an exception
>> to
>> > RFC 5280 that would allow the practice to continue. When that ballot
>> > failed, some CAs stopped allowing underscore characters in SANs and
>> others
>> > continued. Ballot SC12 is intended to resolve this inconsistency and
>> > provide clear guidance to auditors.
>> >
>> > The sunset period defined by ballot SC12 is very short. Today Mozilla
>> sent
>> > an email to all CAs in our program informing them of this change and
>> asking
>> > them to take any steps necessary to comply [2].
>> >
>> > - Wayne
>> >
>> > [1]
>> >
>> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
>> > [2]
>> >
>> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[Wayne Thayer via dev-security-policy]

On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I seem to recall that the bad practice was explicitly called out in
> their (old) CP/CPS, which was applicable at the time.  Thus any similar
> misunderstanding should be discoverable by Mozilla and/or their auditor
> comparing the CP/CPS with the BR, Mozilla, National and other applicable
> requirements.  However this has been a long discussion and some posts
> have been expired by the mozilla NNTP server.
>
> Devon discovered this during his review of Certigna's root inclusion
request:
https://groups.google.com/d/msg/mozilla.dev.security.policy/z7iDk9CdTFo/9zQpW1-bCwAJ

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

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[Wayne Thayer via dev-security-policy]

On Wed, Oct 3, 2018 at 7:27 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote:
> > On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > > Thank you for this clear statement of your validation interface design.
> > > Unfortunately, this sounds like a design which is extremely risky,
> from an
> > > unintentional errors perspective.  What form(s) of review for UX,
> including
> > > but not limited to human factors of safety, were applied to this
> interface
> > > prior to it being deployed?
> > >
> > If the implication here is that CAs should apply a high level of UX
> > expertise to their internal validation interfaces, I would wager that
> very
> > few CAs meet your standards.
>
> Whilst I would not want to take the other side of that wager, it's still
> unfortunate that safety-critical UX is treated with such a cavalier
> attitude
> across the industry.
>
> It's useful, for the ecosystem, that Certigna has been willing to identify
> this publicly as a risk in this instance, specifically *because* I agree
> with you -- that very few CAs probably do meet my standards in UX design
> and
> review -- and it is an important thing that all CAs *should*, ideally, be
> taking into account.
>
> My standards, incidentally, are informed by the approaches taken by other
> safety-critical industries, which have seen great benefits from taking UX
> seriously, and I'd like to see a similar approach taken by CAs who wish to
> participate in the web PKI.
>
> Aside from clearly articulating the value of UX design in reducing risk as
you have done, do you have any suggestions for how we could encourage
improvements in this area? It doesn't seem like something that could very
easily be made into a policy.

> > > Each operation performed by an operator is traced so that it can be
> > > > audited.  The periodic audits of registration requests are also
> intended
> > > > to ensure the conduct of controls by RA and the conformity of their
> > > > results.
> > >
> > > Based on your initial report, I got the impression that the misissuance
> > > we're discussing was not picked up by an ordinary operational audit,
> but
> > > was instead identified by some sort of extraordinary review.  Is that
> an
> > > accurate impression?  If so, can you provide more detail around the
> > > criteria you use for selecting operations for auditing, and the
> > > frequency of those audits, with particular reference to how such an
> > > unusual event (overriding a CAA validation failure) wasn't picked up by
> > > ordinary auditing?
> > >
> > Agreed - the misissuance was caught by an audit that was only performed
> > after Certigna's CAA validation practices were questioned. CAs are
> required
> > to audit 3% of issued certificates (BR section 8.7), and I would be
> > surprised if there are many that exceed that requirement, so this seems
> > like an industry-wide concern.
>
> Perhaps the BRs, or Mozilla policy, needs to specify some increased
> vigilance over certificates whose issuance required any sort of override or
> deviation from the "standard" practice?  (Tricky to define "standard"
> practice in a useful fashion, I know...)
>
> Agree - we could perhaps require management review of any deviation from
the standard process, but something like that would be easy to sidestep.

Not that such a policy would have been likely to catch this particular
> problem any quicker, since this specific issue under discussion wasn't due
> to a mistake or malfeasance by an RA, but was instead due to a systemic,
> organisation-wide misinterpretation of the BRs.  In general, though, when
> unusual things happen, it's useful to pay closer attention to what's going
> on, as the chances of mistakes are much higher, and they happen rarely
> enough that the standard 3% sampling is unlikely to catch them by accident.
>
> > > Alternately, if the BRs *are*, in fact, sufficiently clear in all
> respects,
> > > the only other possibility that comes to my mind is that Certigna
> failed to
> > > correctly interpret the BRs, which is far more concerning -- for
> Certigna,
> > > at least.  It would mean that there could be any number of other, as
> yet
> > > unidentified, misunderstandings in Certigna's procedures.  I would
> imagine
> > > there would need to be a very comprehensive review of Certigna's
> processes
> > > and procedures, with a detailed public report of the findings of that
> > > review, for confidence in Certigna to be restored.
> >
> > I think we have established that the problem was with Certigna's chosen
> > interpretation of the BRs. I am not clear on how you are proposing to
> have
> > a "comprehensive review of Certigna's processes and procedures, with a
> > detailed public report of the findings of that review" performed. This
> > sounds like an audit to me?
>
> Not by my understanding 

Re: DoS attack without consequences to Firmaprofesional

[Wayne Thayer via dev-security-policy]

Thank you for reporting this incident Chema. No further actions are
required by Mozilla, but this information may be useful to others in our
community.

- Wayne

On Wed, Oct 3, 2018 at 7:57 AM Chema Lopez via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Good afternoon,
>
> I send this email to inform that on Saturday, October 29th, between 12:00
> and 19:45 (CEST) approximately, the services of Firmaprofesional were
> subject to a denial of service attack (DoS), which, thanks to the company's
> security systems did not have a notable impact. There were some microcuts
> at: 12:03:38, 12:24:38, 14:25:38, 17:45:48, 18:01:38, 18:16:58, 18:32:48,
> 19 : 36: 28 (CEST).
>
> After investigating and ruling out different possible causes, we found that
> it was, indeed, a DoS attack. The following IP addresses were identified as
> attackers and proceeded to block them:
>
>- 167.114.41.148
>- 167.114.41.149
>- 149.56.154.192
>- 149.56.180.253
>- 45.195.133.125
>
> From that moment, no more attacks were received until last Monday 1st of
> Octobre at 14:30 CEST, and until Yesterday, the attack persisted, although,
> again, it is not affecting the services provided by Firmaprofesional.
>
> Just to keep you informed.
>
> Best regards,
>
>
>
>
>
> *Chema López GonzálezDirector Área de Innovación, Cumplimiento y
> TecnologíaAC Firmaprofesional S.A.*
>
>
> Av. Torre Blanca, 57.
> Edificio ESADECREAPOLIS - Local M2
>
> 08173 Sant Cugat del Vallès. Barcelona.
> Tel: 93.477.42.45 / 666.429.224
>
> El contenido de este mensaje y de sus anexos es confidencial. Si no es el
> destinatario, le hacemos saber que está prohibido utilizarlo, divulgarlo
> y/o copiarlo sin tener la autorización correspondiente. Si ha recibido este
> mensaje por error, le agradeceríamos que lo haga saber inmediatamente al
> remitente y que proceda a destruir el mensaje.
> ___
> 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 - Misissuance of one certificate without DNS CAA authorization (Certigna)

[Wayne Thayer via dev-security-policy]

Hi Matt,

I appreciate your interest in getting to the root causes of this issue, and
the polite and professional manner in which you are asking questions.
However, I am concerned that this line of questioning seem to have reached
the limits of Certigna's analysis capabilities, and is thus unlikely to
uncover much more information that helps others in our community to
improve. I think it is time that we draw conclusions from the information
we have rather than continuing a press for answers that can be
misinterpreted as an attack on the CA. If you would like recommend specific
actions from Certigna or Mozilla, please do so.

I have included more specific comments inline, and I would welcome a
meaningful response from Certigna to any of Matt's questions or my comments.

- Wayne

On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 26, 2018 at 07:36:57AM -0700, josselin.allemandou--- via
> dev-security-policy wrote:
> > Thank you for your exchanges. We hope that the additions below will
> answer your questions.
>
> It appears that your response has removed most indications of what parts of
> your message are my questions, compared to your responses.  For clarity,
> I've re-added appropriate formatting, but it would be appreciated if you
> could use standard e-mail formatting in the future.
>
> > > Was the action required to manually override the CAA validation failure
> > > different from what would be required if the CAA validation had
> succeeded?
> > > Could an operator have just "clicked the same button they always
> clicked",
> > > and have the CAA validation failure overridden?  Or was there a
> separate
> > > sequence of UI interactions required to override a CAA validation
> failure?
> > >
> > > This answer does not address the controls in place at the time of the
> > > misissuance.  Any action which an operator can manually take should be
> able
> > > to be audited for correctness, but I don't see any mention of that
> being a
> > > possibility in your response.  I take that to mean that there are no
> > > functional audit logs, or at least that there are no effective audits
> > > (sampling or otherwise) of those logs, for decisions and actions
> undertaken
> > > by registration agents.
> >
> > The check on the authorization to be issued for the organization was the
> > only one that combined both the verification of the consent form and the
> > verification of DNS CAA alerts.  The operator could view the alert but
> the
> > same validation button was used to proceed to the next step, whether the
> > DNS CAA is valid or not.
>
> Thank you for this clear statement of your validation interface design.
> Unfortunately, this sounds like a design which is extremely risky, from an
> unintentional errors perspective.  What form(s) of review for UX, including
> but not limited to human factors of safety, were applied to this interface
> prior to it being deployed?
>
> If the implication here is that CAs should apply a high level of UX
expertise to their internal validation interfaces, I would wager that very
few CAs meet your standards.

> Each operation performed by an operator is traced so that it can be
> > audited.  The periodic audits of registration requests are also intended
> > to ensure the conduct of controls by RA and the conformity of their
> > results.
>
> Based on your initial report, I got the impression that the misissuance
> we're discussing was not picked up by an ordinary operational audit, but
> was
> instead identified by some sort of extraordinary review.  Is that an
> accurate impression?  If so, can you provide more detail around the
> criteria you use for selecting operations for auditing, and the frequency
> of
> those audits, with particular reference to how such an unusual event
> (overriding a CAA validation failure) wasn't picked up by ordinary
> auditing?
>
> Agreed - the misissuance was caught by an audit that was only performed
after Certigna's CAA validation practices were questioned. CAs are required
to audit 3% of issued certificates (BR section 8.7), and I would be
surprised if there are many that exceed that requirement, so this seems
like an industry-wide concern.

> > This sounds like there may have been a misunderstanding in the BR
> > > description of CAA validation.
> > >
> > > What specific language in the BRs surrounding CAA validation caused
> you to
> > > believe that successful CAA validation was optional in the presence of
> other
> > > forms of consent?
> > >
> > > What changes do you propose in the language of the CAA validation
> > > requirements in the BRs to ensure that no other CA could possibly
> > > misunderstand the CAA validation requirements?
> >
> > We have no improvement to issue regarding BRs.  We understood the
> > requirement and implemented the DNS CAA control but we made two errors:
> >
> > - The first is to have assessed that the existing control having the same
>