Re: Entrust Root Certification Authority - G4 Inclusion Request

2019-10-17 Thread Wayne Thayer via dev-security-policy
Having received no further comments, I have recommended approval of this
request in bug 1480510.

- Wayne

On Tue, Oct 8, 2019 at 4:23 PM Wayne Thayer  wrote:

> On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
>>
>> > We will update section 4.2 and 9.12.3 in the next release of the CPS.
>>
>> The CPS Has been updated to address the above issues, see
>> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf
>> .
>>
>> I've verified these updates.
>
> This request has been in discussion for quite a while now. Please post any
> further comments by next Tuesday 15-October, and I will plan to end the
> discussion period at that time.
>
> - Wayne
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Entrust Root Certification Authority - G4 Inclusion Request

2019-10-08 Thread Wayne Thayer via dev-security-policy
On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
>
> > We will update section 4.2 and 9.12.3 in the next release of the CPS.
>
> The CPS Has been updated to address the above issues, see
> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf
> .
>
> I've verified these updates.

This request has been in discussion for quite a while now. Please post any
further comments by next Tuesday 15-October, and I will plan to end the
discussion period at that time.

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


Re: Mozilla Policy Requirements CA Incidents

2019-10-08 Thread Wayne Thayer via dev-security-policy
Ryan,

Thank you for pointing out these incidents, and for raising the meta-issue
of policy compliance. We saw similar issues with CP/CPS compliance to
changes in the 2.5 and 2.6 versions of policy, with little explanation
beyond "it's hard to update our CPS" and "oops". Historically, our approach
has been to strive to communicate policy updates to CAs with the assumption
that they will happily comply with all of the requirements they are aware
of. I don't think that's a bad thing to continue, but I agree it is is not
working.

Having said that, I do recognize that translating "Intermediates must
contain EKUs" into "don't renew this particular certificate" across an
organization isn't as easy as it sounds. I'd be really interested in
hearing how CAs are successfully managing the task of adapting to new
requirements and if there is something we can do to encourage all CAs to
adopt best practices in this regard. Our reactive options short of outright
distrust are limited- so I think it would be worthwhile to focus on new
preventive measures.

Thanks,

Wayne

On Tue, Oct 8, 2019 at 11:02 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On the topic of root causes, there's also
> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3425554 that was
> recently published. I'm not sure if that was peer reviewed, but it does
> provide an analysis of m.d.s.p and Bugzilla. I have some concerns about the
> study methodology (for example, when incident reports became normalized is
> relevant, as well as incident reporting where security researchers first
> went to the CA), but I think it looks at root causes a bit holistically.
>
> I recently shared on the CA/B Forum's mailing list another example of
> "routine" violation:
> https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html
>
> My concern is that, 7 years later, while I think that compliance has
> marginally improved (largely due to things led by outside the CA ecosystem,
> like CT and ZLint/Certlint), I think the answers/responses/explanations we
> get are still falling into the same predictable buckets, and that concerns
> me, because it's neither sustainable nor healthy for the ecosystem.
>
>
>- We misinterpreted the requirements. It said X, but we thought it meant
>Y (Often: even though there's nothing in the text to support Y, that's
> just
>how we used to do business, and we're CAs so we know more than browsers
>about what browsers expect from us)
>- We weren't paying attention to the updates. We've now assigned people
>to follow updates.
>- We do X by saying our staff should do X. In this case, they forgot.
>We've retrained our staff / replaced our staff / added more staff to
>correct this.
>- We had a bug. We did not detect the bug because we did not have tests
>for this. We've added tests.
>- We weren't sure if X was wrong, but since no one complained, we
>assumed it was OK.
>- Our auditor said it was OK
>- Our vendor said it was OK
>
> and so forth.
>
> And then, in the responses, we generally see:
>
>- These certificates are used in Very Important Systems, so even though
>we said we'd comply, we cannot comply.
>- We don't think X is actually bad. We think X should be OK, and it
>should be Browsers that reject X if they don't like X (implicit: But
> they
>should still trust our CA, even though we aren't doing what they want)
>- Our vendor is not able to develop a fix in time, so we need more time.
>- We agree that X is bad, and has always been prohibited, but we need
>more time to actually implement a fix (because we did not
> plan/budget/staff
>to actually handle issues of non-compliance)
>
> and so forth.
>
> It's tiring and exhausting because we're hearing the same stuff. The same
> patterns that CAs were using when they'd issue MITM certs to companies:
> "Oh, wait, you mean't DON'T issue MITM certs? We didn't realize THAT'S what
> you meant" (recall, this was at least one CA's response when caught issuing
> MITM certs).
>
> I'm exasperated because we're seeing CAs do things like not audit sub-CAs,
> but leaving all the risk to be accepted by browsers, because it's too
> hard/complex to migrate. We're seeing things like CA's not follow policy
> requirements, but then correcting those issues is risky because now they've
> issued a bunch of certs and it's painful to have to replace them all.
>
> If we go back to that classic Dan Geer talk,
> https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html , every time a CA
> issues a certificate, they've now externalized the risk onto browsers/root
> stores for that certificate lifetime. It's left to the ecosystem to detect
> and clean up the mess, while the CA/subscriber gets the full benefits of
> the issuance. It's a system of incentives that is completely misaligned,
> and we've seen it now for the past decade: The CA benefits from the
> (mis)issuance, and 

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-10-04 Thread Wayne Thayer via dev-security-policy
Jeremy Rowley posted the following comments in a separate thread:

One suggestion on incident reports is to define "regularly update" as some
> period of time as non-responses can result in additional incident reports.
> Maybe something along the lines of "the greater of every 7 days, the time
> period specified in the next update field by Mozilla, or the time period
> for the next update as agreed upon with Mozilla". I'd also change "the
> corresponding bug is resolved by a Mozilla representative" to "the
> corresponding bug is marked as resolved in bugzilla by a Mozilla
> representative" since the CA is resolving the actual bug, and Mozilla is
> managing its perception on the bug's status.
>

While I agree with the intent, I do fear that something this strict in
policy creates the wrong incentives (e.g. bots that auto-comment bugs with
no real updates, and others that create new incidents after 7 days and one
second). I'd be okay with adding something like "CAs SHOULD update status
weekly and MUST provide status updates at least every 30 days unless
otherwise agreed by a Mozilla representative."

The addition of "marked as resolved" makes sense to me.

On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:

>
> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer  wrote:
>
>>
>> I've drafted a specific proposal for everyone's consideration:
>>
>>
>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>
>>
> Having received no new comments on this proposal, I'll consider this issue
> closed and plan to include it in policy version 2.7.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.7 Proposal: Update Appeal Process

2019-10-04 Thread Wayne Thayer via dev-security-policy
The last sentence of section 1.2 Policy Ownership states:

CAs or others objecting to a particular decision by either team MAY appeal
> to the Mozilla governance module owner
>  who will make a
> final decision.
>

Last year [1], Mozilla delegated this responsibility to the Firefox
Technical Leadership Module [2], and I have updated this sentence to
reflect that change [3].

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

I will plan to make this change unless objections are raised.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.governance/YTTqUzWaJ00/-MopTK71AwAJ
[2] https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership
[3]
https://github.com/mozilla/pkipolicy/commit/2a30327cde67e9431cb9d6b5c270d7ad855887bd
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

2019-10-04 Thread Wayne Thayer via dev-security-policy
I'd like to revive this discussion. So far we've established that the
existing "required practice" [1] is too stringent for email address
validation and needs to be changed. We can do that by removing email
addresses from the scope of the requirement as Kathleen proposed, or by
exempting the local part of the email address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how
removing the requirement entirely is beneficial, but no one else has spoken
in favor of this need. Kathleen did however point out that this requirement
doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
arguing that the process described by Ryan Hurst is insecure and thus a
reason to forbid delegation of validation of the domain name part. Pedro
Fuentes also wrote in favor of this outcome.

One thing that might help to resolve this is a more detailed description of
the weaknesses that are present in the process described by Ryan Hurst. If
we can all agree that the process is vulnerable, then it seems that we'd
have a strong argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to third
> > parties. However, the BRs don't forbid delegation of email address
> > validation nor do they apply to S/MIME certificates.
> >
> > Delegation of email address validation is already addressed by Mozilla's
> > Forbidden Practices [1] state:
> >
> > "Domain and Email validation are core requirements of the Mozilla's Root
> > Store Policy and should always be incorporated into the issuing CA's
> > procedures. Delegating this function to 3rd parties is not permitted."
> >
> > I propose that we move this statement (changing "the Mozilla's Root Store
> > Policy" to "this policy") into policy section 2.2 "Validation Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> Domain and Email validation are core requirements of the Mozilla's Root
> Store Policy and should always be incorporated into the issuing CA's
> procedures. Delegating this function to 3rd parties is not permitted."
>
> Based on the way that section is written, it appears that domain
> validation (and the BRs) was the primary consideration, and that the
> Email part of it was an afterthought, or added later. Historically, my
> attention has been focused on TLS certs, so it is possible that the
> ramifications of adding Email validation to this section was not fully
> thought through.
>
> I don't remember who added this email validation text or when, but I can
> tell you that when I review root inclusion requests I have only been
> concerned about making sure that domain validation is not being
> delegated to 3rd parties. It wasn't until a representative of a CA
> brought this to my attention that I realized that there has been a
> difference in text on this wiki page versus the rules I have been trying
> to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant security reasons to add our own
> S/MIME required/forbidden practices at this time, my preference is to
> wait for the CA/Browser Forum to create the S/MIME Working Group, and
> for that group to identify the S/MIME baseline requirements. Then we can
> add policy and required/forbidden practices based on the S/MIME BRs
> provided by that group.
>
> I do realize that my proposal is unfair to CAs who have been diligently
> following this section of this wiki page. Your diligence is appreciated,
> and your contributions to this discussion will also be appreciated.
>
> 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

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-10-04 Thread Wayne Thayer via dev-security-policy
rrect profile information. The long cycle in
> getting information,  being a middle-man information gathering, and trying
> to convey both Mozilla and CAB forum policy makes controlling compliance
> very difficult, and a practice I would not recommend to any CA. Once you've
> established a relationship as a signer CA (or acquired a relationship),
> extraditing yourself is... difficult.  The certificates end up embedded on
> smart cards, used by government institutions and pinned in weird places.
> And the unfortunate part is you don't have the direct relationship with the
> end-user to offer counsel against some of the practices. That extra
> abstraction layer between the CA and root store program ends up adding a
> lot more complexity than you'd initially think. Delegating the CA
> responsibility ends up being a bad idea and takes years to fix. DigiCert is
> finally down to the final few TLS sub CAs (5) and each are operating in
> OCSP signing mode only. They'll all be revoked in 2020.
>
>
Unless I'm missing something, DigiCert is continuing to issue externally
operated S/MIME sub CAs, e.g. https://crt.sh/?id=1652799594

Jeremy
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Thursday, October 3, 2019 2:45 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate
> CAs
>
> I'd like to revisit this topic because I see it as a significant change
> and am surprised that it didn't generate any discussion.
>
> Taking a step back, a change [1] to notification requirements was made
> last year to require CAs that are signing unconstrained subordinate CAs
> (including cross-certs) controlled by a different organization to notify
> Mozilla. We have received few, if any, notifications of this nature, so I
> have to wonder if CAs are adhering to this requirement.
>
> This requirement applies as follows:
>
> an organization other than the CA obtains control of an unconstrained
> > intermediate certificate (as defined in section 5.3.2 of this policy)
> > that directly or transitively chains to the CA's included
> > certificate(s);
> >
>
> Is the "obtains control" language being interpreted to mean that this only
> applies when control of the private keys change, and not when a CA signs a
> key controlled by a different organization? I believe the intent is for
> this to apply in both situations - otherwise it is trivial to bypass.
>
> The new change [2] proposed for version 2.7 of our policy goes one step
> further and places transfers and signings of unconstrained subordinate CAs
> clearly in the scope of section 8.1, including the following language:
>
> If the receiving or acquiring company is new to the Mozilla root program,
> > it must demonstrate compliance with the entirety of this policy and
> > there MUST be a public discussion regarding their admittance to the
> > root program, which Mozilla must resolve with a positive conclusion in
> > order for the affected certificate(s) to remain in the root program.
> > If the entire CA operation is not included in the scope of the
> > transaction, issuance is not permitted until the discussion has been
> resolved with a positive conclusion.
>
>
> That means any organization "new to the Mozilla root program" for which a
> CA signs an unconstrained subordinate CA or cross-cert must go through an
> approval process including a public discussion before issuing certificates
> in order to comply with this policy.
>
> It also means that we need to decide what "new to the Mozilla root program"
> means. Organizations that control unconstrained subordinate CAs have not
> been considered members of the program in the past, so it's easy to argue
> that every such organization will be "new to the Mozilla root program"
> if/when this policy goes into effect. However, it may be more practical to
> "grandfather in" organizations that are currently in control of
> unconstrained subordinate CAs.
>
> This also raises the question of what it means to "demonstrate compliance
> with the entirety of this policy". Section 8.1 has historically applied to
> companies acquiring root CAs and we have not required them to go through
> the entire inclusion process - only a public discussion. Should that same
> interpretation apply to unconstrained subordinate CA?
>
> Before proposing any changes, I'd like to ask for everyone's input on
> these and any other concerns stemming from this policy proposal.
>
> - Wayne
>
> [1]
>
> https://github.com/mozilla/pkipolicy/commit/7a3

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-10-03 Thread Wayne Thayer via dev-security-policy
I'd like to revisit this topic because I see it as a significant change and
am surprised that it didn't generate any discussion.

Taking a step back, a change [1] to notification requirements was made last
year to require CAs that are signing unconstrained subordinate CAs
(including cross-certs) controlled by a different organization to notify
Mozilla. We have received few, if any, notifications of this nature, so I
have to wonder if CAs are adhering to this requirement.

This requirement applies as follows:

an organization other than the CA obtains control of an unconstrained
> intermediate certificate (as defined in section 5.3.2 of this policy) that
> directly or transitively chains to the CA's included certificate(s);
>

Is the "obtains control" language being interpreted to mean that this only
applies when control of the private keys change, and not when a CA signs a
key controlled by a different organization? I believe the intent is for
this to apply in both situations - otherwise it is trivial to bypass.

The new change [2] proposed for version 2.7 of our policy goes one step
further and places transfers and signings of unconstrained subordinate CAs
clearly in the scope of section 8.1, including the following language:

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


That means any organization "new to the Mozilla root program" for which a
CA signs an unconstrained subordinate CA or cross-cert must go through an
approval process including a public discussion before issuing certificates
in order to comply with this policy.

It also means that we need to decide what "new to the Mozilla root program"
means. Organizations that control unconstrained subordinate CAs have not
been considered members of the program in the past, so it's easy to argue
that every such organization will be "new to the Mozilla root program"
if/when this policy goes into effect. However, it may be more practical to
"grandfather in" organizations that are currently in control of
unconstrained subordinate CAs.

This also raises the question of what it means to "demonstrate compliance
with the entirety of this policy". Section 8.1 has historically applied to
companies acquiring root CAs and we have not required them to go through
the entire inclusion process - only a public discussion. Should that same
interpretation apply to unconstrained subordinate CA?

Before proposing any changes, I'd like to ask for everyone's input on these
and any other concerns stemming from this policy proposal.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
[2]
https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8


On Fri, May 10, 2019 at 1:58 PM Wayne Thayer  wrote:

> Having received no comments on these proposed changes, I plan to include
> them in version 2.7 of our policy.
>
> - Wayne
>
> On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer  wrote:
>
>> Ryan Sleevi made the following proposal:
>>
>> Issue #122 [1] previously discussed Section 8 in the context of
>>> subordinate CAs, with a change [2] being made to include subordinate CAs
>>> (in the context of Section 5.3.2) within scope of notification requirements.
>>>
>>> However, as presently worded, it's ambiguous as to whether or not
>>> Sections 8.1 through 8.3 also apply to subordinate CAs, or whether the only
>>> disclosure required is upon the initial introduction of the subordinate.
>>> This confusion results from language such as in Section 8.1, "or when an
>>> organization buys the private key of a certificate in Mozilla's root
>>> program", implying that private keys which transitively chain to a root
>>> certificate within Mozilla's program are exempt from such requirements.
>>>
>>> This ambiguity creates incentives for situations such as cross-signing
>>> CAs that might otherwise or have been otherwise rejected from direct
>>> inclusion within the Mozilla program. It further creates issues with
>>> respect to the supervision of audits and auditors.
>>>
>>> While it is true that the signing CA accepts the risk that an
>>> unfavorable verdict on the subordinate may impact the root, the cost of
>>> such a decision is primarily borne by Mozilla and the broader community, in
>>> that they are responsible for the collateral ecosystem challenges and
>>> devising appropriate solutions. This has been demonstrated, for example,
>>> through the discussion of Symantec issues [3].
>>>
>>> Because Mozilla and the community bear significant cost, 

Re: DigiCert OCSP services returns 1 byte

2019-10-03 Thread Wayne Thayer via dev-security-policy
I've gone ahead and moved [4] to the "Recommended Practices" section.

The ballot to modify the BRs is now in the formal discussion period leading
up to a vote [5].

I'll be resolving the existing compliance bugs on this issue as INVALID.
I'd like to thank the CAs that proactively submitted incident reports
rather than taking a "wait and see" approach. That degree of transparency
is both appreciated and encouraged.

- Wayne

[5] https://cabforum.org/pipermail/servercert-wg/2019-October/001145.html

On Wed, Oct 2, 2019 at 2:20 AM Rob Stradling  wrote:

> On 02/10/2019 00:51, Wayne Thayer wrote:
> > On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> >
> > I propose that you update [4] to say that Mozilla won't treat
> > non-compliance with [4] as an "incident" whilst it remains the case
> > that the BRs are inconsistent with [4].
> >
> > I could simply move [4] to a "recommended practice" (SHOULD) until the
> > ballot comes into force, then move it back to "required". That implies
> > that the bugs which have been opened for this specific issue (responding
> > "unknown" - not to be confused with "returns 1 byte") will be closed as
> > INVALID.
> >
> > Are there strong objections to this course of action?
>
> It seems a bit strange to recommend a practice that CAs cannot currently
> adhere to without violating the BRs and some other root programs'
> policies, but at the same time it is helpful to signpost upcoming policy
> changes.
>
> I don't object strongly.
>
> > - Wayne
> >
> > [4]
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

2019-10-02 Thread Wayne Thayer via dev-security-policy
Thank you Ryan. Brian reviewed these changes back in May, so I've gone
ahead and accepted them for the 2.7 policy update:
https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27

I'll consider this issue resolved unless there are further comments.

- Wayne

On Fri, May 24, 2019 at 1:38 AM Ryan Sleevi  wrote:

>
>
> On Wed, May 22, 2019 at 7:43 PM Brian Smith  wrote:
>
>> Ryan Sleevi  wrote:
>>
>>>
>>>
 It would be easier to understand if this is true if the proposed text
 cited the RFCs, like RFC 4055, that actually impose the requirements that
 result in the given encodings.

>>>
>>> Could you clarify, do you just mean adding references to each of the
>>> example encodings (such as the above example, for the SPKI encoding)?
>>>
>>
>> Exactly. That way, it is clear that the given encodings are not imposing
>> a new requirement, and it would be clear which standard is being used to
>> determine to correct encoding.
>>
>
> Thanks, did that in
> https://github.com/sleevi/pkipolicy/commit/80da8acded63618a058d26c73db1e2438a6df9ed
>
>
>>
>> I realize that determining the encoding from each of these cited specs
>> would require understanding more specifications, including in particular
>> how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
>> calling out all of these details individually less people get confused by
>> inevitable omissions.
>>
>
> Hopefully struck the right balance. These changes are now reflected in the
> PR at https://github.com/mozilla/pkipolicy/pull/183
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-10-02 Thread Wayne Thayer via dev-security-policy
On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道:
> > The BRs require EKUs in leaf TLS certs, but there is no equivalent
> > requirement for S/MIME certificates. This leads to confusion such as [1]
> in
> > which certificates that are not intended for TLS or S/MIME fall within
> the
> > scope of our policies.
> >
> > Simply requiring EKUs in S/MIME certificates won't solve the problem
> unless
> > we are willing to exempt certificates without an EKU from our policies,
> and
> > doing that would create a rather obvious loophole for issuing S/MIME
> > certificates that don't adhere to our policies.
> >
> > The proposed solution is to require EKUs in all certificates that chain
> up
> > to roots in our program, starting on some future effective date (e.g.
> April
> > 1, 2020). This has the potential to cause some compatibility problems
> that
> > would be difficult to measure and assess. Before drafting language for
> this
> > proposal, I would like to gauge everyone's support for this proposal.
> >
> > Alternately, we could easily argue that section 1.1 of our existing
> policy
> > already makes it clear that CAs must include EKUs other than
> > id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
> > to remain out of scope for our policies.
> >
> > This is https://github.com/mozilla/pkipolicy/issues/163
> >
> > I will greatly appreciate everyone's input on this topic.
> >
> > - Wayne
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
>
>
> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption EKU,
> and coordinate all subordinate Cas(Five CAs) and application system’s
> owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple
> evaluations, it is decided to officially add the EKU to the user
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>
I had expected to have this policy update completed sooner when I proposed
April 2020 as the date for requiring EKUs in end-entity certificates. Given
that, I think it's reasonable to push the date back to July 2020, but not
to January 2021. 2021 seems particularly unreasonable in light of the
Microsoft requirement [1] that went into effect in January 2017 and appears
to apply to GPKI.

Will any other CAs find it impossible to meet this requirement for
certificates issued after June 2020? Also, are there any concerns with this
applying to certificates issued from technically constrained intermediate
CA certificates? As-proposed, this applies to those certificates (and it
appears to me that Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-10-02 Thread Wayne Thayer via dev-security-policy
Thank you for the comments Dimitris. I think you make a valid point in
general that S/MIME certificates are quite different from TLS certificates,
and applying the BR rules to them might not be appropriate. I expect this
to ultimately be sorted out by the CAB Forum's future S/MIME Working Group,
but in the interim we still need some reasonable Mozilla policy. This leads
me to conclude that the best solution might be to do as Kathleen suggested
and reinstate the old Mozilla revocation requirements (prior to referencing
the BRs) to apply to S/MIME certificates:
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
The biggest change here from my earlier proposal would be that no
revocation timeline would be specified.

I also suggest that we add a requirement for both TLS and S/MIME
certificates that states the CA must revoke a certificate that "does not
comply with the version of this policy that was in effect at the time it
was issued.". Currently, there is no hard requirement for CAs to revoke
certificates that comply with the BRs but not with our own policy (e.g. use
of the P-521 algorithm [1]).

How do these changes sound to everyone?

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/_eJvekr1BgAJ

On Fri, Jun 14, 2019 at 10:43 PM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
> Dear Wayne,
>
> Please consider the fact that S/MIME is focused on "signature"
> Certificates which has different considerations than "authentication"
> Certificates. The baseline requirements (and their revocation
> requirements) are focused on "authentication" Certificates. I believe
> the revocation policies, at least for the CA Certificates, do not align
> well with S/MIME.
>
> When a piece of data is "signed" (such as an e-mail), Relying Parties
> need to be able to verify the status of the signing Certificate _when
> the signature was created_. If the Issuing CA is revoked, it is no
> longer able to provide status information for that Certificate. If we
> think about the serial number issue, if a CA had to be revoked, status
> information for its issued Certificates would discontinue leading
> Relying Parties to have difficulties validating the existing signed
> e-mails that were valid when signed.
>
> This might be something to consider more carefully.
>
>
> Thank you,
> Dimitris.
>
>
> On 15/5/2019 3:25 π.μ., Wayne Thayer via dev-security-policy wrote:
> > On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy
> <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 5/10/19 5:46 PM, Wayne Thayer wrote:
> >>> I've attempted to update section 6 to incorporate revocation
> requirements
> >>> for S/MIME certificates:
> >>>
> >>>
> >>
> https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637
> >>> Note: since much of this language is copied directly from the BRs, if
> we
> >>> decide to adopt it, the policy will also need to comply with the
> Creative
> >>> Commons Attribution 4.0 International license used by the BRs.
> >>>
> >>> I will greatly appreciate everyone's review and comments on this
> proposed
> >>> change.
> >>
> >> The proposed changes look OK to me.
> >>
> >> But I would also be fine with the new section 6.2 regarding revocation
> >> of S/MIME certs just re-using the revocation text that we used to have
> >> in our policy (which had been removed in an effort to remove redundancy
> >> with the BRs).
> >>
> >>
> >>
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
> >>
> >>
> > The 'reasons for revocation' from the old policy are very close to the BR
> > language I proposed. The main difference in my proposal is the inclusion
> of
> > deadlines by which certificates must be revoked (same as in the BRs).
> While
> > the BR deadlines have sometimes been challenging, I do feel that we're
> > better off to have them as our standard and handle exceptions as
> incidents,
> > so my preference is to stick with my proposal.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Next Root Store Policy Update

2019-10-02 Thread Wayne Thayer via dev-security-policy
Over the past 3 months, a number of other projects distracted me from this
work. Now I'd like to focus on finishing these updates to our Root Store
policy. There are roughly 6 issues remaining to be discussed, and I will,
as always, greatly appreciate everyone's input on them. I'll be sending out
individual emails on each issue.

Meanwhile, you can view a redline of the changes we previously agreed on:
https://github.com/mozilla/pkipolicy/compare/master...2.7

- Wayne

On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:

> I've added a few more issues that were recently created to the list for
> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>
> 176 - Clarify revocation requirements for S/MIME certs
> 175 - Forbidden Practices wiki page says email validation cannot be
> delegated to 3rd parties
>
> I plan to begin posting issues for discussion shortly.
>
>
> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>
>> Later this month, I would like to begin discussing a number of proposed
>> changes to the Mozilla Root Store policy [1]. I have reviewed the list of
>> issues on GitHub and labeled the ones that I recommend discussing:
>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>
>> 173 - Strengthen requirement for newly included roots to meet all current
>> requirements
>> 172 - Update section 5.3 to include Policy Certification Authorities as
>> an exception to the mandatory EKU inclusion requirement
>> 171 - Require binding of CA certificates to CP/CPS
>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair
>> 169, 140 - Extend Section 8 to also encompass subordinate CAs
>> 168, 161, 158  - Require Incident Reports, move practices into policy
>> 163 - Require EKUs in end-entity certificates (S/MIME)
>> 162 - Require disclosure of CA software vendor/version in incident report
>> 159 - Clarify section 5.3.1 Technically Constrained
>> 152 - Add EV audit exception for policy constrained intermediates
>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>
>> I will appreciate any feedback on the proposed list of issues to discuss.
>>
>> I do recognize that the current DarkMatter discussions could result in
>> the need to add some additional items to this list.
>>
>> I have created a new branch for drafting these changes [1] and made one
>> commit that adds a bullet to the BR Conformance section informing the
>> reader that Mozilla policy has a more restrictive list of approved
>> algorithms [3]
>>
>> As we've done in the past, I plan to post individual issues for
>> discussion in small batches over the next few months, with the goal of
>> finalizing version 2.7 by June.
>>
>> - Wayne
>>
>> [1]
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
>> [2] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
>> [3] https://github.com/mozilla/pkipolicy/issues/167
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DigiCert OCSP services returns 1 byte

2019-10-01 Thread Wayne Thayer via dev-security-policy
On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling  wrote:

>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case that
> the BRs are inconsistent with [4].
>
>
I could simply move [4] to a "recommended practice" (SHOULD) until the
ballot comes into force, then move it back to "required". That implies that
the bugs which have been opened for this specific issue (responding
"unknown" - not to be confused with "returns 1 byte") will be closed as
INVALID.

Are there strong objections to this course of action?

- Wayne

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


Re: DigiCert OCSP services returns 1 byte

2019-09-30 Thread Wayne Thayer via dev-security-policy
I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
identified.

I also want to acknowledge the feedback from Google on the timing of this.
I can appreciate the framing of this as a new policy that's been added
without due process, but I view this as a clarification of existing
requirements. Some CAs have already been held accountable for this
requirement [2] and some that have been paying close attention adhere to
it. Others were struggling to determine what to do. Under these
circumstances, it made no sense to me to roll back the policy, so the only
reasonable course was to clarify it in favor of the consensus that emerged
from this thread.

I'm still open to making changes to our "required practice" on
precertificates, but having caught up on the thread I don't think any
further changes are necessary.

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/00.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

On Wed, Sep 25, 2019 at 3:59 AM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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


Re: Outdated resource links on CCADB

2019-09-30 Thread Wayne Thayer via dev-security-policy
Thank you for reporting this Matthew. I've updated that page with the
correct links: https://www.ccadb.org/resources

- Wayne

On Mon, Sep 23, 2019 at 8:23 AM Jos Purvis (jopurvis) via
dev-security-policy  wrote:

> Heh--my bad, I read that as "cabforum.org". I'll correct it there as
> well, but Kathleen or Wayne would have to handle the CCADB pages, methinks.
>
> Kathleen/Wayne: I did get confirmation from Mike at Microsoft that those
> are the correct URLs for their sites. :)
>
>
> --
> Jos Purvis (jopur...@cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  |
>
>
> On 9/23/19, 9:48 AM, "dev-security-policy on behalf of Jos Purvis
> (jopurvis) via dev-security-policy" <
> dev-security-policy-boun...@lists.mozilla.org on behalf of
> dev-security-policy@lists.mozilla.org> wrote:
>
> Thanks for pointing that out! I'll confirm those quickly with
> Microsoft and then fix up the links.
>
> Cheers,
>
> Jos
>
>
> --
> Jos Purvis (jopur...@cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  |
>
>
> On 9/22/19, 11:16 PM, "dev-security-policy on behalf of Mathew Hodson
> via dev-security-policy"  on behalf of dev-security-policy@lists.mozilla.org> wrote:
>
> On https://www.ccadb.org/resources some of the Microsoft links are
> outdated and need to be updated.
>
> Trusted Root Program Portal page is obsolete and can be removed
> since
> there is no equivalent page on docs.microsoft.com.
>
> Trusted Root Program Requirements new page at
> https://aka.ms/RootCert
>
> Trusted Root Certificate Program Updates new page at
> https://aka.ms/rootupdates
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DigiCert OCSP services returns 1 byte

2019-09-20 Thread Wayne Thayer via dev-security-policy
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos 
wrote:

> 
>
> Using the following practice as described in RFC 6960 should not be a
> violation of the BRs. That is, answering revoked where a pre-certificate
> has been issued but not the final certificate should be OK as long as the
> response contains the Extended Revoked extension and the revocationReason
> is certificateHold. With this practice, it is very clear that the final
> certificate has
> not been issued, so would this be considered a violation of the Mozilla
> policy?
>
Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
responder to return a certificateHold reason in a response for a
precertificate. As you noted, the BRs forbid certificate suspension.
Mozilla assumes that a certificate corresponding to every precertificate
exists, so the OCSP response would be interpreted as applying to a
certificate and thus violating the BRs.

In practice, I also think that Ryan has raised a good point about OCSP
response caching. If a revoked response for a precertificate were supplied
by a CA, would the Subscriber need to wait until that response expires
before using the certificate, or else risk that some user agent has cached
the revoked response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Apple: Precertificates without corresponding certificates return OCSP value of "unknown"

2019-09-19 Thread Wayne Thayer via dev-security-policy
Thank you for the notification. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1582519 to track this issue.

- Wayne

On Fri, Sep 13, 2019 at 4:24 PM Apple CA via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We’ve been following the discussions regarding how OCSP responders should
> handle Precertificates without corresponding certificates and what the
> appropriate response indicator should be (good, revoked, or unknown).
>
> Based on the recent clarifications at [1], we want to inform the community
> that Apple’s OCSP responders return a status of “unknown” for
> Precertificates without a corresponding certificate. We have identified one
> Precertificate that did not result in a corresponding certificate for which
> our OCSP responders are returning a status of “unknown” (
> https://crt.sh/?id=1368484681).
>
> We’ve updated the OCSP responders to respond “good” for that
> Precertificate and a long-term fix is in progress.
>
> We appreciate the efforts being made to amend the Mozilla Root Store
> Policy to explicitly address matters relating to Certificate Transparency.
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/24Fl9kc-AQAJ
> ___
> 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: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Wayne Thayer via dev-security-policy
I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.

I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.

- Wayne

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer  wrote:

> Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
> and Ryan's:
>
> The current implementation of Certificate Transparency does not provide
>> any way for Relying Parties to determine if a certificate corresponding to
>> a given precertificate has or has not been issued. It is only safe to
>> assume that a certificate corresponding to every precertificate exists.
>>
>> RFC 6962 states “The signature on the TBSCertificate indicates the
>> certificate authority's intent to issue a certificate.  This intent is
>> considered binding (i.e., misissuance of the Precertificate is considered
>> equal to misissuance of the final certificate).”
>>
>> However, BR 7.1.2.5 states “For purposes of clarification, a
>> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
>> not be considered to be a “certificate” subject to the requirements of RFC
>> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
>> Revocation List (CRL) Profile under these Baseline Requirements.”
>>
>> Mozilla interprets the BR language as a specific exception allowing CAs
>> to issue a precertificate containing the same serial number as the
>> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
>> a precertificate that a corresponding certificate has been issued.
>>
>> This means, for example, that:
>>
>> * A CA must provide OCSP services and responses in accordance with
>> Mozilla policy for all certificates presumed to exist based on the presence
>> of a Precertificate, even if the certificate does not actually exist
>> * A CA must be able to revoke a certificate presumed to exist, if
>> revocation of the certificate is required under Mozilla policy, even if the
>> certificate does not actually exist.
>> * If any corresponding certificate with the same serial number and issuer
>> exists, and can not be verified to match the precertificate using the
>> algorithms in RFC 6962, it will be considered misissued.
>> * In examining historical issuance, the CA must consider both final
>> certificates and precertificates, even if the precertificate did not
>> ultimately result in the issuance of a certificate.
>>
>
> I propose adding this language to our "Required Practices" wiki page [2],
> then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
> serial numbers. That still leaves some uncertainty about the use of the
> "unknown" response for precertificates (and in general), although Ryan made
> some good points about why using this status beyond the very narrow scope
> described in RFC 6960 section 2.2 is a bad idea.
>
> Once again, I will greatly appreciate your feedback on this topic. Since
> this is a practice and not official policy, I'll go ahead and update the
> wiki when I sense that we're in agreement here.
>
> - Wayne
>
> [1] https://cabforum.org/pipermail/public/2014-January/002694.html
> [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
>
> On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>>
>> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org > dev-security-policy@lists.mozilla.org>> wrote:
>> >
>> >>
>> >>
>> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >>>
>> >>> Hi Kurt.  I agree, hence why I proposed:
>> >>>
>> >>>  "- I would also like to see BR 4.9.10 revised to say something
>> roughly
>> >>> along these lines:
>> >>>   'If the OCSP responder receives a status request for a serial number
>> >>>that has not been allocated by the CA, then the responder SHOULD
>> NOT
>> >>>respond with a "good" status.’"
>> >>
>> >> I suppose one issue there is for CAs which allocate the serial number
>> very
>> >> early on in the issuance workflow - signing a dummy certificate with an
>> >> untrusted key, for instance, but not committing the CA to actually
>> >> producing either a pre-certificate or certificate (e.g, because the
>> >> applicant has insufficient funds to complete the process). It would not
>> >> seem correct to start answering 

Re: DigiCert OCSP services returns 1 byte

2019-09-18 Thread Wayne Thayer via dev-security-policy
Thanks Curt. Reading between the lines of Ryan's and your response, I'm
thinking that we should specifically ban or limit the scope of "unknown"
responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves
some room for a CA to argue that they are permitted to use that response in
situations such as the one you described.

On Wed, Sep 18, 2019 at 3:48 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> My interpretation is once a precertificate has been signed with the
> issuing CA key the corresponding OCSP service should only respond with
> "good" or "revoked". In this case an "unknown" response indicates the
> specific serial number for the issuing CA has not been assigned which isn’t
> the case. Since the serial number has been assigned the OCSP responder
> should know about the status of that serial number for the issuing CA. If
> there are no issues with the precertificate that would require its
> revocation the OCSP responder should respond with “good”. If the
> precertificate is classified as a misissuance (or any other reason that
> would require revocation) the OCSP responder should respond with “revoked”.
>
> - Curt
> ___
> 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


CCADB Policy Update: Exceptions to Policies, Practices, and Audit Information

2019-09-18 Thread Wayne Thayer via dev-security-policy
When Rob Stradling announced the excellent addition of the "inconsistent
Audit details" and Inconsistent CP/CPS Details" sections to the crt.sh
Mozilla CA Certificate Disclosures report [1], we discovered some
inconsistencies between Mozilla's expectations and CCADB policy [2]. To
correct this, the following list of exceptions to providing audit
information *for intermediate certs* has been added to the policy:

   - The SHA-256 fingerprint of the certificate is specifically listed as
   in scope in the audit statements of the parent certificate, and the “Audits
   Same as Parent” checkbox is checked; or
   - The certificate has expired; or
   - The certificate is technically-constrained as described in section
   7.1.5 of the CA/Browser Forum Baseline Requirements, or
   - The certificate has been revoked, and the corresponding record in the
   CCADB has been updated with the correct revocation status.

This change is captured in CCADB policy issues #30 [3] and #31 [4].

- Wayne

[1] https://crt.sh/mozilla-disclosures
[2] https://www.ccadb.org/policy#5-policies-practices-and-audit-information
[3] https://github.com/mozilla/www.ccadb.org/issues/30
[4] https://github.com/mozilla/www.ccadb.org/issues/31
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DigiCert OCSP services returns 1 byte

2019-09-17 Thread Wayne Thayer via dev-security-policy
Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 states “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [1]. Otherwise, Mozilla infers from the existence of a
> precertificate that a corresponding certificate has been issued.
>
> This means, for example, that:
>
> * A CA must provide OCSP services and responses in accordance with Mozilla
> policy for all certificates presumed to exist based on the presence of a
> Precertificate, even if the certificate does not actually exist
> * A CA must be able to revoke a certificate presumed to exist, if
> revocation of the certificate is required under Mozilla policy, even if the
> certificate does not actually exist.
> * If any corresponding certificate with the same serial number and issuer
> exists, and can not be verified to match the precertificate using the
> algorithms in RFC 6962, it will be considered misissued.
> * In examining historical issuance, the CA must consider both final
> certificates and precertificates, even if the precertificate did not
> ultimately result in the issuance of a certificate.
>

I propose adding this language to our "Required Practices" wiki page [2],
then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
serial numbers. That still leaves some uncertainty about the use of the
"unknown" response for precertificates (and in general), although Ryan made
some good points about why using this status beyond the very narrow scope
described in RFC 6960 section 2.2 is a bad idea.

Once again, I will greatly appreciate your feedback on this topic. Since
this is a practice and not official policy, I'll go ahead and update the
wiki when I sense that we're in agreement here.

- Wayne

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

On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>> wrote:
> >
> >>
> >>
> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>>
> >>> Hi Kurt.  I agree, hence why I proposed:
> >>>
> >>>  "- I would also like to see BR 4.9.10 revised to say something roughly
> >>> along these lines:
> >>>   'If the OCSP responder receives a status request for a serial number
> >>>that has not been allocated by the CA, then the responder SHOULD NOT
> >>>respond with a "good" status.’"
> >>
> >> I suppose one issue there is for CAs which allocate the serial number
> very
> >> early on in the issuance workflow - signing a dummy certificate with an
> >> untrusted key, for instance, but not committing the CA to actually
> >> producing either a pre-certificate or certificate (e.g, because the
> >> applicant has insufficient funds to complete the process). It would not
> >> seem correct to start answering (affirmatively) OCSP requests where no
> >> artefact has been signed by a trusted key.
> >>
> >
> > Why does a CA need to sign something to allocate a serial? Could you
> expand
> > a bit more on that?
> >
>
> Yes - on further consideration, I could have been a lot clearer. I didn’t
> mean that a CA _has_ to sign something to allocate a serial in some
> internal database; merely that the allocation of a serial number, in
> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
> start responding to the (Issuer, Serial Number) request with successful
> response codes.
>
> What I meant was that some workflows allocate a serial number, sign a
> dummy certificate containing that serial number (with an untrusted key),
> which then 

Re: CRL for decommissioned CA

2019-09-17 Thread Wayne Thayer via dev-security-policy
On Tue, Sep 17, 2019 at 8:23 AM nenyotoso--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and
> is no longer in operation [2],
> I become aware of CRL endpoint of both the CA and at least one of sub-CA
> is unavailable.
>
> a sub-CA: https://crt.sh/?id=9341006
> leaf certificate issued from the sub-CA: https://crt.sh/?id=524524172
> (you can browse all issued certificates from the sub-CA with
> https://crt.sh/?Identity=%25=1419)
>
> Both of them was revoked but CRL endpoint is unavailable now with HTTP 404
> error response.
> OCSP also fails.
>
> Is it OK to abandon CRL for the decommissioned CA even if there are still
> unexpired certificates?
> The certificates was revoked but we have no way to validate it in a
> PKI-ish manner...
>
>
If there are user agents that continue to trust this root, then this is
certainly a bad thing.

Sorry if it is off-topic because the CA has never been approved as Root CA
> by Mozilla.
>

It appears that Microsoft may still trust this root. I'll inform them.

Thanks,

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


Re: DigiCert OCSP services returns 1 byte

2019-09-16 Thread Wayne Thayer via dev-security-policy
On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:

> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> 
>
> If a certificate (with embedded SCTs and no CT poison extension) is
> "presumed to exist" but the CA has not actually issued it, then to my
> mind that's a "certificate that has not been issued"; and therefore, the
> OCSP 'responder SHOULD NOT respond with a "good" status'.
>
> However, this is Schrödinger's "certificate that has not been issued",
> because a Precertificate has been issued that has the same serial number
> (as the "certificate presumed to exist" that doesn't actually exist).
>
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in question:
>(1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>(2) SHOULD NOT respond "good" (see BR 4.9.10).
>
>
If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
on to state "Effective 1 August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
"good" status for such certificates." (referring to 'certificates that have
not been issued' from the prior paragraph)

If the desired outcome is for CAs to respond "good" to a precertificate
without a corresponding certificate, we could override the BRs in Mozilla
policy, but I'd want to get the BRs updated quickly as Rob suggested to
avoid audit findings.

The other piece of this policy that's still unclear to me relates to the
"unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
provide an "unknown" OCSP response for an issued certificate? If not,
should it be? The implication here would be that CAs responding "unknown"
to precertificates without corresponding certificates are doing the right
thing, despite prior precedent indicating that this is a violation. [1]

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390


> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5:
>'For purposes of clarification, a Precertificate, as described in RFC
> 6962 – Certificate Transparency, shall not be considered to be a
> “certificate” subject to the requirements of RFC 5280'
>
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
> respond "good"'.
>
> I can't say I like this conclusion, but nonetheless it is the conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
>
> IDEAS FOR FIXING IT:
>
> Long-term:
>- In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
>
> Short-term:
>- I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.'
>
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Trusted Recursive Resolver Policy in India

2019-09-13 Thread Wayne Thayer via dev-security-policy
Rich: I want to acknowledge your question, which I think is really "what is
the right forum for Mozilla TRR (DNS over HTTPS) policy [1] discussions?" I
don't currently have an answer for you, but will respond when I do.

- Wayne

[1] https://wiki.mozilla.org/Security/DOH-resolver-policy

On Wed, Sep 11, 2019 at 11:39 AM rich.salz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is this list the right place to discuss the TRR policy?
> If so, could the wiki page on the policy be updated to point to it?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DigiCert OCSP services returns 1 byte

2019-09-13 Thread Wayne Thayer via dev-security-policy
Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:

* Accepted Jeremy's proposed language for the examples in the last
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a certificate exists by changing that sentence to
"Otherwise, Mozilla infers from the existence of a precertificate that a
corresponding certificate has been issued, even when we have no evidence of
the certificate."

The new statement of "required practice" reads:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given Precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every Precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a Precertificate containing the same serial number as the subsequent
> certificate. Otherwise, Mozilla infers from the existence of a
> Precertificate that a corresponding certificate has been issued, even when
> we have no evidence of the certificate.
>
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with Mozilla policy for all Precertificates as if
> the corresponding certificate exists, and (ii) a CA must be able to revoke
> a Precertificate if revocation of the certificate is required under Mozilla
> policy and the corresponding certificate doesn’t actually exist and
> therefore cannot be revoked.
>

I will again welcome everyone's constructive feedback on this proposal, and
when there are no further comments I'll add this to our wiki.

- Wayne

On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek 
wrote:

> Yes, but I think this clarifies things in the wrong direction.
>
> -Tim
>
> > -Original Message-
> > From: Rob Stradling 
> > Sent: Friday, September 13, 2019 4:22 AM
> > To: Tim Hollebeek ; Jeremy Rowley
> > ; Alex Cohn 
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > 
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > > So, this is something that would be helpfully clarified via either an
> > > IETF draft,
> >
> > There's already a 6962-bis draft [1] in IESG Last Call, which (when we
> finally
> > complete it!) will obsolete RFC6962.  6962-bis redefines precertificates
> so that
> > they're not actually X.509 certificates.
> > Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >
> > Thinking aloud...
> > Does anything need to be clarified in 6962-bis though?
> > A (non-X.509) 6962-bis precertificate contains the serial number that
> will
> > appear in the certificate (if or when that certificate is issued),
> > so: Should the CA be forbidden, permitted or required to operate
> revocation
> > services for that serial number once the 6962-bis precertificate has been
> > produced but before the certificate has been issued?  (And is this a
> technical
> > matter for 6962-bis to address, or a policy matter that's out of scope
> for the
> > 6962-bis document?)
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >
> > > or clarifications in the BRs.  There are various things in the OCSP
> RFCs and
> > even the BRs that can be read as precluding good OCSP responses for pre-
> > certificates, although the situation is unclear since the relevant
> sections are
> > blissfully ignorant of CT, and the correct behavior here was
> unfortunately left
> > out of RFC 6962, which should have clarified this.
> > >
> > > Happy to help draft something.  There are some interesting complexities
> > once you dig deeper.
> > >
> > > -Tim
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Jeremy
> > >> Rowley via dev-security-policy
> > >> Sent: Thursday, September 12, 2019 1:46 PM
> > >> To: Alex Cohn 
> > >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > >> 
> > >> Subject: RE: DigiCert OCSP services returns 1 byte
> > >>
> > >> The language says you have to provide the response for the cert as if
> > >> it exists, but the reality is that sending a response for the precert
> > >> is the same as calculating the 

Re: Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

2019-09-13 Thread Wayne Thayer via dev-security-policy
Thank you for the report and follow-up Andy. I created
https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue.

- Wayne

On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A quick follow-up to close this out.
>
> The push to fully address the issue was completed globally shortly before
> 16:00 UTC on 2019-09-02.
>
> After additional review, we're confident the only certificates affected
> were these two:
> https://crt.sh/?id=760396354
> https://crt.sh/?id=759833603
>
> Google Trust Services considers this matter fully addressed. We will of
> course continue our ongoing internal review program, but no other work or
> information is outstanding at this point.
>
> --
> Andy Warner
> Google Trust Services
>
> On Friday, August 30, 2019 at 2:39:51 PM UTC-4, Andy Warner wrote:
> > This is an initial report and we expect to provide some additional
> details and the completion timeline after a bit more verification and full
> deployment of in-flight mitigations. We are posting the most complete
> information we have currently to comply with Mozilla reporting timelines
> and will follow-up with additional details soon.
> >
> > 1. How your CA first became aware of the problem and the time and date.
> >
> > While performing an internal review and assessment of the CRL generation
> system for Google Trust Services' GTS CA 1O1 on August 16, 2019, it was
> discovered that the CRL generation service did not include CRL entries of
> expired certificates. The periodic job only considered certificates with
> valid lifetimes. This does not conform to RFC 5280 Section 3.3 which states
> that “An entry MUST NOT be removed from the CRL until it appears on one
> regularly scheduled CRL issued beyond the revoked certificate's validity
> period.”  We expect that few, if any, clients have been impacted.  For a
> client to be impacted they would have to: clock skewed to a time before the
> not-after field of the certificate; and have a CRL published after
> expiration dropping the revoked certificate.
> >
> >
> > 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.
> >
> > August 16, 2019 15:00 UTC - Reviewer realizes that CRL will not publish
> for one update past expiration
> > August 16, 2019 16:00 UTC - Reviewer checks for other issues & talks to
> peers to confirm problem
> > August 16, 2019 17:00 UTC - Bug is filed to fix the issue with a
> proposed design fix
> > August 16, 2019 23:30 UTC - Fix is sent for review
> > August 20, 2019 16:00 UTC - Remediation work is discussed & assigned
> > August  20, 2019 18:00 UTC - Query to inspect revoked certificates is
> created and sent to be run by production team for initial analysis.
> > August 21, 2019 10:40 UTC - Production team runs query and returns result
> > August 21, 2019 15:00 UTC - Reviewer analyzes data
> > August 21, 2019 20:30 UTC - Reviewer asks for a follow up query to
> ascertain if any certificates did not make it onto the CRL
> > August 22, 2019 07:00 UTC - Initial attempt at updating test systems
> with fix.
> > August 22, 2019 09:00 UTC - Updating of test systems aborted due to
> (unrelated) issues.
> > August 22, 2019 07:00 UTC - Production team runs query for CRLs that may
> have missed a certificate
> > August 22, 2019 15:00 UTC - Reviewer ascertains that certificates under
> question were on a CRL
> > August 26, 2019 11:00 UTC - Second attempt at updating test systems with
> fix.
> > August 26, 2019 13:00 UTC - Test systems updated, confirmed integrity of
> fixed software.
> > August 27, 2019 09:00 UTC - Confirmed fix is effective on test systems.
> > August 27, 2019 10:00 UTC - present: Ongoing staged deployment to
> production systems. Should complete fully by September 3, 2019 17:00 UTC
> (slightly extended window due to push policies around holiday weekends. The
> rollout was staged in accordance with Google's standard rollout procedures.)
> >
> >
> > 3. Whether your CA has stopped, or has not yet stopped, issuing
> certificates with the problem.
> >
> > The affected CA software has been patched.  It now populates expired
> certificates in the CRL for 7 days after their expiration to ensure they
> appear in at least one regularly issued CRL update.  Automated testing was
> added as part of the same patch to check that revoked certificates are kept
> in the CRL.  The patch was developed, tested, reviewed and landed within
> the codebase by August 19, 2019.  The CRL entry removal bug has been fully
> remediated.
> >
> >
> > 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.
> >
> > Investigation began on 

Re: Request to Include 4 Microsoft Root CAs

2019-09-11 Thread Wayne Thayer via dev-security-policy
Having received no further comments, I have recommended approval of this
request in bug 1448093.

- Wayne

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

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

Re: DigiCert OCSP services returns 1 byte

2019-09-11 Thread Wayne Thayer via dev-security-policy
Correct. That's what I intended to convey with the last sentence:

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

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

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

> Hey Wayne - I take it that this "Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued" means a CA issuing
> a precert without the final cert must respond "good" unless the pre-cert is
> revoked? Responding unknown means the CA wouldn't know that they issued the
> cert, which means they disagree with the proof that a corresponding cert
> has been issued.
>
> Jeremy
>
> -Original Message-----
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, September 11, 2019 7:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Mozilla has, to-date, not published policies related to Certificate
> Transparency, but this is a case where a clarification would be helpful. I
> propose adding the following language to our "Required Practices" wiki page
> [1]:
>
> The current implementation of Certificate Transparency does not provide any
> > way for Relying Parties to determine if a certificate corresponding to
> > a given precertificate has or has not been issued. It is only safe to
> > assume that a certificate corresponding to every precertificate exists.
> >
> > RFC 6962 states “The signature on the TBSCertificate indicates the
> > certificate authority's intent to issue a certificate.  This intent is
> > considered binding (i.e., misissuance of the Precertificate is
> > considered equal to misissuance of the final certificate).”
> >
> >
> >
> > However, BR 7.1.2.5 state “For purposes of clarification, a
> > Precertificate, as described in RFC 6962 – Certificate Transparency,
> > shall not be considered to be a “certificate” subject to the
> > requirements of RFC
> > 5280 - Internet X.509 Public Key Infrastructure Certificate and
> > Certificate Revocation List (CRL) Profile under these Baseline
> Requirements.”
> >
> > Mozilla interprets the BR language as a specific exception allowing
> > CAs to issue a precertificate containing the same serial number as the
> > subsequent certificate [2]. Mozilla recognizes a precertificate as
> > proof that a corresponding certificate has been issued.
> >
> > This means, for example, that the requirements for OCSP for end-entity
> > certificates apply even when a CA has issued a precertificate without
> > issuing a corresponding certificate.
> >
>
> I plan to add this to the wiki next week. I also plan to include this in
> in a future update to our Root Store Policy.
>
> I will greatly appreciate your constructive feedback on this proposal.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> [2] https://cabforum.org/pipermail/public/2014-January/002694.html
>
> On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Let me try that again since I didn't explain my original post very well.
> > Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
> >
> > What happened at DigiCert is that the OCSP service failed to return a
> > signed response for a certificate where a pre-certificate existed by a
> > certificate had not issued for whatever reason. The question asked was
> > what type of OCSP services are required for a pre-cert if there is no
> > other certificate. The answer we came up with is it should respond
> > "GOOD" based on the Mozilla policy, not Unknown or any other response.
> > Note that this was a bug in the DigiCert system but it lead to a fun
> internal discussion.
> > What I'm sharing is the outcome of the internal discussion - it's only
> > tangentially related to the bug, not the cause or remediation of it.
> >
> > Summary: Pre-certs require a standard OCSP response as if the pre-cert
> > was a normal cert. In fact, it's a mistake to ever think of pre-certs
> > as anything other than TLS certs, even if the poison extension exists.
> >
> > The question comes up because the BRs don't cover pre-certs. However,
> > as Ryan points out, the browsers sort-of cover this as does the
> > Mozilla policy. The browser say this is a promise to issue the cert
> > and mis-issuance of a pre-cer

Re: DigiCert OCSP services returns 1 byte

2019-09-11 Thread Wayne Thayer via dev-security-policy
Mozilla has, to-date, not published policies related to Certificate
Transparency, but this is a case where a clarification would be helpful. I
propose adding the following language to our "Required Practices" wiki page
[1]:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
>
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [2]. Mozilla recognizes a precertificate as proof that a
> corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

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

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

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

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

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

Re: Auditor letters and incident reports

2019-09-06 Thread Wayne Thayer via dev-security-policy
Thanks for the response Jeff.

On Fri, Sep 6, 2019 at 4:17 PM jeffwardpki--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 21, 2019 at 11:46:37 PM UTC-5, Jeremy Rowley wrote:
> > Hey all,
> >
> > An interesting issue came up recently with audits. Because the Mozilla
> policy includes some requirements that diverge from the BRs, the audit
> criteria don't necessarily cover everything Mozilla cares about. Thus, it's
> possible to have an incident that doesn't show up on an audit. It's also
> possible that the auditor determines the incident is not sufficiently
> important/risky(?) to include it in an audit. For example:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1458024. Auditors aren't
> controlled by the CA and operate independently which means the CA can't
> dictate what goes into the opinion. One solution is to require CAs to list
> all of the incidents that occur during their audit in the management
> assertion letter. I posted an addendum to the management assertion on that
> thread. Going forward, we'll just include it as part of the main body. I
> need to look into whether I can get our existing audit reissued to the
> appendix is part of the seal as well.
> >
> > What do you think about just requiring that as part of the Mozilla
> policy? Ie - the management assertion letter must include a list of the
> incidents active/opened during the audit period. Something like that could
> ensure transparency and make sure all incidents are disclosed to the
> auditor, distinguishing the CA's disclosures from the auditors.
> >
> > Jeremy
>
> Reposting as I don't see my original response to this thread:
>
> Sorry for the delay in responding, but I first wanted to gather feedback
> from the members of the WebTrust Task Force.  Keep in mind any
> audit/assurance engagement entails professional judgment, which of course
> may vary from firm to firm.   We are certainly seeing a trend in audit
> reports whereby “Other Matters” are described that do not modify/qualify
> the auditor’s opinion but do allow the auditor to make mention of the
> issues.  Some firms use this section to list items noted in Bugzilla, for
> instance, to demonstrate that these types of issues were addressed in the
> course of the audit.
>
> Depending on the firm, some firms have been listing all issues noted in
> Bugzilla, while others are listing only those that are significant.  As a
> Task Force, it is not our position, or even a possibility, for us to
> mandate how these should be handled as professional judgment will dictate
> their treatment based on the respective firms’ risk management policies.
> That being said, we have as part of our draft practitioner guidance
> commentary that the browser community prefers seeing all these types of
> issues listed as either modifications/qualifications, or described in
> “Other Matters” and encourage practitioners to use this approach.
>
>
I would go beyond "all issues noted in Bugzilla" to "all issues, including
those noted in Bugzilla".

In most cases, management’s Assertion accompanies the audit report, and
> there is greater flexibility for what goes into them.  Our professional
> standards require certain items be present in the Assertion, but other
> items that management wants to add are permissible to include.  Except in
> the rare reporting scenario when an assertion by management is not
> provided, most of the Task Force members agree there would not be any issue
> with your proposed requirement to require a CA's management to detail
> Bugzilla or similar issues relevant to the current audit period in their
> assertion to the auditors.
>
>
By doing this, a CA can eliminate any question about disclosure of
incidents to auditors, which is terrific and encouraged. As a Mozilla
requirement it has the problem - as Ryan pointed out - that ETSI audits
don't include management assertions, at least not today.


> As far as the management representation letter, which is a required
> written communication to the auditors at the conclusion to the audit,
> regulatory non-compliance would normally form part of the management
> representation that is needed for each audit, and the assertion can form
> part of that representation.   Keep in mind that the management
> representation letter is not part of the deliverable that is viewed
> publicly as is the case with the auditor’s opinion and management assertion.
>
> To demonstrate that the auditor has addressed the significance of the
> relevant issues, we can propose that the standard WebTrust reports have an
> Exhibit that sets out the issues identified by reference to Bugzilla, as an
> example.  The audit report can then reflect the relevant significance
> either as a report qualification or through an "Other Matters" paragraph
> that provides further commentary.  The main issue is that, even by
> identifying and addressing them in the audit report, there is still the
> potential for disagreements 

Re: Request to Include 4 Microsoft Root CAs

2019-09-05 Thread Wayne Thayer via dev-security-policy
Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.

Unless a CA has an existing EV policy OID associated with root(s) in our
program, we have been strongly encouraging the use of the CAB Forum OID.

This request is past the 3-week minimum discussion period. If no
significant comments are posted, I will close it on Tuesday 10-September.

- Wayne

On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-26 Thread Wayne Thayer via dev-security-policy
On Mon, Aug 26, 2019 at 5:39 AM Josef Schneider via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:
> > On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:
> > > Deploying a Stripe Inc EV SSL from a state other than CA is one thing,
> but using an EV SSL in conjunction with a domain name and website with the
> true intent to dupe potential customers is another matter. I'm trying to
> get past the theoretical and get to real world instances.
> >
> > I don't understand the idea that the Stripe proof-of-concept is
> > "theoretical". We know that phishing is epidemic, and we also know that
> > phishers presently need -- at most -- a DV cert. The POC shows that --
> > should something cause phishers to need an EV cert -- they can also get
> > one of those quickly and inexpensively. But why would a phisher bother
> > with an EV cert if a DV cert works just as well?
>
>
> The important question is can they get this without making them easily
> traceable?
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?
>
> How long do you think would it have taken for the police to come and get
> Ian Carroll if he'd actually committed fraud?
>
> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them. But they do raise the bar for criminals. And in my
> opinion, significantly.
>
> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to the
> problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.
>
>
The counter-argument is that not all problems can be solved with UX, and
getting browser users to recognize and respond to the lack of an EV
indicator is in that class of unsolvable problems.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Nation State MITM CA's ?

2019-08-21 Thread Wayne Thayer via dev-security-policy
(resending because the first attempt was not posted to the list)

Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> News reports[1][2] are now showing that the certificate has been
> "cancelled". I do not have a way to verify that it has been revoked
> independently at this time.
>
> Sources:
> [1] https://tsarka.org/post/national-certificate-cancelled
> [2]
> https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD
> ___
> 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: Nation State MITM CA's ?

2019-08-21 Thread Wayne Thayer via dev-security-policy
Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.

- Wayne

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> News reports[1][2] are now showing that the certificate has been
> "cancelled". I do not have a way to verify that it has been revoked
> independently at this time.
>
> Sources:
> [1] https://tsarka.org/post/national-certificate-cancelled
> [2]
> https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD
> ___
> 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


Request to Include 4 Microsoft Root CAs

2019-08-13 Thread Wayne Thayer via dev-security-policy
This request is for inclusion of the Microsoft RSA Root Certificate
Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
Authority 2017 trust anchors as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448093

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

* Summary of Information Gathered and Verified:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275

* Root Certificate Download URL:
https://www.microsoft.com/pkiops/docs/repository.htm

* CP/CPS:
** CP:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
** CPS:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf

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

* Test Websites
** Valid: https://actrsaevroot2017.pki.microsoft.com/,
https://actrsaroot2017.pki.microsoft.com/,
https://acteccevroot2017.pki.microsoft.com/,
https://acteccroot2017.pki.microsoft.com/
** Expired: https://exprsaevroot2017.pki.microsoft.com/,
https://exprsaroot2017.pki.microsoft.com/,
https://expeccevroot2017.pki.microsoft.com/,
https://expeccroot2017.pki.microsoft.com/
** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
https://rvkrsaroot2017.pki.microsoft.com/,
https://rvkeccevroot2017.pki.microsoft.com/,
https://rvkeccroot2017.pki.microsoft.com/

* CRL URLs:
** ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
** RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
** EV ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
** EV RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl

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

* Audit: Annual audits are performed by BDO according to the WebTrust for
CA, BR, and EV audit criteria.
** WebTrust for CA: https://bugzilla.mozilla.org/attachment.cgi?id=9083810
** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813

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

==Good==
* A root key generation ceremony audit report has been provided [1].

==Meh==
* CPS section 3.2.4 stated that OU is not verified, however, BR section
7.1.4.2.2(i) does place requirements on this field, and the CPS made it
unclear if these requirements are met. This was clarified in the latest
version of the CPS.
* CPS section 3.2.5 stated that Microsoft PKI Services shall verify
authority for all certificate requests, and that for Domain Validated
requests, this is done using one of the methods described in the BRs.
Section 3.2.5 of the BRs only describes validation of authority for OV
certificates using a reliable method of communication. This was clarified
in the latest version of the CPS.
* CPS section 6.1.5 indicated that P-512 keys may be used, which would
violate Mozilla policy. This was corrected in the latest version of the CPS.
* The content-type header in CRL responses is not set to
'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
4.2.1.13). Microsoft explanation: the reason for the content-type being set
to octet-stream is that we use a content upload service at Microsoft that
hosts different types of content. All of the content in the service is
hosted in Azure’s BLOB storage and the content type by default is octet
stream. This has not been an issue because the browsers will resolve the
file type based on the extension in the file name. It should also be noted
that the RFC 5280 shows SHOULD rather than MUST.

==Bad==
* It had been more than a year since the CP was updated when I reviewed
this request. CPS and BR section 2 require annual updates. The CP was
updated on 5-August.
* CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
clear problem reporting instructions. This was corrected in the latest
versions of the CP and CPS.
* A number of unrevoked certificates chaining to the Microsoft RSA Root
Certificate Authority 2017 have recently been issued with BR violations [2]

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

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

- Wayne

[1] https://bug1448093.bmoattachments.org/attachment.cgi?id=8986854
[2]
https://crt.sh/?caid=109424=cablint,zlint,x509lint=2019-05-01
[3] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-12 Thread Wayne Thayer via dev-security-policy
Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
which is expected to be released on 22-October. Details below.

If the before and after images are stripped from the email, you can view
them here:

Before:
https://lh4.googleusercontent.com/pSX4OAbkPCu2mhBfeleKKe842DgW28-xAIlRjhtBlwFdTzNhtNE7R43nqBS1xifTuB0L8LO979yhpPpLUIOtDdfJd3UwBmdxFBl7eyX_JihYi7FqP-2LQ5xw4FFvQk2bEObdKQ9F

After:
https://lh5.googleusercontent.com/kL-WUskmTnKh4vepfU3cSID_ooTXNo9BvBOmIGR1RPvAN7PGkuPFLsSMdN0VOqsVb3sAjTsszn_3LjRf4Q8eoHtkrNWWmmxOo3jBRoEJV--XJndcXiCeTTAmE4MuEfGy8RdY_h5u

- Wayne

-- Forwarded message -
From: Johann Hofmann 
Date: Mon, Aug 12, 2019 at 1:05 AM
Subject: Intent to Ship: Move Extended Validation Information out of the
URL bar
To: Firefox Dev 
Cc: dev-platform , Wayne Thayer <
wtha...@mozilla.com>


In desktop Firefox 70, we intend to remove Extended Validation (EV)
indicators from the identity block (the left hand side of the URL bar which
is used to display security / privacy information). We will add additional
EV information to the identity panel instead, effectively reducing the
exposure of EV information to users while keeping it easily accessible.

Before:


After:


The effectiveness of EV has been called into question numerous times over
the last few years, there are serious doubts whether users notice the
absence of positive security indicators and proof of concepts have been pitting
EV against domains  for
phishing.

More recently, it has been shown  that EV
certificates with colliding entity names can be generated by choosing a
different jurisdiction. 18 months have passed since then and no changes
that address this problem have been identified.

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.



On our side a pref for this
(security.identityblock.show_extended_validation) was added in bug 1572389
 (thanks :evilpie for
working on it!). We're planning to flip this pref to false in bug 1572936
.

Please let us know if you have any questions or concerns,

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


Entrust Root Certification Authority - G4 Inclusion Request

2019-07-26 Thread Wayne Thayer via dev-security-policy
This request is to include the Entrust Root Certification Authority - G4 as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1480510

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

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

* Root Certificate Download URL:
https://bug1480510.bmoattachments.org/attachment.cgi?id=8997105

* CP/CPS:
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf

* This request is for Websites and Email trust bits. EV treatment is
requested.
** EV Policy OID: .16.840.1.114028.10.1.2

* Test Websites:
** Valid: https://validg4.entrust.net/
** Expired: https://expiredg4.entrust.net/
** Revoked: https://revokedg4.entrust.net/

* CRL URL: http://crl.entrust.net/g4ca.crl

* OCSP URL: http://ocsp.entrust.net/

* Audit: Annual audits are performed by Deloitte according to the WebTrust
for CA, BR, and EV audit criteria.
** WebTrust for CAs and EV:
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230012
** BR:
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Entrust Root Certification Authority - G4 inclusion request that is being
tracked in this bug and have the following comments:

==Good==
* I’m pleased to see the “Other Matters” section of this and last year’s
audit reports.
* This root was signed in 2015, but there is no evidence that it has been
used other than to sign test certificates, and I can find no evidence of
misissued certificates chaining to this root.

==Meh==
* Entrust has had some compliance issues recorded during the life of this
root certificate that are now resolved:
** Metadata in ST and OU fields [1] [2]
** OCSP responding “good” for unknown certificates. [3]
** IP address in dNSName form [4] and [5]
** Late revocation of misissued certificates [6]
** Question marks in certificate O and L fields [7]
** Issued certificates to incorrect organization [8]
** AffirmTrust Issuing CA Impacted by EJBCA Serial Number Issue [9]
** Late revocation of underscore certificates [10]
* External RAs are permitted, but the CPS I originally reviewed (version
3.2) did not make it clear that domain validation will not be delegated as
required by BR section 1.3.2. Entrust addressed this in the current version.
* BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly
specify the set of Issuer Domain Names that the CA recognises in CAA
"issue" or "issuewild" records as permitting it to issue.” The Entrust CPS
instead references section 3.2.2.8 where the Issuer Domain Name is listed.
* CPS section 9.12.3 is blank. Mozilla recommends against this [11].

==Bad==
* Entrust self-reported a bug in which they had improperly encoded an IP
address in a certificate. [4] In March 2018, they indicated in the bug that
they would implement pre-issuance linting, but not until early 2019. It was
ultimately implemented in May 2019. While pre-issuance linting is not a
requirement, it is certainly a best practice and taking over a year to
implement it is discouraging. It appears [12] that at least one other
misissuance would have been prevented if pre-issuance linting had been
implemented sooner.
* Entrust’s current and prior [13] BR audit reports contain a qualification
for failing to address critical vulnerabilities within 96 hours. Entrust
engaged Deloitte to confirm the the problem had been remediated in
September 2018. [14] The current period-of-time report confirms that the
issue was remediated as of 30-June 2018.
* The most recent BR audit report lists two additional qualifications
related to the Network Security requirements:
** During the Period, there were instances of some Certificate Systems not
undergoing a Vulnerability Scan at least every three (3) months.
** During the Period, there were instances where a technical control to
restrict remote access to only those devices owned or controlled by Entrust
did not operate effectively.
* Entrust has the following open CA compliance bugs (as of 25-June):
** Outdated audit statement for intermediate cert [15]
** Certificate issued with incorrect Country Code [16]
** Certificate issued with validity greater than 825 days [17]
** SHA-1 Issuance and other misissuance while testing [18]
* CPS version 3.2 section 9.8.2.2 appeared to limit liability to $1000 USD
per Subscriber, but EVGL section 18 sets a minimum of $2000 USD. Entrust
addressed this in the current version.

This begins the 3-week (minimum) comment period for this request [19].

I will greatly appreciate your thoughtful and constructive feedback on the
decision to include this root certificate.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512018
[2] 

Re: Disclosure and CP/CPS for Cross-Signed Roots

2019-07-24 Thread Wayne Thayer via dev-security-policy
Thank you Rob! These are excellent additions to this report.

I'd like to ask all the CA representatives on this list to take a look at
the updated report (https://crt.sh/mozilla-disclosures) and correct any
issues with your company's disclosures as soon as possible.

Regarding Peter's earlier comment:

> I think that the process should be updated to list CAs (subject, subject
public key, subject key identifier), is addition to listing the CA
certificates.

It makes sense. I'll discuss this suggestion with Kathleen.

For now, what I'm hearing is that the GoDaddy and Asseco cases are clearly
incorrect disclosures due to the certificates not showing up on the
"parent" audit statement.

I think we want to continue to hold the issuing CA accountable for
disclosing any cross-certificates it signs, but they need to indicate that
the audit and applicable CP/CPS is that of the subject CA when that is the
case. I will also consider adding guidance on this issue to
https://www.ccadb.org/cas/intermediates

- Wayne

On Wed, Jul 24, 2019 at 9:41 AM Rob Stradling  wrote:

> [Wearing Sectigo hat]
>
> Andrew, thanks for filing [1].  Sectigo will provide a full response on
> that bug, but I'll just note here that we have updated the CCADB records
> for the cross-certificates such that the Audit and CP/CPS details are
> now consistent with the Web.com roots.  As it happens, I was already
> aware of this inconsistency, but I'd delayed fixing it so that I could
> use it as a test case for...
>
> [Wearing crt.sh hat]
>
> https://crt.sh/mozilla-disclosures now has two new buckets:
> - Disclosed, but with Inconsistent Audit details
> - Disclosed, but with Inconsistent CP/CPS details
>
> (I started discussing this new feature with Kathleen, Wayne and Sleevi
> off-list a few months ago, but I was not able to finish implementing it
> until a few days ago).
>
> I've also made the checks for the "Disclosure Incomplete" bucket
> stricter.  Missing/incomplete disclosures of BR and/or EV audits are now
> flagged.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060
>
> On 18/07/2019 21:46, Andrew Ayer via dev-security-policy wrote:
> > On Thu, 18 Jul 2019 11:40:31 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> >> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
> >> a bit of discussion.
> >
> > There's a third bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1567062
> >
> > Like the GoDaddy case, the intermediate supposedly having the same
> > CP/CPS/audits as parent is not listed in the parent's audit report, so
> > this too looks like an incorrect disclosure.
> >
> > Regarding Sectigo and Web.com, although their CPSes use extremely
> > similar language, they are not consistent, since they list different
> > CAA domains.
> >
> > Regards,
> > Andrew
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Misissuance Report: Incorrect CA-Issuers URI in some certificates

2019-07-23 Thread Wayne Thayer via dev-security-policy
Neil,

Thank you for posting this detailed incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1568356 to track this issue
and I have no questions at this time.

- Wayne

On Tue, Jul 23, 2019 at 10:20 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To m.d.s.p,
>
> The following contains an incident report, compiled as a result of the
> release of two example certificates with an incorrect CA-Issuers URI
> included.
>
> Any questions or observations on this incident are gratefully received,
> and I will endeavour to answer them as quickly as I can.
>
> Regards,
>
> Neil Dunbar,
> CA Administrator,
> TrustCor Systems, S. de R.L.
>
> —
>
> 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.
>
> 2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
> monitoring process, Internal QA identified two (2) certificates which
> contained an incorrect URI value in the CA Issuers part of the
> authorityInformationAccess extension.
>
> 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.
>
> 2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
> 2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA
> hierarchy suspended, pending investigation of issue.
> 2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected
> certificates completed.
> 2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect
> value stipulated for an Internal Example Certificate profile under the
> ECA-1 root (no other hierarchies shared this issue).
> 2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile
> values for ECA-1 internal example certificates corrected on testing and
> production platforms.
> 2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected
> certificates.
> 2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected
> certificates.
>
> 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.
>
> TrustCor stopped issuing certificates identified with this problem and
> rapidly resolved the issue.
>
> 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.
>
> Two (2) certificates were identified with this issue. The first was
> issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
> at 2019-07-22 11:22:10 UTC.
>
> 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.
>
> Two (2) certificates were identified: one was revoked immediately post
> production (as it is there to demonstrate a revoked certificate), and
> the second certificate, which was otherwise valid, was then revoked
> upon identifying the issue.
>
> The crt.sh URIs for the certificates (now revoked) are:
>
> https://crt.sh/?id=1695491402 
> https://crt.sh/?id=1695520034 
>
> 6. Explanation about how and why the mistakes were made or bugs
>   introduced, and how they avoided detection until now.
>
> The problem was that the authorityInformationAccess CA-Issuers URI, (BR
> Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA
> certificate, not the ECA-1 External CA certificate. While the BRs do not
> actually mandate the inclusion of the CA-Issuers URI, providing an
> incorrect value is certainly a mis-issuance.
>
> When TrustCor CA created the new certificate profiles for the ECA-1 example
> hierarchy, the profile QA tool previously only verified that the CA issuers
> URI point to a valid TrustCor CA certificate.
>
> Certificate profiles being copied from the test CA software are compared
> with the intended profiles for production as part of the QA
> process. Because the CA-Issuers URI is always different in test
> vs. production, and the test URI domain is different from
> production, the error was missed before the certificates were issued.
>
> 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 

Re: DarkMatter Concerns

2019-07-22 Thread Wayne Thayer via dev-security-policy
Benjamin,

On behalf of Mozilla I'd like to acknowledge that your request has been
received and is under review.

- Wayne

On Tue, Jul 16, 2019 at 12:14 PM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Message Body (6 of 6)  APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS
>
> 1) Violation of Anti-Trust Laws:
>
> The Module Owner’s discretionary decision, when taken into context with
> the comments of other Mozilla Peers employed by other Browsers and/or
> competing Certificate Authorities, are intended to result in the types of
> unfair competition that are prohibited under the United States Sherman Act,
> the United States Federal Trade Commission Act, the Canadian Competition
> Act, the European Union Anti-Trust Policies, and the United Arab Emirates
> Competition Laws.
>
> a) Notwithstanding to the assertions for a decision “made on a collective
> assessment of all the information at hand”, the Module Owner, and Mozilla
> staff, have blatantly ignored, or failed to acknowledge and consider, the
> impact of anti-competitive comments made by Mr. Ryan Sleevi, a Google
> employee, with regard to the Applicants’ Root Inclusion request.
>
> > “I highlight this, because given the inherently global nature of the
> Internet, there is no technical
> > need to work with local CAs, and, with a well-run root store, all CAs
> provide an equivalent level
> > of protection and security, which rests in the domain authorization."
> [1]
>
> The above statement is quite startling in that it is being made by a
> representative of a dominant market power as an argument against the
> inclusion of a new economic participant’s entry into the global CA market
> place. In light of the fact that representative has tried to justify a
> technical non-compliance to support revocation of the Applicants’ Root
> Inclusion (note that significantly higher number of users were at risk due
> to the same serial entropy violations of his own employer Google) [2], and
> considering that this representative was a key player in the demonstration
> of dominant Browser market power against a significant CA global business
> [3], the Applicants have a reasonable basis to believe that the distrust
> discussion are more likely to be motivated by economic considerations that
> preserve incumbent parties market domination and monopolization.
>
> b) Additionally, the Module Owner, and Mozilla staff, have blatantly
> ignored, or failed to acknowledge and consider, the Applicants’ response to
> the Google Representative in their decision-making process. The General
> Counsel of DarkMatter asserted unambiguously in the public discussion as
> follows:
>
> We are of the view that CA monopolies are inherently bad for the internet
> in that they unfairly exploit market power. The result is a fundamental
> right to Internet security and privacy being deliberately priced out of
> reach for a significant population of the world.  We ask you, what can be
> more of an anti-competitive monopoly than a "well run store" (read
> Google/Mozilla) that does not take into consideration that sovereign
> nations have the fundamental right to provide digital services to their own
> citizens, utilizing their own national root, without being held hostage by
> a provider situated in another nation.” [4]
>
> The above discussions are highly relevant to the decision-making process,
> considering that the Module Owner is aware of the significant economic
> investment the Applicants have made in progressing the Root inclusion
> requests over the past two years.  In fact, the Applicants have received
> further communications from other relevant Browser Stores indicating that
> their respective decision to permit the Applicants to participate in the
> global CA business ecosystem will be based and influenced by the Mozilla
> Module Owner’s highly subjective discretionary decision. The entire global
> internet traffic is controlled by four (4) Browser Root Stores (Mozilla,
> Microsoft, Google and Apple). As Reuters pointed out in its July 4 story,
> three (3) of those Browser Stores will likely adopt and enforce this
> decision by Mozilla. In light of this, the Module Owner would be, or should
> be, aware of the significant economic harm of a decision based on less than
> verifiable “credible evidence”.
>
> c) Notwithstanding the above highly relevant elements of the public
> discussion, the Module Owner has now made a significant decision (on less
> than verifiable “credible evidence”) which we believe is intended to
> unfairly affect commerce in the global CA ecosystem through the use of the
> coercive influence he wields on the Applicants as a result of his
> discretionary decision making power. While rejecting the right of the
> Applicants to participate directly within the Mozilla Root Store, and by
> extension setting the stage for an outright denial of the Applicants’
> inclusions in any other browser store, the Module Owner has 

Disclosure and CP/CPS for Cross-Signed Roots

2019-07-18 Thread Wayne Thayer via dev-security-policy
Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of a bit
of discussion. They both appear to be in reference to root certificates
included in the Mozilla program that are cross-signed by a different TSP
(CA). In both cases the TSP that signed the cross-certificate has had it
audited, and disclosed it in CCADB as operating under their own CPS.

For example:
TSP 1 has Root A (subject A, issuer A, public key A) included in the
Mozilla root store
TSP 2 has Root B (subject B, issuer B, public key B) also included in the
Mozilla root store
TSP 2 has signed a cross certificate (subject A, issuer B, public key A)
with Root B.
TSP 2 has disclosed the cross-certificate in CCADB, has it included in
their audit, and asserts that it is operated under their CP/CPS.

One issue, that I recall having been been previously discussed, is that TSP
1 has no way of knowing if another TSP has cross-signed one of their CA
certificates, so it makes sense to require disclosure from the TSP that
issued the cross-certificate.

I think Andrew is asserting that the cross-certificate is really operated
by the root TSP that is in control of the key-pair (TSP 1), and should be
audited and disclosed as such. Should that be our policy?

A secondary question is if the disclosures made by GoDaddy and Sectigo and
documented the bugs filed by Andrew violate our current policies?

- Wayne

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


Re: Nation State MITM CA's ?

2019-07-18 Thread Wayne Thayer via dev-security-policy
On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi  wrote:

>
> On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Finally, I'll point out that Firefox implements public key pinning via a
>> preloaded list of sites, so the reported MITM will fail for those:
>>
>> https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status
>
>
> Wayne,
>
> I don't believe this is correct. Locally-installed trust anchors bypass
> pinning, as they're indicators of explicit user action (or coercion) to
> configure. As a consequence, unless the pinning mode is set to 2. Strict
> (which will typically preclude the use of a number of anti-virus products,
> for better or worse), which it is not by default, the MITM will not fail.
> From the Firefox point-of-view, it's completely transparent whether the
> MITM is being done by local security software or a nation-state
>

Yes, I had just realized that - in the default state, pinning in Firefox
will not block this type of MITM.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Nation State MITM CA's ?

2019-07-18 Thread Wayne Thayer via dev-security-policy
For everyone's reference, here is a link to the old thread:
https://groups.google.com/d/msg/mozilla.dev.security.policy/wnuKAhACo3E/ujxPTWTlCQAJ

To be clear, the Kazakhstan government CA's root inclusion request
referenced in that thread was denied:
https://bugzilla.mozilla.org/show_bug.cgi?id=1232689#c11

However, a bug has been filed proposing to blocklist the current, untrusted
CA certificate being used by the Kazakhstan government:
https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

In reading through the old thread, consensus seemed to be that blocklisting
this CA certificate isn't a good idea.

The old thread mentions the idea of adding a visual indicator to Firefox
when a root that is not included in our default root store is being used.
Somewhat coincidentally, this was added in Firefox 68:
https://bugzilla.mozilla.org/show_bug.cgi?id=1549605

Finally, I'll point out that Firefox implements public key pinning via a
preloaded list of sites, so the reported MITM will fail for those:
https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status

- Wayne



On Thu, Jul 18, 2019 at 8:55 AM starosekpd--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sorry for bumping this old thread, but the Government of Kazakhstan has
> already started to use the certificate for MITM. Some information in news
> (on Russian):
>
> https://tengrinews.kz/internet/spetsialnyiy-sertifikat-poprosili-ustanovit-smartfonyi-374216/
>
> https://tengrinews.kz/internet/problemyi-dostupom-internetu-mogut-poyavitsya-astanchan-374068/
>
> https://www.nur.kz/1805169-problemy-s-dostupom-k-internetu-mogut-poavitsa-u-zitelej-nur-sultana.html
>
> Our internet providers via SMS inform us about the need to install this
> certificate that can be downloaded from their websites:
> http://qca.kz
> https://www.kcell.kz/ru/product/3585/658
>
> https://www.beeline.kz/almatinskaya-obl/about/press-center/press/news/details/sertifikat-bezopasnosti/
>
> Just to note, this certificate is not the same with the one that was
> published in this thread. Current one is issued by "Qaznet Trust
> Network"/"Security Certificate".
>
> At the moment, providers started to use the certificate in the capital of
> Kazakhstan - Nur-Sultan (ex. Astana).
>
> Did Mozilla have any way to prevent such attacks?
>
> --
> Thanks,
> Pavel
> ___
> 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: Logotype extensions

2019-07-16 Thread Wayne Thayer via dev-security-policy
It seems to me that this discussion has veered away from the original
question, which was seeking consent to "experiment" with logotypes in
publicly-trusted certificates. I don't think there is much doubt that RFC
3709 has been and can be implemented, and as pointed out, it can be tested
in private hierarchies. I fail to understand the point of this type of
"experiment", especially when it leaves all of the difficult questions -
such as global trademark validation and the potential to mislead users -
unanswered. The risks of permitting such "experimentation" appear to far
outweigh the benefits.

The discussion has morphed into a question of a CA's right to encode
additional information into a publicly-trusted certificate, beyond the
common profile defined in the BRs, for use in a subset of Browsers or other
client software. The argument here seems to be that BR 7.1.2.4(b)
("semantics that, if included, will mislead a Relying Party about the
certificate information") can't be triggered if the user agent doesn't
understand the data, or that there needs to be proof that the data is
misleading (versus could be misleading) to trigger that clause. This seems
like a much more difficult problem to solve, and one that doesn't need to
be addressed in the context of the original question.

Given this, and the fact that I believe it is in everyone's best interest
to resolve the current ambiguity over Mozilla's policy on logotypes, I
again propose to add logotype extensions to our Forbidden Practices[1], as
follows:

** Logotype Extension **
Due to the risk of misleading Relying Parties and the lack of defined
validation standards for information contained in this field, as discussed
here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or
Subscriber certificates.

I will greatly appreciate additional feedback on my analysis and proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ

On Fri, Jul 12, 2019 at 2:26 PM Ryan Sleevi  wrote:

> And they will mislead relying parties. Which is why you cannot use *this*
> particular extension. Sorry, that ship sailed in 2005.
>
> A CA that would be remotely be considering exercising this clause would
> strongly benefit from checking with the Root stores they’re in, no matter
> the extension proposed.
>
> It’s also Subject Identifying Information.
>
> On Fri, Jul 12, 2019 at 5:11 PM Jeremy Rowley 
> wrote:
>
>> The language of the BRs is pretty permissive.  Assuming Mozilla didn't
>> update its policy, then issuance would be permitted if the CA can show that
>> the following was false:
>>
>> b. semantics that, if included, will mislead a Relying Party about the
>> certificate information verified by
>> the CA (such as including extendedKeyUsage value for a smart card, where
>> the CA is not able to verify
>> that the corresponding Private Key is confined to such hardware due to
>> remote issuance)..
>>
>> I think this is section you are citing as prohibiting issuance correct?
>> So as long as the CA can show that this is not true, then issuance is
>> permitted under the current policy.
>>
>>
>>
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ryan Sleevi via dev-security-policy
>> Sent: Friday, July 12, 2019 3:01 PM
>> To: Doug Beattie 
>> Cc: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org>; Wayne Thayer <
>> wtha...@mozilla.com>
>> Subject: Re: Logotype extensions
>>
>> Alternatively:
>>
>> There is zero reason these should be included in publicly trusted certs
>> used for TLS, and ample harm. It is not necessary nor essential to securing
>> TLS, and that should remain the utmost priority.
>>
>> CAs that wish to issue such certificates can do so from alternate
>> hierarchies. There is zero reason to assume the world of PKI is limited to
>> TLS, and tremendous harm has been done to the ecosystem, as clearly and
>> obviously demonstrated by the failures of CAs to correctly implement and
>> validate the information in a certificate, or timely revoke them. The fact
>> that were multiple CAs who issued certificates like “Some-State” is a
>> damning indictment not just on those CAs, but in an industry that does not
>> see such certificates as an existential threat to the CAs relevance.
>>
>> It is trivial to imagine how to issue such certificates from non-TLS
>> hierarchies, and to have those still usable by clients. Any CA that can’t
>> think of at least three ways to do that has no business in this industry -
>> because it is truly basic application of existing technologies.
>>
>> The BRs do not permit this. Just like they don’t permit a lot of things
>> that CAs are unfortunately doing. If the CA portion of the industry wants
>> to improve things, such that a single CA could reasonably be believed to be
>> competent enough to issue such certificates, let alone reasonably validate
>> them 

Re: Logotype extensions

2019-07-11 Thread Wayne Thayer via dev-security-policy
On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker 
wrote:

>
> On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer  wrote:
>
>> On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker <
>> ph...@hallambaker.com> wrote:
>>
>>> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>> Russ,
>>>>
>>>> >
>>>> Perhaps one of us is confused because I think we're saying the same
>>>> thing -
>>>> that  rules around inclusion of Logotype extensions in publicly-trusted
>>>> certs should be in place before CAs begin to use this extension.
>>>>
>>>
>>> I don't see how your proposed ban on logotypes is consistent. What that
>>> would do is set up a situation in which it was impossible for CABForum to
>>> develop rules for logotypes because one of the browsers had already banned
>>> their use.
>>>
>>>
>> How exactly does a Browser banning the use of an extension prevent the
>> CAB Forum from developing rules to govern the use of said extension? If
>> anything, it would seem to encourage the CAB Forum to take on that work.
>> Also, as has been discussed, it is quite reasonable to argue that the
>> inclusion of this extension is already forbidden in a BR-compliant
>> certificate.
>>
>
> Because then the Mozilla ban will be used to prevent any work on logotypes
> in CABForum and the lack of CABForum rules will be used as pretext for not
> removing the ban.
>
> I have been doing standards for 30 years. You know this is exactly how
> that game always plays out.
>
>
Citation please? The last two examples I can recall of a Browser clarifying
or overriding CAB Forum policy are:
1. banning organizationIdentifier - resulting in ballot SC17 [1] , which
properly defines the requirements for using this Subject attribute.
2. banning domain validation method #10 - resulting in the ACME TLS ALPN
challenge [2], which is nearly through the standards process.

In both examples, it appears that Browser policy encouraged the development
of standards.

If you don't want to use the extension, that is fine. But if you attempt to
> prohibit anything, ruin it by your lawyers first and ask them how it is not
> an a restriction on trade.
>
> It is one thing for CABForum to make that requirement, quite another for
> Mozilla to use its considerable market power to prevent other browser
> providers making use of LogoTypes.
>


If this proposal applied to any certificate issued by a CA, I might agree,
but it doesn't. CAs are free to do whatever they want with hierarchies that
aren't trusted by Mozilla. It's not clear to me how a CA would get a
profile including a Logotype through a BR audit, but that's beside the
point.


>

>

>
>
>> A better way to state the requirement is that CAs should only issue
>>> logotypes after CABForum has agreed validation criteria. But I think that
>>> would be a mistake at this point because we probably want to have
>>> experience of running the issue process before we actually try to
>>> standardize it.
>>>
>>>
>> I would be amenable to adding language that permits the use of the
>> Logotype extension after the CAB Forum has adopted rules governing its use.
>> I don't see that as a material change to my proposal because, either way,
>> we have the option to change Mozilla's position based on our assessment of
>> the rules established by the CAB Forum, as documented in policy section 2.3
>> "Baseline Requirements Conformance".
>>
>> I do not believe that changing the "MUST NOT" to "SHOULD NOT" reflects
>> the consensus reached in this thread.
>>
>> I also do not believe that publicly-trusted certificates are the safe and
>> prudent vehicle for "running the issue process before we actually try to
>> standardize it".
>>
>
> You are free to ignore any information in a certificate. But if you
> attempt to limit information in the certificate you are not intending to
> use in your product, you are arguably crossing the line.
>
>
It's quite clear from the discussions I've been involved in that at least
one goal for Logotypes is that Browsers process them.  You implied so
yourself above by stating that this proposal would "prevent other browser
providers making use of LogoTypes." So you are now suggesting that Browsers
ignore this information while others are suggesting precisely the opposite.

If publicly-trusted certificates containing Logotypes are issued prior to
some agreement on the rules, then we have created a "leg

Re: Logotype extensions

2019-07-10 Thread Wayne Thayer via dev-security-policy
On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker 
wrote:

> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Russ,
>>
>> >
>> Perhaps one of us is confused because I think we're saying the same thing
>> -
>> that  rules around inclusion of Logotype extensions in publicly-trusted
>> certs should be in place before CAs begin to use this extension.
>>
>
> I don't see how your proposed ban on logotypes is consistent. What that
> would do is set up a situation in which it was impossible for CABForum to
> develop rules for logotypes because one of the browsers had already banned
> their use.
>
>
How exactly does a Browser banning the use of an extension prevent the CAB
Forum from developing rules to govern the use of said extension? If
anything, it would seem to encourage the CAB Forum to take on that work.
Also, as has been discussed, it is quite reasonable to argue that the
inclusion of this extension is already forbidden in a BR-compliant
certificate.

A better way to state the requirement is that CAs should only issue
> logotypes after CABForum has agreed validation criteria. But I think that
> would be a mistake at this point because we probably want to have
> experience of running the issue process before we actually try to
> standardize it.
>
>
I would be amenable to adding language that permits the use of the Logotype
extension after the CAB Forum has adopted rules governing its use. I don't
see that as a material change to my proposal because, either way, we have
the option to change Mozilla's position based on our assessment of the
rules established by the CAB Forum, as documented in policy section 2.3
"Baseline Requirements Conformance".

I do not believe that changing the "MUST NOT" to "SHOULD NOT" reflects the
consensus reached in this thread.

I also do not believe that publicly-trusted certificates are the safe and
prudent vehicle for "running the issue process before we actually try to
standardize it".

I can't see Web browsing being the first place people are going to use
> logotypes. I think they are going to be most useful in other applications.
> And we actually have rather a lot of those appearing right now. But they
> are Applets consisting of a thin layer on top of a browser and the logotype
> stuff is relevant to the thin layer rather than the substrate.
>
>
If the use case isn't server auth or email protection, then publicly
trusted certificates shouldn't be used. Full stop. How many times do we
need to learn that lesson?


> For example, I have lots of gadgets in my house. Right now, every
> different vendor who does an IoT device has to write their own app and run
> their own service. And the managers are really happy with that at the
> moment because they see it as all upside.
>
> I think they will soon discover that most devices that are being made to
> Internet aren't actually very useful if the only thing they connect to is a
> manufacturer site and those start to cost money to run. So I think we will
> end up with an open interconnect approach to IoT in the end regardless of
> what a bunch of marketing VPs think should happen. Razor and blades models
> are really profitable but they are also vanishingly rare because the number
> 2 and 3 companies have an easy way to enter the market by opening up.
>
> Authenticating those devices to the users who bought them, authenticating
> the code updates. Those are areas where the logotypes can be really useful.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Logotype extensions

2019-07-10 Thread Wayne Thayer via dev-security-policy
Russ,

On Wed, Jul 10, 2019 at 11:41 AM housley--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote:
> > Based on this discussion, I propose adding the following statement to the
> > Mozilla Forbidden Practices wiki page [1]:
> >
> > ** Logotype Extension **
> > Due to the risk of misleading Relying Parties and the lack of defined
> > validation standards for information contained in this field, as
> discussed
> > here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or
> > Subscriber certificates.
> >
> > Please respond if you have concerns with this change. As suggested in
> this
> > thread, we can discuss removing this restriction if/when a robust
> > validation process emerges.
> >
> > - Wayne
> >
> > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> > [2]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ
>
> People find logos very helpful.  That is why many browsers display a tiny
> logo in the toolbar.
>
> I would suggest that a better way forward is to start the hard work on the
> validation process.  It will not be difficult for that to become more
> robust and accessible than the logos in the toolbar.
>
>
Perhaps one of us is confused because I think we're saying the same thing -
that  rules around inclusion of Logotype extensions in publicly-trusted
certs should be in place before CAs begin to use this extension.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DarkMatter Concerns

2019-07-09 Thread Wayne Thayer via dev-security-policy
The bug requesting that the existing subordinate CAs be added to OneCRL is
https://bugzilla.mozilla.org/show_bug.cgi?id=1564544

On Tue, Jul 9, 2019 at 8:31 AM Wayne Thayer  wrote:

> I would like to thank everyone for their constructive input on this
> difficult issue. I would also like to thank DarkMatter representatives for
> participating in the open, public discussion. I feel that the discussion
> has now, after more than 4 months, run its course.
>
> The question that I originally presented [1] to this community was about
> distrusting DarkMatter’s current intermediate CA certificates (6 total)
> based on credible evidence of spying activities by the company. While a
> decision to revoke trust in these intermediates would likely result in a
> denial of DarkMatter’s root inclusion request [2], the public discussion
> for that request has not yet begun. A decision not to revoke these
> intermediates does not necessarily mean that the inclusion request will be
> approved.
>
> Some of this discussion has revolved around compliance issues, the most
> prominent one being the serial number entropy violations discovered by
> Corey Bonnell. While these issues would certainly be a consideration when
> evaluating a root inclusion request, they are not sufficient to have
> triggered an investigation aimed at revoking trust in the DarkMatter
> intermediates or QuoVadis roots. Therefore, they are not relevant to the
> question at hand.
>
> Much of the discussion has been about the desire for inclusion and
> distrust decisions to be made based on objective criteria that must be
> satisfied. However, if we rigidly applied our existing criteria, we would
> deny most inclusion requests. As I stated earlier in this thread, every
> distrust decision has a substantial element of subjectivity. One can argue
> that we’re discussing a different kind of subjectivity here, but it still
> amounts to a decision being made based on a collective assessment of all
> the information at hand rather than a checklist.
>
> Some, including DarkMatter representatives [3], have declared the need to
> examine and consider the benefits of having DarkMatter as a trusted CA.
> However, last year we changed our policy to replace the weighing of
> benefits and risks with “based on the risks of such inclusion to typical
> users of our products.” [4]
>
> Perhaps the most controversial element in this discussion has been the
> consideration of “credible evidence”. The first component is the inherent
> uncertainty over what is “credible”, especially in this day and age. While
> it has been pointed out that respected news organizations are not beyond
> reproach [5], having four independent articles [6][7][8][9] from reputable
> sources published years apart does provide some indication that the
> allegations are credible. These articles are also extensively sourced.
>
> If we assume for a second that these allegations are true, then there is
> still a sincere debate over what role they should play in our decision to
> trust DarkMatter as a CA. The argument for considering these allegations is
> akin to the saying “where there’s smoke there’s fire”, while the argument
> against can be described as “innocent until proven guilty”.
>
> DarkMatter has argued [3] that their CA business has always been operated
> independently and as a separate legal entity from their security business.
> Furthermore, DarkMatter states that once a rebranding effort is completed,
> “the DarkMatter CA subsidiary will be completely and wholly separate from
> the DarkMatter Group of companies in their entirety.” However, in the same
> message, DarkMatter states that “Al Bannai is the sole beneficial
> shareholder of the DarkMatter Group.” and leaves us to assume that Mr. Al
> Bannai would remain the sole owner of the CA business. More recently,
> DarkMatter announced that they are transitioning all aspects of the
> business to DigitalTrust and confirmed that Al Bannai controls this entity.
> This ownership structure does not assure me that these companies have the
> ability to operate independently, regardless of their names and legal
> structure.
>
> Mozilla’s principles should be at the heart of this decision. “The Mozilla
> Manifesto [10] states:
>
> Individuals’ security and privacy on the internet are fundamental and must
> not be treated as optional.”
>
> And our Root Store policy states: “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, our foremost responsibility is to protect individuals who
> rely on Mozilla products.  I believe this framing strongly supports a
> decision to revoke trust in DarkMatter’s intermediate certificates. While
> there are solid arguments on both sides of this decision, it is reasonable
> to conclude that continuing to place trust in DarkMatter is a significant
> risk to our users. I will be opening a bug requesting 

Re: DarkMatter Concerns

2019-07-09 Thread Wayne Thayer via dev-security-policy
I would like to thank everyone for their constructive input on this
difficult issue. I would also like to thank DarkMatter representatives for
participating in the open, public discussion. I feel that the discussion
has now, after more than 4 months, run its course.

The question that I originally presented [1] to this community was about
distrusting DarkMatter’s current intermediate CA certificates (6 total)
based on credible evidence of spying activities by the company. While a
decision to revoke trust in these intermediates would likely result in a
denial of DarkMatter’s root inclusion request [2], the public discussion
for that request has not yet begun. A decision not to revoke these
intermediates does not necessarily mean that the inclusion request will be
approved.

Some of this discussion has revolved around compliance issues, the most
prominent one being the serial number entropy violations discovered by
Corey Bonnell. While these issues would certainly be a consideration when
evaluating a root inclusion request, they are not sufficient to have
triggered an investigation aimed at revoking trust in the DarkMatter
intermediates or QuoVadis roots. Therefore, they are not relevant to the
question at hand.

Much of the discussion has been about the desire for inclusion and distrust
decisions to be made based on objective criteria that must be satisfied.
However, if we rigidly applied our existing criteria, we would deny most
inclusion requests. As I stated earlier in this thread, every distrust
decision has a substantial element of subjectivity. One can argue that
we’re discussing a different kind of subjectivity here, but it still
amounts to a decision being made based on a collective assessment of all
the information at hand rather than a checklist.

Some, including DarkMatter representatives [3], have declared the need to
examine and consider the benefits of having DarkMatter as a trusted CA.
However, last year we changed our policy to replace the weighing of
benefits and risks with “based on the risks of such inclusion to typical
users of our products.” [4]

Perhaps the most controversial element in this discussion has been the
consideration of “credible evidence”. The first component is the inherent
uncertainty over what is “credible”, especially in this day and age. While
it has been pointed out that respected news organizations are not beyond
reproach [5], having four independent articles [6][7][8][9] from reputable
sources published years apart does provide some indication that the
allegations are credible. These articles are also extensively sourced.

If we assume for a second that these allegations are true, then there is
still a sincere debate over what role they should play in our decision to
trust DarkMatter as a CA. The argument for considering these allegations is
akin to the saying “where there’s smoke there’s fire”, while the argument
against can be described as “innocent until proven guilty”.

DarkMatter has argued [3] that their CA business has always been operated
independently and as a separate legal entity from their security business.
Furthermore, DarkMatter states that once a rebranding effort is completed,
“the DarkMatter CA subsidiary will be completely and wholly separate from
the DarkMatter Group of companies in their entirety.” However, in the same
message, DarkMatter states that “Al Bannai is the sole beneficial
shareholder of the DarkMatter Group.” and leaves us to assume that Mr. Al
Bannai would remain the sole owner of the CA business. More recently,
DarkMatter announced that they are transitioning all aspects of the
business to DigitalTrust and confirmed that Al Bannai controls this entity.
This ownership structure does not assure me that these companies have the
ability to operate independently, regardless of their names and legal
structure.

Mozilla’s principles should be at the heart of this decision. “The Mozilla
Manifesto [10] states:

Individuals’ security and privacy on the internet are fundamental and must
not be treated as optional.”

And our Root Store policy states: “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, our foremost responsibility is to protect individuals who
rely on Mozilla products.  I believe this framing strongly supports a
decision to revoke trust in DarkMatter’s intermediate certificates. While
there are solid arguments on both sides of this decision, it is reasonable
to conclude that continuing to place trust in DarkMatter is a significant
risk to our users. I will be opening a bug requesting the distrust of
DarkMatter’s subordinate CAs pending Kathleen’s concurrence. I will also
recommend denial of the pending inclusion request, and any new requests
from DigitalTrust.

In the past, we’ve seen CAs attempt to make an end run around adverse trust
decisions - through an acquisition, a shell company, etc. We will treat any

Re: Logotype extensions

2019-07-05 Thread Wayne Thayer via dev-security-policy
Based on this discussion, I propose adding the following statement to the
Mozilla Forbidden Practices wiki page [1]:

** Logotype Extension **
Due to the risk of misleading Relying Parties and the lack of defined
validation standards for information contained in this field, as discussed
here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or
Subscriber certificates.

Please respond if you have concerns with this change. As suggested in this
thread, we can discuss removing this restriction if/when a robust
validation process emerges.

- Wayne

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ

On Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/06/2019 18:54, Ryan Sleevi wrote:
> > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> In such a case, there are two obvious solutions:
> >>
> >> A. Trademark owner (prompted by applicant) provides CA with an official
> >> permission letter stating that Applicant is explicitly licensed to
> >> mark the EV certificate for a specific list of SANs and and Subject
> >> DNs with their specific trademark (This requires the CA to do some
> >> validation of that letter, similar to what is done for domain
> >> letters).
> >
> >
> > This process has been forbidden since August 2018, as it is fundamentally
> > insecure, especially as practiced by a number of CAs. The Legal Opinion
> > Letter (LOL) has also been discussed at length with respect to a number
> of
> > problematic validations that have occurred, due to CAs failing to
> exercise
> > due diligence or their obligations under the NetSec requirements to
> > adequately secure and authenticate the parties involved in validating
> such
> > letters.
> >
>
> Well, that was unfortunate for the case where it is not straing parent-
> child (e.g. trademark owned by a foundation and licensed to the company)
> But ok, in that case the option is gone, and what follows below is moot:
>
> >
> > Letter needs to be reissued for end-of-period cert
> >> renewals, but not for unchanged early reissue where the cause is not
> >> applicant loss of rights to items.  For example, the if the
> Heartbleed
> >> incident had occurred mid-validity, the web server security teams
> >> could get reissued certificates with uncompromised private keys
> >> without repeating this time consuming validation step.
> >
> >
> > EV certificates require explicit authorization by an authorized
> > representative for each and every certificate issued. A key rotation
> event
> > is one to be especially defensive about, as an attacker may be attempting
> > to bypass the validation procedures to rotate to an attacker-supplied
> key.
> > This was an intentional design by CAs, in an attempt to provide some
> value
> > over DV and OV certificates by the presumed difficulty in substituting
> them.
> >
>
> I was considering the trademark as a validated property of the subject
> (similar to e.g. physical address), thus normally subject to the 825 day
> reuse limit.  My wording was intended to require stricter than current
> BR revalidation for renewal within that 825 day limit.
>
>
> 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: Avast Antivirus enables the entire Microsoft PKI for Firefox

2019-05-21 Thread Wayne Thayer via dev-security-policy
On Tue, May 21, 2019 at 1:23 PM Adrian R via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Wayne Thayer  wrote:
> >
> >
> > That is not my understanding of how this setting works: it only imports
> > roots that have been added to the Windows root store, e.g. by a program
> > such as Avast, or an administrator. It does not import roots Microsoft
> > ships with Windows.
> >
>
> The problem is that if a root certificate is revoked locally by:
> - exporting it from any place in the windows certificate store,
> - adding it to the Untrusted Certificates store
> - keeping it untouched in the initial store where it was exported from ...
>  Firefox considers that certificate as valid when it should consider it as
> revoked.
> Windows considers such a certificate to be revoked.
>
>
There is a big difference between importing the entire Windows root store
and thus effectively overriding Mozilla's trust decisions, and importing
roots added by an antivirus program, so I wanted to clarify that.

The bug that you filed (thanks!) should address the revocation issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1553233

>
> With Avast antivirus it's not possible to delete their MITM scanner
> certificate because they will re-create another if i delete it, but they
> allow it to be revoked and stay revoked.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Avast Antivirus enables the entire Microsoft PKI for Firefox

2019-05-21 Thread Wayne Thayer via dev-security-policy
On Tue, May 21, 2019 at 12:59 PM Adrian R via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello
>
> Today, as part of an "upgrade" to version 19.5 Avast Antivirus has
> forcefully enabled the entire Microsoft PKI for all Firefox users that also
> happen to be users of Avast [Free] Antivirus.
>
> They now forcefully set this Mozilla enterprise policy for all users of
> Avast:
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Certificates
> "ImportEnterpriseRoots"=dword:0001
>
> And this causes Mozilla Firefox to trust all the root certificates in the
> Windows store...


That is not my understanding of how this setting works: it only imports
roots that have been added to the Windows root store, e.g. by a program
such as Avast, or an administrator. It does not import roots Microsoft
ships with Windows.


> but with a bug: Firefox ignores the local revocation info for root
> certificates and thus considers revoked root certificates as being valid.
>
>
> Related Mozilla bugzilla bug id: 1553233
>
> *sigh*
>
> 
> Adrian R.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-16 Thread Wayne Thayer via dev-security-policy
On Thu, May 16, 2019 at 4:23 PM Wayne Thayer  wrote:

I will soon file a bug requesting removal of the “Certinomis - Root CA”
> from NSS.
>

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-16 Thread Wayne Thayer via dev-security-policy
I would like to thank everyone for your constructive input during this
discussion. Since my post last week suggesting two options for distrusting
the existing Certinomis root, a number of events have occurred, including
the following:

* Certinomis confirmed that they have implemented pre-issuance linting [1],
although it has more recently been disclosed that the linting is not active
on older subCAs that Certinomis no longer intend to use for TLS [2][3].
* Francois posted a detailed response [2] to the issues list [4], and
followed that with another explanation of how the response covers all of
the issues that were identified [5].
* Four new precertificates containing an invalid SAN value [6] were found
to have been issued on 13-May, after pre-issuance linting was in place.
This was explained as being caused by a misconfiguration that allowed TLS
issuance from one of the older subCAs without pre-issuance linting in place.
* On 13-May, 174 precertificates with ‘unknown’ OCSP status were discovered
[7]. Two more were discovered on 14-May. Certinomis currently does not have
a solution to this problem [3].
* On 15-May, Andrew Ayer argued in this thread that Certinomis responds
poorly to incidents.

While the most recent incidents have not yet been fully understood, their
existence points to the fact that Certinomis continues to demonstrate
compliance issues, and it supports my previous recommendation to distrust
the Certinomis root. While I encourage continued discussion of these
issues, at this time we have enough information to make a decision.

I proposed an option involving name constraining the existing Certinomis
root rather than completely removing it from the Mozilla NSS root store.
The feedback that was received was largely against this idea, and the
arguments presented for not extending trust in the most important gouv.fr
government site certificates - especially when they haven’t asked us to do
so - are compelling.

In conclusion, I recommend the following:

Remove the “Certinomis - Root CA” from the Mozilla root store in an
upcoming NSS release.
* Treat any cross-signature of the existing root by another CA in Mozilla’s
program as a policy violation that will (at a minimum) result in the
immediate addition of the cross-certificate to OneCRL.

Allow Certinomis to apply for inclusion in the Mozilla program with one or
more newly created root(s)
* Certinomis must undergo the normal Mozilla root inclusion process
* Certinomis may be required to explain in detail how the issues discussed
in this thread have been resolved.
* A new audit report covering a period ending after the new root(s) are
created will be required prior to completing the inclusion process.

Mozilla may consider permitting an existing Mozilla CA Program member to
cross-sign the new root under certain conditions, such as requiring
Certinomis to produce a “clean” audit prior to the signing. Any such
agreement must be disclosed to Mozilla, discussed on this list, and
approved by Mozilla before the new Certinomis root key(s) are signed by any
root included in our program.

I will appreciate any feedback you have on this recommendation.

I will soon file a bug requesting removal of the “Certinomis - Root CA”
from NSS. If Kathleen accepts this recommendation, I predict that the root
will be removed in the version of NSS that ships with Firefox 69 in
September [8].

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c8
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c3
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c6
[4] https://wiki.mozilla.org/CA/Certinomis_Issues
[5]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/UiLZU1gDBQAJ
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[8] https://wiki.mozilla.org/Release_Management/Calendar

On Tue, May 7, 2019 at 4:48 PM Wayne Thayer  wrote:

> Since I began this discussion, additional recent misissuances by
> Certinomis have been discovered and reported. [1] [2] [3] One investigation
> [1] led us to suspect that Certinomis had continued to employ BR domain
> validation method 3.2.2.4.5 after it was banned [4]. A former Certinomis
> employee denied this [5], and over a week passed with no official response
> from Certinomis before they stated that the former employee is correct.
> Unfortunately, we have also seen no engagement from Certinomis on this
> mozilla.dev.security.policy list since I began the discussion, almost 3
> weeks ago. This week, the primary contact stated [6] “I am on holidays
> until 14th of may, please apologize my slow answering.”
>
> On a positive note, on 6-May Certinomis stated in multiple bugs that
> pre-issuance linting is now operational.
>
> I have updated the issues list [7] to reflect these changes.
>
> As others have stated during this discussion, I believe that the issues I
> have documented demonstrate a basic inability to operate effective 

Re: DarkMatter Concerns

2019-05-15 Thread Wayne Thayer via dev-security-policy
Thank you for sharing this information Scott.

On Wed, May 15, 2019 at 2:49 AM Scott Rea  wrote:

>
> Please advise if additional information relating to this change is
> required.
>
>
As pointed out in earlier discussions about DarkMatter's QuoVadis-signed
intermediates [1], and the policy 2.7 proposal that aims resolve this issue
[2], it's not clear if section 8 of Mozilla policy applies to subordinate
CA certificates, or only roots. Given the lack of clarity and enforcement
to-date, I do not believe that the section 8.1 requirement for "...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" should be applied to this
change at this time. The information you provided will, of course, be
considered as part of the ongoing distrust discussion that will continue in
this thread.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/xGGGaI1_uo0/e2e6RAEBBgAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/bWc70D8Kk6I/fafb9lXqCwAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-05-14 Thread Wayne Thayer via dev-security-policy
On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/10/19 5:46 PM, Wayne Thayer wrote:
> > I've attempted to update section 6 to incorporate revocation requirements
> > for S/MIME certificates:
> >
> >
> https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637
> >
> > Note: since much of this language is copied directly from the BRs, if we
> > decide to adopt it, the policy will also need to comply with the Creative
> > Commons Attribution 4.0 International license used by the BRs.
> >
> > I will greatly appreciate everyone's review and comments on this proposed
> > change.
>
>
> The proposed changes look OK to me.
>
> But I would also be fine with the new section 6.2 regarding revocation
> of S/MIME certs just re-using the revocation text that we used to have
> in our policy (which had been removed in an effort to remove redundancy
> with the BRs).
>
>
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
>
>
The 'reasons for revocation' from the old policy are very close to the BR
language I proposed. The main difference in my proposal is the inclusion of
deadlines by which certificates must be revoked (same as in the BRs). While
the BR deadlines have sometimes been challenging, I do feel that we're
better off to have them as our standard and handle exceptions as incidents,
so my preference is to stick with my proposal.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

2019-05-14 Thread Wayne Thayer via dev-security-policy
On Mon, May 13, 2019 at 9:13 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Though it seems the thread has largely expressed my concerns I do want to
> chime in and stress that I believe that it is important that this text gets
> clarified.
>
>
Does replacing the existing "require practice" language by adding the
following sentence to the Root Store Policy achieve the clarity you're
seeking and avoid the problems you've pointed out?

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."


Email addresses are, as has been pointed out, tricky.
>
> Today it is common practice for CAs to send "ping mails" for every
> certificate that is sent, this has been a common interpretation for what
> "email certificate" validation has to look like.
>
> This, however, excludes things like:
> > Using MX records, as a means to look at which mail service is
> authoritative for that domain and delegating the local part to the entity
> operating the mail service.
> > Using DNS records as a means to determine who is authoritative for that
> domain and delegating the local part to that entity.
> > Relying on OAUTH based redirection flows from mail service providers
> such as Google, Microsoft, and others.
>
> These options all offer strong and friction-free user experiences for the
> associated use cases.
>
> I also think that since emails have become the most common account
> identifier excluding the ability for a CA to enter into an RA agreement
> essentially precludes the use of email certificates by anyone other than a)
> the CA or b) the mail service provider.
>
> This means, as an example, one could not use Mozilla trusted certificates
> at scale for mail or document signing unless it was provided by one of
> those two entities.
>
> This is because out of context ping emails to individual users (what many
> CAs offer today) is essentially a deal breaker.
>
>
A deal breaker due to the poor usability involved in interrupting a task
while the user retrieves an email and confirms receipt?

The scale and nature of email validation are such that RA style agreements
> should, in my personal opinion, be within reason to accommodate.
>
>
It's not clear to me if you are arguing for the policy I proposed above, or
the ability for a CA to also delegate the validation of the domain name
part to a 3rd party RA?


> This is particularly problematic in that even if other root stores allowed
> the use of RA agreements for email certificates it would no longer be
> allowed; in essence, precluding the adoption of publicly trusted client
> certificates for mainstream SASS applications.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents

2019-05-14 Thread Wayne Thayer via dev-security-policy
I've gone ahead and made this change in the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/3a70cf31cf81f5e00b62f958fe8a3b59c7cb0f34

I'll consider this issue resolved unless further comments are received.

- Wayne

On Mon, May 13, 2019 at 11:41 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wayne,
> I agree with this approach, it's quite explicit but flexible at the same
> time.
> Thanks,
> Pedro
>
> El martes, 14 de mayo de 2019, 0:49:40 (UTC+2), Wayne Thayer  escribió:
> > On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Hi Wayne,
> > > inserting my comments below.
> > > Best,
> > > Pedro
> > >
> > > El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer
> escribió:
> > > > I have drafted the change as proposed, moving the exact "Required
> > > Practice"
> > > > language into section 3.3 of the policy:
> > > >
> > >
> https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
> > > >
> > > > On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via
> dev-security-policy <
> > > > dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I totally agree about the (...) be disclosed in the CPS.
> > > > >
> > > > >
> > > > Pedro: I agree with you if there is only one CP. However when there
> are
> > > > multiple CPs, there needs to be some way to determine which one
> applies
> > > to
> > > > each CA certificate. Does the language I proposed give you enough
> > > > flexibility to meet the requirement without forcing the listing of
> every
> > > > intermediate in your CPs?
> > >
> > > My point about the wording is that you propose to disclose this
> > > information in both the CP and the CPS, and I propose that this is made
> > > mandatory in the CPS only, as it can happen that the CA is adopting a
> CP
> > > defined by another entity.
> > > So I'd prefer a wording that says: "CPSes must clearly indicate which
> root
> > > and intermediate certificates the practices and processes described in
> CPs
> > > and CPSes documents apply to. "
> > >
> > > > My rational is that (...) a leaf certificate with a CP
> > > > >
> > > >
> > > > Can we determine which CP applies to a given intermediate based on
> OIDs?
> > > >
> > >
> > > Right now is only mandatory to use the OIDs in SSL certificates, but we
> > > embraced this as a general practice for the new CAs we are deploying,
> so
> > > all new certificates include a policy OID, as stipulated in the
> related CP
> > > document, independently if are SSL or Personal certificates.
> > >
> > > >* its own CPS, that (...)  a particular kind, but this
> > > > > information must be disclosed in the CA's CPS.
> > > > >
> > > > >
> > > > I think it is okay if a CP isn't aware of a particular CA
> certificate, as
> > > > long as there is some clear way to determine which CP applies to that
> > > > intermediate. How does the CPS identify which CP applies to each
> > > > intermediate?
> > >
> > > Actually we updated recently our WISeKey CPS to accommodate this
> change.
> > > Previously we were relying on publishing the current version of the
> list of
> > > Issuing CAs in the website, but I added this explicitly in the WISeKey
> CPS.
> > > If you check our new CPS (you can get it at
> > > https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the
> method
> > > we use to disclose this:
> > > - In section 1.3.1 we disclose the Roots and Intermediates and in
> > > particular in section 1.3.1.3 we clarify about the Issuing CAs and we
> make
> > > a reference to the Annex B (using an Annex because of the different
> page
> > > format so it's easer to read and maintain)
> > > - In Annex B (page 63 at the end of the doc) we add the list of the
> active
> > > intermediate and issuing CAs, mapping it to the allowed CP they issue
> > >
> > > I think the only place where we can disclose this is in the WISeKey
> CPS,
> > > as the CP documents published by the OISTE Foundation set the rules to
> be
> > > implemented by the CAs operating in the trust model, but aren't
> necessarily
> > > aware of the particular Issuing CAs allowed to issue the CP.
> > >
> > > >
> > > > Our particular approach (...)
> > >
> > >
> > Thank you Pedro, this helps to clarify your concern. I think your
> approach
> > is good, but I am concerned that limiting the scope of the requirement to
> > only the CPS does not address my concern when CAs have multiple CPs. Here
> > is an alternate proposal:
> >
> > CAs must provide a way to clearly determine which CP and CPS applies to
> > each root and intermediate certificate.
> >
> > I think that this would allow you to continue with the approach you
> > described above. Do you agree?
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trusted Recursive Resolver Policy in India

2019-05-14 Thread Wayne Thayer via dev-security-policy
On Sun, May 12, 2019 at 9:59 AM Nemo via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> I've been running a public DNSCrypt resolver[0] for the last 2 years,
> and would like to start a DoH resolver as well. I went through the
> DoH-Resolver-Policy page[1] and have setup a Draft Policy for my
> resolver that is based on it[2].
>
> India specifically, has a lot of Internet Blocks implemented
> haphazardly[3], and I believe that a resolver under Indian jurisdiction
> will help with some of these issues. Right now the blocks are all
> implemented by ISPs as per secret court orders, and we are reliant upon
> user reports to figure out which ISP has blocked what. Most of these
> blocks are implemented on the DNS Level, so DoH has a chance of fixing
> the gap.
>
> Running a independent resolver in the Indian jurisdiction would give us
> a way to challenge blocks in court, and maintain a log of these.
>
> I tried searching online, but could not find the process for getting a
> resolver added to the program. Appreciate any help on the same.
>
> You are correct that Mozilla has not yet published an application process
for DNS over HTTPS Trusted Recursive Resolvers that meet the Mozilla policy
requirements, but I am working on an answer for your specific request.
Meanwhile, it's relatively easy to configure a TRR in Firefox by going to
Preferences, scrolling to the Network Settings section and selecting
"Settings...", then selecting "Enable DNS over HTTPS".

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


Re: Certificates with subject stateOrProvinceName "Some-State"

2019-05-13 Thread Wayne Thayer via dev-security-policy
Thanks for reporting this Alex.

I have created the following bugs to track these issues:
Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1551362
DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1551363
SwissSign: https://bugzilla.mozilla.org/show_bug.cgi?id=1551364
Government of Turkey: https://bugzilla.mozilla.org/show_bug.cgi?id=1551369
T-Systems: https://bugzilla.mozilla.org/show_bug.cgi?id=1551371
Telia: https://bugzilla.mozilla.org/show_bug.cgi?id=1551372
SecureTrust: https://bugzilla.mozilla.org/show_bug.cgi?id=1551374
certSIGN: https://bugzilla.mozilla.org/show_bug.cgi?id=1551375

- Wayne

On Sat, May 11, 2019 at 10:37 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Inspired by Nick Lamb's comment a week or so ago on m.d.s.p about "Default
> City" being an OpenSSL default value in CSRs, I ran some more searches on
> the OpenSSL defaults and found almost 100 certificates with a
> stateOrProvinceName of "Some-State". BR section 7.1.4.2.2(f) requires this
> field to be verified if present in a certificate.
>
> Affected CAs are Sectigo, DigiCert, SwissSign, Government of Turkey,
> T-Systems, Telia, SecureTrust, and certSIGN.
>
> Here's the batch: https://misissued.com/batch/53/
>
> Alex
> ___
> 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.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

2019-05-13 Thread Wayne Thayer via dev-security-policy
On Mon, May 13, 2019 at 2:09 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Piggybacking to Ryan's message and putting into my mundane words, I'd say
> that is reasonable to say that a CA must not delegate the validation of
> what is after the @ in the email address, but I think it's totally
> admissible to let the domain owner (and typically email service provider)
> to assume the task to issue certificates to its users without further
> intervention of the CA once the domain part has been validated.
>
> Just my two cents...
>
> Pedro
>
> El lunes, 13 de mayo de 2019, 19:58:46 (UTC+2), Ryan Sleevi  escribió:
> > On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > The BRs forbid delegation of domain and IP address validation to third
> > > parties. However, the BRs don't forbid delegation of email address
> > > validation nor do they apply to S/MIME certificates.
> > >
> > > Delegation of email address validation is already addressed by
> Mozilla's
> > > Forbidden Practices [1] state:
> > >
> > > "Domain and Email validation are core requirements of the Mozilla's
> Root
> > > Store Policy and should always be incorporated into the issuing CA's
> > > procedures. Delegating this function to 3rd parties is not permitted."
> > >
> > > I propose that we move this statement (changing "the Mozilla's Root
> Store
> > > Policy" to "this policy") into policy section 2.2 "Validation
> Practices".
> > >
> > > This is https://github.com/mozilla/pkipolicy/issues/175
> > >
> > > I will appreciate everyone's input on this proposal.
> > >
> > > - Wayne
> > >
> >
> > This strikes me as tricky to get right, because an e-mail contains both a
> > local-part and a domain (to use the terminology from RFC 5322, 3.4.1) [1]
> >
> > Under the SSL/TLS model, we do allow partial (conceptual) delegation of
> > domain validation, with respect to Section 1.3.2 of the BRs [2] ("The CA
> > SHALL confirm that the requested Fully-Qualified Domain Name(s) are
> within
> > the Enterprise RA's verified Domain Namespace") and the use of
> > "Authorization Domain Names". I say it's partial, because the CA still
> has
> > certain obligations (such as CAA checking), but otherwise can allow an
> > external entity to represent subdomains as authorized, without requiring
> > additional control validation.
> >
> > I highlight this, because in the context of S/MIME, the question is
> whether
> > or not the CA is responsible for validating the local-part, or whether it
> > may delegate validation of that to the operator of the domain. The
> > semantics of the local-part are entirely at the responsibility of the
> > holder - they can, for example, dictate that local-parts are equivalent
> > based on the presence of full-stop (".") characters, or they might even
> > designate equivalence based on the presence of some token (for example,
> the
> > use of "+label"), both examples taken from Gmail/GSuite, but which have
> > since expanded among industry.
> >
> > I think it's fairly reasonable to designate an organization as an
> > Enterprise RA, in the S/MIME sense, allowing them to control issuance for
> > arbitrary local-parts if they've demonstrated control over the domain
> (and
> > thus, correspondingly, the primary MX records). Is this something you
> think
> > is reasonable to continue supporting, or is this something you'd like to
> > prohibit? Understanding your/Mozilla's goals would help figure out
> > productive next steps - whether to convince you otherwise ;) or to
> provide
> > draft language accounting for it.
> >
>

The goal of this issue is to move a currently "required practice" into the
formal policy so that we don't have requirements that aren't explicitly
called out in policy. However, everyone has made it clear that the current
statement is too vague to add to our policy.

I think we can rely on the BRs to set forth the requirements for TLS
certificates.

If we are going to craft a policy for S/MIME, I agree that we should permit
delegation of the local-part. The resulting language could be:

CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party.

Thoughts?

> [1] https://tools.ietf.org/html/rfc5322#section-3.4.1
> > [2]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents

2019-05-13 Thread Wayne Thayer via dev-security-policy
On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Wayne,
> inserting my comments below.
> Best,
> Pedro
>
> El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer  escribió:
> > I have drafted the change as proposed, moving the exact "Required
> Practice"
> > language into section 3.3 of the policy:
> >
> https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
> >
> > On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Hello,
> > >
> > > I totally agree about the (...) be disclosed in the CPS.
> > >
> > >
> > Pedro: I agree with you if there is only one CP. However when there are
> > multiple CPs, there needs to be some way to determine which one applies
> to
> > each CA certificate. Does the language I proposed give you enough
> > flexibility to meet the requirement without forcing the listing of every
> > intermediate in your CPs?
>
> My point about the wording is that you propose to disclose this
> information in both the CP and the CPS, and I propose that this is made
> mandatory in the CPS only, as it can happen that the CA is adopting a CP
> defined by another entity.
> So I'd prefer a wording that says: "CPSes must clearly indicate which root
> and intermediate certificates the practices and processes described in CPs
> and CPSes documents apply to. "
>
> > My rational is that (...) a leaf certificate with a CP
> > >
> >
> > Can we determine which CP applies to a given intermediate based on OIDs?
> >
>
> Right now is only mandatory to use the OIDs in SSL certificates, but we
> embraced this as a general practice for the new CAs we are deploying, so
> all new certificates include a policy OID, as stipulated in the related CP
> document, independently if are SSL or Personal certificates.
>
> >* its own CPS, that (...)  a particular kind, but this
> > > information must be disclosed in the CA's CPS.
> > >
> > >
> > I think it is okay if a CP isn't aware of a particular CA certificate, as
> > long as there is some clear way to determine which CP applies to that
> > intermediate. How does the CPS identify which CP applies to each
> > intermediate?
>
> Actually we updated recently our WISeKey CPS to accommodate this change.
> Previously we were relying on publishing the current version of the list of
> Issuing CAs in the website, but I added this explicitly in the WISeKey CPS.
> If you check our new CPS (you can get it at
> https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the method
> we use to disclose this:
> - In section 1.3.1 we disclose the Roots and Intermediates and in
> particular in section 1.3.1.3 we clarify about the Issuing CAs and we make
> a reference to the Annex B (using an Annex because of the different page
> format so it's easer to read and maintain)
> - In Annex B (page 63 at the end of the doc) we add the list of the active
> intermediate and issuing CAs, mapping it to the allowed CP they issue
>
> I think the only place where we can disclose this is in the WISeKey CPS,
> as the CP documents published by the OISTE Foundation set the rules to be
> implemented by the CAs operating in the trust model, but aren't necessarily
> aware of the particular Issuing CAs allowed to issue the CP.
>
> >
> > Our particular approach (...)
>
>
Thank you Pedro, this helps to clarify your concern. I think your approach
is good, but I am concerned that limiting the scope of the requirement to
only the CPS does not address my concern when CAs have multiple CPs. Here
is an alternate proposal:

CAs must provide a way to clearly determine which CP and CPS applies to
each root and intermediate certificate.

I think that this would allow you to continue with the approach you
described above. Do you agree?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

2019-05-13 Thread Wayne Thayer via dev-security-policy
The BRs forbid delegation of domain and IP address validation to third
parties. However, the BRs don't forbid delegation of email address
validation nor do they apply to S/MIME certificates.

Delegation of email address validation is already addressed by Mozilla's
Forbidden Practices [1] state:

"Domain and Email validation are core requirements of the Mozilla's Root
Store Policy and should always be incorporated into the issuing CA's
procedures. Delegating this function to 3rd parties is not permitted."

I propose that we move this statement (changing "the Mozilla's Root Store
Policy" to "this policy") into policy section 2.2 "Validation Practices".

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

I will appreciate everyone's input on this proposal.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-05-10 Thread Wayne Thayer via dev-security-policy
I've attempted to update section 6 to incorporate revocation requirements
for S/MIME certificates:

https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637

Note: since much of this language is copied directly from the BRs, if we
decide to adopt it, the policy will also need to comply with the Creative
Commons Attribution 4.0 International license used by the BRs.

I will greatly appreciate everyone's review and comments on this proposed
change.

- Wayne

On Mon, May 6, 2019 at 2:04 PM Jeremy Rowley 
wrote:

> I think it should be added by Mozilla. The CAB Forum is a long way from
> having an s/MIME policy in place (there's not even a working group yet).
> Having no policy for cert revocation related to s/MIME ignores that s/MIME
> are part of the Mozilla ecosystem and sequesters them from the rest of the
> policy.  Without a revocation policy, there's no requirement to revoke a
> certificate mis-issued that's non-TLS.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Friday, May 3, 2019 12:44 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal: Clarify Revocation Requirements for
> S/MIME Certificates
>
> Kathleen and Pedro,
>
> Thank you for raising these legitimate concerns. I continue to believe
> that a literal reading of the current requirement is that it already does
> apply to S/MIME certificates, and the discussion I mentioned supports that
> interpretation.
>
> I propose two new options to solve this problem:
> * Remove S/MIME certificates from the scope of section 6 and wait for the
> CAB Forum to publish baseline requirements for S/MIME. I suspect that is a
> few years away given that the working group is still in the process of
> being chartered. However, this option is consistent with some people's
> interpretation of the existing requirements.
> * Add a subsection on revocation specific to S/MIME certificates and
> populate it with a version of the BR requirements tailored to S/MIME. We'd
> probably need to include requirements for S/MIME Intermediates as well as
> leaf certificates.
>
> A third option would be to specify the parts of the BR revocation
> requirements that don't apply to S/MIME certificates, but after reviewing
> section 4.9.1, I think this would be confusing, at best.
>
> I would appreciate everyone's input on the best way to address this issue.
>
> - Wayne
>
>
> On Fri, May 3, 2019 at 5:12 AM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello,
> > my main concern about applying this would be that this would lead to
> > forbid the option to suspend a personal certificate.
> >
> > On a side note about suspension... I was not active in the forums when
> > this was discussed and adopted and I'm sure there was a clear benefit
> > on disallowing suspensions, but it's kind of a hassle already because
> > of the application of this rule to the whole hierarchy. We'd like for
> > example to have the capability to suspend a subordinate CA that is
> > under investigation or that is pending of an audit, but right now we
> > can't do it... extending these rules to personal certificates is not
> > something I'm personally too enthusiastic.
> >
> > Best,
> > Pedro
> >
> > El jueves, 2 de mayo de 2019, 17:32:43 (UTC+2), Kathleen Wilson
> escribió:
> > > Just want to make it very clear to everyone, that the proposal, to
> > > add the following text to section 6 of Mozilla's Root Store Policy
> > > would mean that certs constrained to id-kp-emailProtection
> > > (end-entity and intermediate), i.e. S/MIME certs, would be subject
> > > to the same BR rules and revocation timelines as TLS/SSL certs.
> > >
> > > > This requirement applies to certificates that are not otherwise
> > required
> > > >> to comply with the BRs.
> > >
> > > For example, Section 4.9.1.1 of the BRs says:
> > > ""
> > > MUST revoke a Certificate within 5 days if one or more of the
> > > following
> > > occurs: ...
> > >
> > > 1. The Certificate no longer complies with the requirements of
> > > Sections
> > > 6.1.5 and 6.1.6;
> > >  ...
> > > 7. The CA is made aware that the Certificate was not issued in
> > > accordance with these Requirements ""
> > >
> > > I interpret "these Requirements" to mean the BRs. Therefore, my
> > > interpretation of the proposed additional text is that certs that

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

2019-05-10 Thread Wayne Thayer via dev-security-policy
First off, I would like to remind everyone that participation in this forum
is subject to Mozilla's Community Participation Guidelines [1].

The arguments that have been made for adding an exception to our policy for
Policy CAs have not, in my opinion, made a clear and compelling case for
the exception. The only CA that has argued for this exception is the one
that proposed it. On the other hand, I do still believe that adding this
exception creates a significant new risk by introducing a poorly defined
term ("Policy CA") and by making enforcement more difficult. Unless
additional information is presented here, I do not plan to implement this
proposal.

- Wayne

[1] https://www.mozilla.org/en-US/about/governance/policies/participation/

On Thu, May 9, 2019 at 9:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/05/2019 05:25, Ryan Sleevi wrote:
> > On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 09/05/2019 16:35, Ryan Sleevi wrote:
> >>> Given that the remark is that such a desire is common, perhaps you can
> >>> provide some external references documenting how one might go about
> >>> configuring such a set-up, particularly in the context of TLS trust?
> >>> Similarly, I'm not aware of any system that supports binding S/MIME
> >>> identities to a particularly CA (effectively, CA pinning) - perhaps you
> >> can
> >>> provide documentation and reference for systems that perform this?
> >>>
> >>> Thanks for helping me understand how this 'common' scenario is actually
> >>> implemented, especially given that the underlying codebases do not
> >> support
> >>> such distinctions.
> >>>
> >>
> >> My description is based on readily available information from the
> >> following sources, that you should also have access to:
> >>
> >
> > It looks like your links to external references may have gotten stripped,
> > as I didn't happen to receive any.
> >
> > As it relates to the topic at hand, the system you described is simply
> that
> > of internal CAs, and does not demonstrate a need to use publicly trusted
> > CAs. Further, going back to your previous message, to which I was
> replying
> > to make sure I did not misunderstand, given that you stated it was
> common,
> > it seemed we established that such scenarios in that message, and further
> > expanded upon in this, already have the capability for enterprise
> > management.
> >
> > I wanted to make sure I did my best to understand, so that we can have
> > productive engagement on substance, specifically around whether there is
> a
> > technical necessity for the use of non-Root CAs to be capable of issuance
> > under multiple different trust purposes. It does not seem as if there's
> > been any external references to establish a technical necessity, so it
> does
> > not seem like the policy needs to be modified, based on the available
> > evidence.
> >
>
> There were no links, only descriptions of obvious facts that you
> willfully ignore in an effort to troll the community.
>
>
> 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: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

2019-05-10 Thread Wayne Thayer via dev-security-policy
On Mon, Apr 29, 2019 at 7:31 AM Peter Bowen  wrote:

> I support this, as long as Policy CAs meet the same operations standards
> and have the same issuance restrictions as root CAs. This would result in
> no real change to policy, as I assume roots not directly included in the
> Mozilla root store were already considered “roots” for this part of the
> policy.
>
> Section 5.3 already excludes "cross-certificates that share a private key
with a corresponding root certificate" from the EKU requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents

2019-05-10 Thread Wayne Thayer via dev-security-policy
I have drafted the change as proposed, moving the exact "Required Practice"
language into section 3.3 of the policy:
https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b

On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
>
> I totally agree about the need to specify this information clearly in the
> documentation framework, but I personally think that it's not always
> adequate to force listing the intermediate CA certificates in the CP, but
> definitely this information is required to be disclosed in the CPS.
>
>
Pedro: I agree with you if there is only one CP. However when there are
multiple CPs, there needs to be some way to determine which one applies to
each CA certificate. Does the language I proposed give you enough
flexibility to meet the requirement without forcing the listing of every
intermediate in your CPs?

My rational is that the Root CA in a Trust Model has the role to define
> different CP for the different certificate profiles that are allowed in the
> hierarchy, setting the rules to be implemented by the issuing CAs (this
> includes the OIDs to include in the certificates to identify the associated
> CP), and it's in the particular CPS published by a CA operating in the
> Trust Model where it's specified the CPs implemented and by which Issuing
> CAs.
>
> This is what we are intending now to do as part of the process to split
> the ownership of the Roots and the Issuing CAs, in our particular case, so
> we'd have:
> - The Root Owner (OISTE Foundation) defines:
>* A number of CP documents that define the practices to be implemented
> while issuing a particular type of certificate. This includes things from
> the allowed validation practices to the OIDs to be included in the
> certificates to associate a leaf certificate with a CP
>

Can we determine which CP applies to a given intermediate based on OIDs?

   * its own CPS, that has as main scope the Root CAs, but also defines the
> general practices of the whole Trust Model
> - A subordinate CA operating under the Root, in our case it would WISeKey,
> defines:
>* A CPS which is defined in accordance of the OISTE CPS and that
> discloses the practices implemented while issuing certificates of one or
> more of the CP defined by OISTE. It's here where WISeKey includes the
> information about the Issuing CAs implementing the different OISTE CP
>
> With this scenario, we consider that the CP document is not aware of the
> particular CA that issues certificates of a particular kind, but this
> information must be disclosed in the CA's CPS.
>
>
I think it is okay if a CP isn't aware of a particular CA certificate, as
long as there is some clear way to determine which CP applies to that
intermediate. How does the CPS identify which CP applies to each
intermediate?

Our particular approach can be seen here:
> - CP and CPS published by the OISTE Foundation:
> https://oiste.org/repository/
> - CPS published by WISeKey (New version 3.0):
> https://www.wisekey.com/repository/
>
> So, this discussion is relevant to us, as it could imply that our approach
> might need to be adapted.
>
> Best,
> Pedro
>
> PS Please note that WISeKey as not fully adopted yet the new CP/CPS
> documentation framework, as this has a dependency on Mozilla approving our
> transfer request, as it's being discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hueaxNtUNl0
>
> El sábado, 27 de abril de 2019, 0:15:00 (UTC+2), Wayne Thayer  escribió:
> > The required practice "Publicly Available CP and CPS" [1] states:
> >
> > The CP/CPS must clearly indicate which root and subordinate certificates
> > > the practices and processes described in those documents apply to.
> >
> >
> > This can be done in (at least) two ways:
> > * the policy document can unambiguously list the specific CA certificates
> > within its scope
> > * the CA certificate can contain one or more policy OIDs that are
> > referenced in the applicable policy documents
> >
> > I have found that many CP/CPSes don't clearly list the certificates that
> > are in-scope, and the binding between policy OIDs in subordinate CA
> > certificates and CP/CPSes is often unclear when the CA has multiple
> policy
> > documents.
> >
> > My concern is that this could lead to situations where a CA can pick and
> > choose policies to argue that a given certificate is compliant.
> >
> > However, BR section 7.1.2.3 already requires each end-entity certificate
> to
> > include "A Policy Identifier, defined by the issuing CA, that indicates a
> > Certificate Policy asserting the issuing CA's adherence to and compliance
> > with these Requirements." I'm much more interested in compliance with the
> > BRs and Mozilla policy than the CA's own CPS, so this mitigates my
> concern.
> >
> > Even though I don't think this is as important now that I've given it
> some
> > thought, I propose moving the 

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-05-10 Thread Wayne Thayer via dev-security-policy
Having received no comments on these proposed changes, I plan to include
them in version 2.7 of our policy.

- Wayne

On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer  wrote:

> Ryan Sleevi made the following proposal:
>
> Issue #122 [1] previously discussed Section 8 in the context of
>> subordinate CAs, with a change [2] being made to include subordinate CAs
>> (in the context of Section 5.3.2) within scope of notification requirements.
>>
>> However, as presently worded, it's ambiguous as to whether or not
>> Sections 8.1 through 8.3 also apply to subordinate CAs, or whether the only
>> disclosure required is upon the initial introduction of the subordinate.
>> This confusion results from language such as in Section 8.1, "or when an
>> organization buys the private key of a certificate in Mozilla's root
>> program", implying that private keys which transitively chain to a root
>> certificate within Mozilla's program are exempt from such requirements.
>>
>> This ambiguity creates incentives for situations such as cross-signing
>> CAs that might otherwise or have been otherwise rejected from direct
>> inclusion within the Mozilla program. It further creates issues with
>> respect to the supervision of audits and auditors.
>>
>> While it is true that the signing CA accepts the risk that an unfavorable
>> verdict on the subordinate may impact the root, the cost of such a decision
>> is primarily borne by Mozilla and the broader community, in that they are
>> responsible for the collateral ecosystem challenges and devising
>> appropriate solutions. This has been demonstrated, for example, through the
>> discussion of Symantec issues [3].
>>
>> Because Mozilla and the community bear significant cost, especially as
>> more time passes and more certificates are issued, the following changes
>> are suggested:
>>
>>1. Align Section 8, and its subsections, with language similar to
>>that of Section 3.1.2.1. That is, that the policy is applicable to a CA 
>> and
>>all subordinate CAs technically capable of issuing (server or e-mail)
>>certificates
>>2. With respect to Section 8.1, extend the requirements of the last
>>paragraph to the issuance of subordinate CA certificates. Namely, if the
>>private key is in possession of an entity that is new to the Mozilla root
>>program, or subject to a CP or CPS that is new to the Mozilla Root 
>> Program,
>>that prior to the issuance of such a certificate, there be a public
>>discussion that results in a favorable conclusion.
>>
>> With the current policy as written, an existing/included root CA that
>> plans to exit the CA business might be prohibited (by virtue of Section
>> 8.1) from selling the business or (by virtue of Section 8.3) from
>> transferring the private key material. However, they are fully permitted to
>> cross-certify a new 'root' and then proverbially close up shop - with no
>> consideration for if their root gets removed as a consequence. These are
>> the same set of concerns that led to the introduction of Section 8, but
>> today exist due to the ambiguity with respect to the subsections.
>>
>
> I've proposed a fix for this issue:
> https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8
> It also attempts to clarify the applicability of section 8.3 as "only"
> when section 8.1 and/or section 8.2 also apply.
>
> This is https://github.com/mozilla/pkipolicy/issues/169 and
> https://github.com/mozilla/pkipolicy/issues/140
>
> I will greatly appreciate everyone's input on this topic. In particular, I
> would like to hear from CAs that would be affected by the requirement for
> any new subordinate CAs to go through a public discussion before issuing
> certificates, with the outcome being positive or else the subordinate CA
> certificate will be added to OneCRL (section 8.1).
>
> - Wayne
>
> [1] https://github.com/mozilla/pkipolicy/issues/122
> [2]
> https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
> [3] https://wiki.mozilla.org/CA:Symantec_Issues
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-10 Thread Wayne Thayer via dev-security-policy
On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi  wrote:

>
> On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> To continue to participate in the Mozilla CA program, I recommend that we
>> require Certinomis to create a new hierarchy and demonstrate their ability
>> to competently operate their CA by going through a new root inclusion
>> request. I’d like to propose two options for their existing root:
>>
>>1. Remove it from our root store in an upcoming Firefox release.
>>2. Constrain it to use for gouv.fr domains in an upcoming Firefox
>> release.
>>
>> While there are only a few thousand unexpired TLS certificates (the root
>> is
>> not trusted for email) known to chain to this root, a few are in use by
>> major French government websites (e.g. ants.gouv.fr). I have suggested
>> option #2 to minimize disruption to those subscribers and relying parties.
>>
>> I will greatly appreciate everyone’s input on my recommendation and the
>> proposed options.
>>
>
> Thanks Wayne for ensuring the conversation progresses in a timely fashion.
>
> Your Option #2 does have precedent, both by Mozilla and by other browser
> vendors, so I can understand the appeal. Some of these incidents have been
> documented by Mozilla [1] in the context of past discussions about
> voluntary name constraints [2], which captured a lengthy discussion about
> some of the tradeoffs involved.
>
> I appreciate that your Option #2 is only proposed in the context of
> addressing compatibility risks. Other CA events have prompted similar
> analysis, with different vendors taking different approaches (e.g. [3] vs
> [4]/[5],  [6] v [7]). Despite these initial differences, it's worth noting
> that even in these cases of addressing potential compatibility issues, the
> industry uniformly aligned on ultimately removing trust in these CAs. It is
> unclear whether your Option #2 is proposing such a convergence, and when,
> or whether you see this as an indefinite proposition.
>
>
If we decide to take option 2, I'm open to suggestions about the length of
time we should continue to trust the root for issuance to gouv.fr domains,
but I don't expect the answer to be "forever". One approach would be to
require a relatively quick transition prior to the inclusion of a new
Certinomis root. Another is to set a date far enough in the future that we
believe it would be reasonable for Certinomis to have a new root included
and transition to it, allowing gouv.fr site to continue to rely on
Certinomis.

One thing to consider with the creation of allowlists, whether in the
> context of name constraints (e.g. India CCA, ANSSI) or in the context of
> specific domains and certificates (Apple and Google, respectively, in the
> context of WoSign/StartCom), an important factor to consider is not just
> the compatibility, but the risk and value of the domain(s) being protected.
> If the conclusion is that Certinomis' existing controls are insufficient to
> provide reliable security, and its operations are not robust enough to
> provide the assurances that the community and Mozilla users critically
> depend on, then it seems important to also consider the potential harm of
> misissued certificates for those domains
>
> In the case of India CCA, this was part of the Indian National Informatics
> Center (India NIC), which itself was the domain registry for these domains.
> Similarly, while AFNIC is the operator for the French TLDs, ANSSI was the
> French national computer security agency to protect government systems. In
> these cases, the allowlist effectively and specifically accomodated the
> government needs and oversight. In the case of Certinomis, it is unclear
> whether the French Government itself would want to delegate the control and
> protection of its critical systems to an organization that has suffered
> such repeated failures.
>
> Has there been any communication with the agencies tasked with this - most
> likely, ANSSI itself? For example, the same concerns that lead to
> contemplating "Option #1" may similarly lead the French government to
> replace their certificates, rather than run further risk of misissuance.
> Similarly, has there been any consideration to simply allowlist the limited
> existing certificates, with a clear sunset date, as an alternative to name
> constraining?
>
>
No, I have not attempted to contact these site operators, nor has the
option of allowlisting specific certificates been given any consideration.
I am not opposed to the idea of allowlisting specific certificates.

My overarching concern with any solution that does not eventually coverge
> at #1, if not be

Re: Certinomis Issues

2019-05-10 Thread Wayne Thayer via dev-security-policy
On Fri, May 10, 2019 at 8:09 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear Wayne,
>
> I’m not arguing that signing the new Startom root was a mistake.In fact,
> as soon as we were told, we backed off.
> Our understanding at that time was that the remediation plan had been
> fully implemented. But the Mozilla staff did not agree and had another
> interpretation of the situation.
> I do not know how or when a distortion was introduced between Franck’s
> exchange with the Mozilla staff and our action.
> But there was no intent to circumvent the Mozilla plan, and we corrected
> it immediately when we were asked to do so.
> That is why I do not understand why this subject is included in the
> present discussions: if there has been an error, it is a past error,
> corrected in the past and on which no further action is possible.
>

The answer can be found on our Maintenance and Enforcement wiki page under
the Recurring Issues section [1], which states (in part) "Mozilla considers
the totality of known issues and patterns of behavior in a CA's response to
those issues."

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues

At a minimum it should only be recalled as a problem that has been solved.
>
> Kind Regards,
>
> François
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-09 Thread Wayne Thayer via dev-security-policy
On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/05/2019 02:22, Wayne Thayer wrote:
> > Thank you for this response Francois. I have added it to the issues list
> > [1]. Because the response is not structures the same as the issues list,
> I
> > did not attempt to associate parts of the response with specific issues.
> I
> > added the complete response to the bottom of the page.
> >
> > On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> ...
> > ...
>  >
> > In response to the email from Franck that you mention, Gerv responded [1]
> > by quoting the plan he had approved and stating "This seems to be very
> > different to the plan you implemented." By cross-signing Startcom's old
> > roots, Certinomis did assist Startcom in circumventing the remediation
> > plan, and by proposing one plan then implementing a different one,
> > Certinomis did so without Mozilla's consent.
> >
>
> As can be seen from your [3] link, Certinomis cross-signed StartCom's
> NEW supposedly remediated 2017 hierarchy, not the old root.
>
> Thank you for correcting me Jakob. I was confused by a statement in the
2017 thread that I referenced, but I see now that Certinomis only
cross-signed Startcom's new roots. Since Certinomis cross-signed Startcom's
new roots before the remediation plan was completed, I believe the
statements I made are otherwise correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-09 Thread Wayne Thayer via dev-security-policy
Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.

On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I don’t want to finish this answer without going back to the A issue, the
> Startcom cross-sign.
> I will not repeat all the history, Franck LEROY had detailed it in his
> e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of
> view: at no time did we in this case violate an existing rule, nor did we
> assist or seek to assist Startcom in circumventing the remediation plan
> proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand
> if what we wanted to do was acceptable, we clearly made it a condition for
> Iñigo to follow the plan and waited to be convinced that he had done so,
> and when, after all these precautions, we were told that we had not
> understood this remedial plan, we revoked both CAs without discussion.
> I hadn’t heard anything about it in those two years.
> So what is the factual criticism that is being made now, two years later?
> I don’t know about that.
> And what is the link with our difficulties of this year? None!
>
>
In response to the email from Franck that you mention, Gerv responded [1]
by quoting the plan he had approved and stating "This seems to be very
different to the plan you implemented." By cross-signing Startcom's old
roots, Certinomis did assist Startcom in circumventing the remediation
plan, and by proposing one plan then implementing a different one,
Certinomis did so without Mozilla's consent.

Startcom misissued a number of certificates (e.g. [3]) under that
cross-signing relationship that Certinomis is responsible for as the
Mozilla program member.

By cross-signing Startcom's roots, Certinomis also took responsibility for
Startcom's qualified audit.

I will also add this information to the issues list.

- Wayne

[1] https://wiki.mozilla.org/CA/Certinomis_Issues
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ
[3] https://crt.sh/?opt=cablint=160150786
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Reported Digicert key compromise but not revoked

2019-05-09 Thread Wayne Thayer via dev-security-policy
DigiCert CPS section 1.5.2 [1] could also more clearly state that
rev...@digicert.com is the correct address for 'reporting suspected Private
Key Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to
Certificates.' Since both email addresses are listed in that section, it's
not difficult to mistake supp...@digicert.com as the problem reporting
mechanism, even though the last sentence in 1.5.2.1 implies that
rev...@digicert.com is for problem reporting.

- Wayne

[1]
https://www.digicert.com/wp-content/uploads/2019/04/DigiCert_CPS_v418.pdf

On Thu, May 9, 2019 at 3:46 PM Andrew Ayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 9 May 2019 14:47:05 +
> Jeremy Rowley via dev-security-policy
>  wrote:
>
> > Hi Han - the proper alias is rev...@digicert.com. The support alias
> > will sometimes handle these, but not always.
>
> Is that also true of SSL certificates?  supp...@digicert.com is listed
> first at
>
> https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
>
> That should be fixed if supp...@digicert.com is not the right place to
> report problems with SSL certificates.
>
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-07 Thread Wayne Thayer via dev-security-policy
Since I began this discussion, additional recent misissuances by Certinomis
have been discovered and reported. [1] [2] [3] One investigation [1] led us
to suspect that Certinomis had continued to employ BR domain validation
method 3.2.2.4.5 after it was banned [4]. A former Certinomis employee
denied this [5], and over a week passed with no official response from
Certinomis before they stated that the former employee is correct.
Unfortunately, we have also seen no engagement from Certinomis on this
mozilla.dev.security.policy list since I began the discussion, almost 3
weeks ago. This week, the primary contact stated [6] “I am on holidays
until 14th of may, please apologize my slow answering.”

On a positive note, on 6-May Certinomis stated in multiple bugs that
pre-issuance linting is now operational.

I have updated the issues list [7] to reflect these changes.

As others have stated during this discussion, I believe that the issues I
have documented demonstrate a basic inability to operate effective issuance
controls. While I acknowledge the efforts that Certinomis has made to
correct their problems, they continued issuance in spite of clear evidence
that the problems weren’t resolved. Having now implemented pre-issuance
linting, it may be reasonable to expect that most of these problems are
finally resolved. However, prior to and during this discussion, they have
also continued a pattern of unresponsiveness and demonstrated a lack of the
deep understanding of our requirements and of their own operations that we
expect of every CA.

To continue to participate in the Mozilla CA program, I recommend that we
require Certinomis to create a new hierarchy and demonstrate their ability
to competently operate their CA by going through a new root inclusion
request. I’d like to propose two options for their existing root:

   1.

   Remove it from our root store in an upcoming Firefox release.
   2.

   Constrain it to use for gouv.fr domains in an upcoming Firefox release.


While there are only a few thousand unexpired TLS certificates (the root is
not trusted for email) known to chain to this root, a few are in use by
major French government websites (e.g. ants.gouv.fr). I have suggested
option #2 to minimize disruption to those subscribers and relying parties.

I will greatly appreciate everyone’s input on my recommendation and the
proposed options.


   -

   Wayne


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072#c4

[7] https://wiki.mozilla.org/CA/Certinomis_Issues
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Unretrievable CPS documents listed in CCADB

2019-05-03 Thread Wayne Thayer via dev-security-policy
On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'm against having to continually update the exact URL of the CP and CPS
> in the CCADB.



A relatively simple solution to this problem is to create a "permanent
link" to the current version of these docs (e.g.
https://digicert.com/repository/current_cp.pdf), then modify or redirect
the document that the link returns each time the document is updated as
part of the publishing process. Under this scheme, the CA should never need
to worry about updating CCADB.


>   It's pretty easy to find the current CP and CPS from a legal repository.



But not as easy as getting it from a CCADB report, especially when the
repository page doesn't clearly map a policy to a CA certificate.

  Plus, if we point to an exact one in the CCADB, it might not be the one
> that is applicable to a given certificate that was issued prior to the most
> current CPS.  In other words, you should look at when the certificate was
> issued and then figure out which CPS is applicable.
>
>
I'm almost always looking for the current policy rather than trying to
identify the version applicable to a specific certificate.


> -Original Message-
> From: dev-security-policy 
> On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Thursday, May 2, 2019 8:16 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Unretrievable CPS documents listed in CCADB
>
> On Thu, 2 May 2019 18:53:39 -0700 (PDT)
> Corey Bonnell via dev-security-policy
>  wrote:
>
> > As an aside, I noticed that several URLs listed in CCADB are “Legal
> > Repository” web page URLs that contain a list of many CP/CPS
> > documents. My recommendation is to slightly amend CCADB Policy to
> > require CAs to provide URLs to the specific document in question
> > rather than a general “Legal Repository” page, where it is left up to
> > the reader to decide which hyperlink on the page is the correct
> > document.
>
> +1.  It's often a real hassle to find the CP/CPS for a CA.  Linking
> directly to the document would help a lot.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-05-03 Thread Wayne Thayer via dev-security-policy
Kathleen and Pedro,

Thank you for raising these legitimate concerns. I continue to believe that
a literal reading of the current requirement is that it already does apply
to S/MIME certificates, and the discussion I mentioned supports that
interpretation.

I propose two new options to solve this problem:
* Remove S/MIME certificates from the scope of section 6 and wait for the
CAB Forum to publish baseline requirements for S/MIME. I suspect that is a
few years away given that the working group is still in the process of
being chartered. However, this option is consistent with some people's
interpretation of the existing requirements.
* Add a subsection on revocation specific to S/MIME certificates and
populate it with a version of the BR requirements tailored to S/MIME. We'd
probably need to include requirements for S/MIME Intermediates as well as
leaf certificates.

A third option would be to specify the parts of the BR revocation
requirements that don't apply to S/MIME certificates, but after reviewing
section 4.9.1, I think this would be confusing, at best.

I would appreciate everyone's input on the best way to address this issue.

- Wayne


On Fri, May 3, 2019 at 5:12 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
> my main concern about applying this would be that this would lead to
> forbid the option to suspend a personal certificate.
>
> On a side note about suspension... I was not active in the forums when
> this was discussed and adopted and I'm sure there was a clear benefit on
> disallowing suspensions, but it's kind of a hassle already because of the
> application of this rule to the whole hierarchy. We'd like for example to
> have the capability to suspend a subordinate CA that is under investigation
> or that is pending of an audit, but right now we can't do it... extending
> these rules to personal certificates is not something I'm personally too
> enthusiastic.
>
> Best,
> Pedro
>
> El jueves, 2 de mayo de 2019, 17:32:43 (UTC+2), Kathleen Wilson  escribió:
> > Just want to make it very clear to everyone, that the proposal, to add
> > the following text to section 6 of Mozilla's Root Store Policy would
> > mean that certs constrained to id-kp-emailProtection (end-entity and
> > intermediate), i.e. S/MIME certs, would be subject to the same BR rules
> > and revocation timelines as TLS/SSL certs.
> >
> > > This requirement applies to certificates that are not otherwise
> required
> > >> to comply with the BRs.
> >
> > For example, Section 4.9.1.1 of the BRs says:
> > ""
> > MUST revoke a Certificate within 5 days if one or more of the following
> > occurs: ...
> >
> > 1. The Certificate no longer complies with the requirements of Sections
> > 6.1.5 and 6.1.6;
> >  ...
> > 7. The CA is made aware that the Certificate was not issued in
> > accordance with these Requirements
> > ""
> >
> > I interpret "these Requirements" to mean the BRs. Therefore, my
> > interpretation of the proposed additional text is that certs that are
> > constrained to S/MIME would also have to be issued in full accordance
> > with the BRs and would have to be revoked within the timeline as
> > specified in the BRs when found to be not in full compliance with the BR
> > issuance rules.
> >
> > Section 1.1 of Mozilla's root store policy limits the scope of the
> > policy such that the proposed additional text would only specifically
> > add the rules to S/MIME certs. Certs with no EKU extension or
> > anyExtendedKeyUsage are considered technically capable of issuing TLS
> > certs, so already subject to the rules of the BRs.
> >
> > Therefore, my concern is that the proposed additional text would mean
> > that all of the BR issuance rules and revocation rules would also apply
> > to S/MIME certs. I do not think that S/MIME certs have been taken into
> > account in the BRs, so I do not think we should impose all the BR
> > issuance and revocation rules on S/MIME certs.
> >
> > 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: Certificates with subject locality "Default City"

2019-05-02 Thread Wayne Thayer via dev-security-policy
Thank you for the report Alex. The following compliance bugs have been
created:

Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1548713
SECOM: https://bugzilla.mozilla.org/show_bug.cgi?id=1548714
DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1548716

- Wayne

On Thu, May 2, 2019 at 10:16 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi all,
>
> I came across a number of certificates issued by Sectigo, SECOM, and
> DigiCert that list "Default City" as the subject's locality. Unless there
> are actually localities named "Default City" that I'm unaware of, it seems
> to me this is a violation of the BRs, sections 3.2.2.1 and 7.1.4.2.2.e.
>
> I created a batch on misissued.com for these:
> https://misissued.com/batch/51/
>
> Alex
> ___
> 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.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-05-01 Thread Wayne Thayer via dev-security-policy
On Fri, Apr 26, 2019 at 5:14 PM Wayne Thayer  wrote:

> Section 6 ("Revocation") of Mozilla's Root Store Policy states:
>
> CAs MUST revoke Certificates that they have issued upon the occurrence of
>> any event listed in the appropriate subsection of section 4.9.1 of the
>> Baseline Requirements, according to the timeline defined therein.
>>
>
> Because the BRs don't apply to intermediate and end-entity certificates
> that are constrained to S/MIME, it's not clear if our policy requires that
> those certificates follow the BR revocation requirements or not.
>
> The discussion [1] that led to the current language makes it clear that
> the intent is for the revocation requirement to apply to S/MIME
> certificates.
>
> I propose adding the following statement to clarify the scope of this
> section:
>
> This requirement applies to certificates that are not otherwise required
>> to comply with the BRs.
>
>
> This is https://github.com/mozilla/pkipolicy/issues/166 and
> https://github.com/mozilla/pkipolicy/issues/167
>
>
Kathleen pointed out that I referenced the wrong issues. The correct issues
are:

https://github.com/mozilla/pkipolicy/issues/176 and
https://github.com/mozilla/pkipolicy/issues/177

I will appreciate everyone's input on this proposal.
>
> - Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/eAy0lxgFHR8/g6Jddy40EAAJ
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-01 Thread Wayne Thayer via dev-security-policy
On Wed, May 1, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/05/2019 22:29, mono.r...@gmail.com wrote:
> >> 2017 assessment report
> >> LSTI didn't issue to Certinomis any "audit attestation" for the
> browsers in 2017. The document Wayne references is a "Conformity Assessment
> Report" for the eIDAS regulation.
> >
> > I had a look at the 2017 report, and unless I misread, it implies
> conformity to ETSI EN 319 401 (Est vérifiée également la conformité aux
> normes: EN 319 401), whereas EN 319 401 states, "The present document is
> aiming to meet the general requirements to provide trust and confidence in
> electronic
> > transactions including, amongst others, applicable requirements from
> Regulation (EU) No 910/2014 [i.2] and those from CA/Browser Forum [i.4].",
> so I'm not sure how that squares with saying it wasn't an audit taking
> CA/BF regulations into account?
> >
>

The 2017 report [1], while not an attestation letter, indicates conformance
with EN 319 411 (refer to annex 2). This is the audit that covers
compliance with the BRs and is required by Mozilla policy.

>
> But does EN 319 401, as it existed in 2016/2017 incorporate a clause to
> apply all "future" updates to the CAB/F regulations or otherwise cover
> all BRs applicable to the 2016/2017 timespan?
>
> Because otherwise EN 319 401 compliance only implied compliance with
> the subset of the BRs directly included in EN 319 401 or documents
> incorporated by reference into EN 319 401 (the above quote is a
> statement of intent to include the BR requirements that existed when
> EN 319 401 was written).
>
> That said, Mozilla policy at the time may have explicitly stated that an
> EN 319 401 audit is/was sufficient for Mozilla inclusion purposes.
>
>
Correct - 319 411 was (and still is) the Mozilla audit requirement.

[1] https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-04-26 Thread Wayne Thayer via dev-security-policy
Section 6 ("Revocation") of Mozilla's Root Store Policy states:

CAs MUST revoke Certificates that they have issued upon the occurrence of
> any event listed in the appropriate subsection of section 4.9.1 of the
> Baseline Requirements, according to the timeline defined therein.
>

Because the BRs don't apply to intermediate and end-entity certificates
that are constrained to S/MIME, it's not clear if our policy requires that
those certificates follow the BR revocation requirements or not.

The discussion [1] that led to the current language makes it clear that the
intent is for the revocation requirement to apply to S/MIME certificates.

I propose adding the following statement to clarify the scope of this
section:

This requirement applies to certificates that are not otherwise required to
> comply with the BRs.


This is https://github.com/mozilla/pkipolicy/issues/166 and
https://github.com/mozilla/pkipolicy/issues/167

I will appreciate everyone's input on this proposal.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/eAy0lxgFHR8/g6Jddy40EAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

2019-04-26 Thread Wayne Thayer via dev-security-policy
In version 2.6 of our Root Store Policy, we added the requirement to
section 5.3 that intermediate certificates contain an EKU and separate
serverAuth and emailProtection uses. Version 2.6.1 updated the requirement
to exclude cross certificates [1]. Last month, an issue [2] was filed
requesting that we add "Policy Certification Authorities" (PCAs) as another
exception.

PCAs are described in RFC 5280 as a CA certificate that is only used to
issue other CA certificates, so excluding PCAs from this requirement would
not in theory weaken it. However, I'm not aware of any way to technically
enforce that PCAs not issue end-entity certificates, and allowing more
exceptions would seem to make this policy more difficult to enforce. In
addition, RFC 5280 section 3.2 appears to reference PCAs as an example of
an architecture that should be abandoned in favor of x509v3 certificate
extensions:

   With X.509 v3, most of the requirements addressed by RFC 1422 can be
   addressed using certificate extensions, without a need to restrict
   the CA structures used.  In particular, the certificate extensions
   relating to certificate policies obviate the need for PCAs...

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

I will appreciate everyone's input on this proposal.

- Wayne

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


Policy 2.7 Proposal: CA Certificate Binding to Policy Documents

2019-04-26 Thread Wayne Thayer via dev-security-policy
The required practice "Publicly Available CP and CPS" [1] states:

The CP/CPS must clearly indicate which root and subordinate certificates
> the practices and processes described in those documents apply to.


This can be done in (at least) two ways:
* the policy document can unambiguously list the specific CA certificates
within its scope
* the CA certificate can contain one or more policy OIDs that are
referenced in the applicable policy documents

I have found that many CP/CPSes don't clearly list the certificates that
are in-scope, and the binding between policy OIDs in subordinate CA
certificates and CP/CPSes is often unclear when the CA has multiple policy
documents.

My concern is that this could lead to situations where a CA can pick and
choose policies to argue that a given certificate is compliant.

However, BR section 7.1.2.3 already requires each end-entity certificate to
include "A Policy Identifier, defined by the issuing CA, that indicates a
Certificate Policy asserting the issuing CA's adherence to and compliance
with these Requirements." I'm much more interested in compliance with the
BRs and Mozilla policy than the CA's own CPS, so this mitigates my concern.

Even though I don't think this is as important now that I've given it some
thought, I propose moving the following required practice into section 3.3
"CPs and CPSes" of our policy:

CPs and CPSes must clearly indicate which root and intermediate
> certificates the practices and processes described in those documents apply
> to.
>

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

I will appreciate everyone's input on this proposal.

- Wayne

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


Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

2019-04-26 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi  wrote:

>
> On Mon, Apr 22, 2019 at 6:20 PM Brian Smith  wrote:
>
>> There are three (that I can think of) sources of confusion:
>>
>> 1. Is there any requirement that the signature algorithm that is used to
>> sign a certificate be correlated in any way to the algorithm of the public
>> key of the signed certificate? AFAICT, the answer is "no."
>>
>> 2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA),
>> Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256,
>> SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely*
>> right in natural language, but easy to get right with a list of encodings.
>>
>> 3. Given a particular combination of algorithm, curve, and digest
>> algorithm, which encodings of that information are acceptable? For example,
>> when a a NULL parameter required and when is it optional. Again, this is
>> hard to get right in natural language, and again, listing the encodings
>> makes this trivial to get exactly right.
>>
>>  Agreed - is someone willing to take on this task?
>>>
>>
>> I could transform what I did with webpki into some text.
>>
>> However, first I think it would be useful if somebody could check that
>> the encodings that webpki expects actually match what certificates in
>> Certificate Transparency are doing. For example, does every CA already
>> encode a NULL parameter when one is required by RFC 4055 (which is included
>> by reference from RFC 5280)? Are there any algorithm combinations in use
>> that aren't in webpki's list? This is something I don't have time to
>> thoroughly check.
>>
>
> I agree with Brian here, unsurprisingly. Luckily, my colleague, David
> Benjamin, had some time to do just what Brian proposes.
>
> The following pull request - https://github.com/mozilla/pkipolicy/pull/183 -
> demonstrates an attempt to resolve those three questions highlighted by
> Brian.
>
>

Thank you David and Ryan! This appears to me to be a reasonable improvement
to our policy.

Brian: could I ask you to review the proposed change?


> This does not, however, address the last part of what Brian proposes -
> which is examining if, how many, and which CAs would fail to meet these
> encoding requirements today, either in their roots, subordinates, or leaf
> certificates.
>
>
While I agree that this would be useful information, for the purpose of
moving ahead with this policy change would it instead be reasonable to set
an effective date and require certificates issued (notBefore) after that
date to comply, putting the burden on CAs to verify their implementations
rather than relying on someone else to do that work?

While this includes RSA-PSS, it's worth noting that mozilla::pkix does not
> support these certificates, and also worth noting that the current encoding
> scheme is substantially more verbose than desirable.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-04-25 Thread Wayne Thayer via dev-security-policy
Since this is a separate, serious issue, I filed a new bug and requested an
incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1547072

I added this to the issues list as Issue G:
https://wiki.mozilla.org/CA/Certinomis_Issues

I also added a summary of the response received yesterday from Certinomis
to issue F.3: Inadequate Controls on Production Testing

On Thu, Apr 25, 2019 at 9:30 AM Ryan Sleevi  wrote:

>
> On Wed, Apr 17, 2019 at 5:22 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
>> issued by Certinomis in February 2019 containing an unregistered domain
>> name. Since the cause described in the incident report is similar, I added
>> this under issue F.1.
>>
>
> In the course of investigating this bug [1], it further appears that
> Certinomis has continued to use method 3.2.2.4.5 to validate domains,
> despite it being formally prohibited in the Baseline Requirements 8 months
> ago, in August 2018.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c8
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Ban "No Stipulation", Blank, and Missing CP/CPS sections

2019-04-23 Thread Wayne Thayer via dev-security-policy
Having received no new comments, I'll plan to include this change in policy
version 2.7.

- Wayne

On Tue, Apr 16, 2019 at 3:40 PM Wayne Thayer  wrote:

> I went ahead and added this change to the 2.7 branch:
> https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44
>
> I removed the phrase "In addition to existing rules placed on the
> structure of CPs and CPSes that comply with the CA/Browser Forum Baseline
> Requirements" because we have S/MIME-only CP/CPS' in our program that don't
> have to comply with the BRs.
>
> Given that this is already a required practice, I don't expect there to be
> any concerns from CAs with the compliance date. If there are any CAs that
> will have difficulty with this date, please explain why and what a more
> reasonable date would be.
>
> On Mon, Apr 1, 2019 at 5:18 PM Wayne Thayer  wrote:
>
>> In October we discussed the use of "No Stipulation", empty sections, and
>> blank sections in CP/CPSes. [1] The result was an update to the "Required
>> Practices" wiki page. [2] I propose moving this into policy by adding the
>> following paragraph to the bottom of section 3.3 "CPs and CPSes"
>>
>> In addition to existing rules placed on the structure of CPs and CPSes
>>> that comply with the CA/Browser Forum Baseline Requirements, and effective
>>> for versions dated after 30-September, 2019, CPs and CPSes MUST be
>>> structured according to RFC 3647 and MUST:
>>> * Include at least every section and subsection defined in RFC 3647; and,
>>> * Only use the words "*No Stipulation*" to mean that the particular
>>> document imposes no requirements related to that section; and,
>>> * Contain no sections that are blank and have no subsections.
>>>
>>
>> This is https://github.com/mozilla/pkipolicy/issues/158
>>
>> I will appreciate everyone's input on this proposal.
>>
>> - Wayne
>>
>> [1]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/Cth8n4mxxmQ/oWV_DgpNBAAJ
>> [2]
>> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-04-23 Thread Wayne Thayer via dev-security-policy
On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer  wrote:

>
> I've drafted a specific proposal for everyone's consideration:
>
>
> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>
>
Having received no new comments on this proposal, I'll consider this issue
closed and plan to include it in policy version 2.7.

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


Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-23 Thread Wayne Thayer via dev-security-policy
On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via
> dev-security-policy wrote:
> > Okay, then I propose adding the following to section 5.2 "Forbidden and
> > Required Practices":
> >
> > Effective for certificates issued on or after April 1, 2020, end-entity
> > certificates MUST include an EKU extension containing KeyPurposeId(s)
> > describing the intended usage(s) of the certificate, and the EKU
> extension
> > MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
> >
> > This does not imply that there will be technical enforcement, but also
> > doesn't rule it out.
> >
> > I will appreciate everyone's feedback on this proposal.
>
> If I may pick the absolute smallest of nits, is it "better" if the
> restriction be on certificate notBefore, rather than "issued on"?  Whilst
> that leaves certificates open to backdating, it does make it easier to
> identify misissuance.  Otherwise there could be arguments made that the
> certificate was *actually* issued before the effective date, even though
> there is no evidence that that is the case.
>
> Thanks Matt, I can see how that change makes it easier to check for
compliance.

I've added my proposal, updated per Matt's suggestion, to the 2.7 branch:

https://github.com/mozilla/pkipolicy/commit/842c9bd53e43904b160e79cb199018252fb60834

Unless there are further comments, I'll consider this issue resolved.

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


Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-19 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 17, 2019 at 5:05 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> For what it is worth I agree with Brian.
>
> I would go a bit further and say certificates need to be issued for
> explicit usages anything else produces potentially unknown behaviors.
>
> What's most important though is that any certificate that is trusted as a
> result of membership in the Mozilla root program that can technically be
> used for SSL on the public web is subject to the program requirements
> intent or not.
>
> It seems since MSFT already requires leaves to have an EKU it wouldn't be
> breaking to apply the same rule in Mozilla's program.
>
>
Okay, then I propose adding the following to section 5.2 "Forbidden and
Required Practices":

Effective for certificates issued on or after April 1, 2020, end-entity
certificates MUST include an EKU extension containing KeyPurposeId(s)
describing the intended usage(s) of the certificate, and the EKU extension
MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.

This does not imply that there will be technical enforcement, but also
doesn't rule it out.

I will appreciate everyone's feedback on this proposal.

Ryan
> On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote:
> > Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > wrote:
> >
> > > My conclusion from this discussion is that we should not add an
> explicit
> > > requirement for EKUs in end-entity certificates. I've closed the issue.
> > >
> >
> > What will happen to all the certificates without an EKU that currently
> > exist, which don't conform to the program requirements?
> >
>

Such certificates are misissued under our current policy. Nothing would
change.

> For what it's worth, I don't object to a requirement for having an
> explicit
> > EKU in certificates covered by the program. Like I said, I think every
> > certificate that is issued should be issued with a clear understanding of
> > what applications it will be used for, and having an EKU extension does
> > achieve that.
> >
> > The thing I am attempting to avoid is the implication that a missing EKU
> > implies a certificate is not subject to the program's requirements.
> >
>

Yes, that's the misunderstanding this issue is attempting to fix.

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


Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-04-19 Thread Wayne Thayer via dev-security-policy
Ryan Sleevi made the following proposal:

Issue #122 [1] previously discussed Section 8 in the context of subordinate
> CAs, with a change [2] being made to include subordinate CAs (in the
> context of Section 5.3.2) within scope of notification requirements.
>
> However, as presently worded, it's ambiguous as to whether or not Sections
> 8.1 through 8.3 also apply to subordinate CAs, or whether the only
> disclosure required is upon the initial introduction of the subordinate.
> This confusion results from language such as in Section 8.1, "or when an
> organization buys the private key of a certificate in Mozilla's root
> program", implying that private keys which transitively chain to a root
> certificate within Mozilla's program are exempt from such requirements.
>
> This ambiguity creates incentives for situations such as cross-signing CAs
> that might otherwise or have been otherwise rejected from direct inclusion
> within the Mozilla program. It further creates issues with respect to the
> supervision of audits and auditors.
>
> While it is true that the signing CA accepts the risk that an unfavorable
> verdict on the subordinate may impact the root, the cost of such a decision
> is primarily borne by Mozilla and the broader community, in that they are
> responsible for the collateral ecosystem challenges and devising
> appropriate solutions. This has been demonstrated, for example, through the
> discussion of Symantec issues [3].
>
> Because Mozilla and the community bear significant cost, especially as
> more time passes and more certificates are issued, the following changes
> are suggested:
>
>1. Align Section 8, and its subsections, with language similar to that
>of Section 3.1.2.1. That is, that the policy is applicable to a CA and all
>subordinate CAs technically capable of issuing (server or e-mail)
>certificates
>2. With respect to Section 8.1, extend the requirements of the last
>paragraph to the issuance of subordinate CA certificates. Namely, if the
>private key is in possession of an entity that is new to the Mozilla root
>program, or subject to a CP or CPS that is new to the Mozilla Root Program,
>that prior to the issuance of such a certificate, there be a public
>discussion that results in a favorable conclusion.
>
> With the current policy as written, an existing/included root CA that
> plans to exit the CA business might be prohibited (by virtue of Section
> 8.1) from selling the business or (by virtue of Section 8.3) from
> transferring the private key material. However, they are fully permitted to
> cross-certify a new 'root' and then proverbially close up shop - with no
> consideration for if their root gets removed as a consequence. These are
> the same set of concerns that led to the introduction of Section 8, but
> today exist due to the ambiguity with respect to the subsections.
>

I've proposed a fix for this issue:
https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8
It also attempts to clarify the applicability of section 8.3 as "only" when
section 8.1 and/or section 8.2 also apply.

This is https://github.com/mozilla/pkipolicy/issues/169 and
https://github.com/mozilla/pkipolicy/issues/140

I will greatly appreciate everyone's input on this topic. In particular, I
would like to hear from CAs that would be affected by the requirement for
any new subordinate CAs to go through a public discussion before issuing
certificates, with the outcome being positive or else the subordinate CA
certificate will be added to OneCRL (section 8.1).

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/122
[2]
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
[3] https://wiki.mozilla.org/CA:Symantec_Issues
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-04-18 Thread Wayne Thayer via dev-security-policy
Yesterday, Andrew Ayer reported two additional misissued certificates:

* Space in SAN, issued yesterday:
https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7
* O=Entreprise TEST, issued in January:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20

I've added these to the issues list.

On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
>
> Mozilla has decided that there is sufficient concern [1] about the
> activities and operations of the CA Certinomis to collect together a list
> of issues. That list can be found here:
> https://wiki.mozilla.org/CA/Certinomis_Issues
>
> Note that this list may expand or contract over time as issues are
> investigated further, with information either from our or our community's
> investigations or from Certinomis.
>
> We expect Certinomis to engage in a public discussion of these issues and
> give their comments and viewpoint. We also hope that our community will
> make comments, and perhaps provide additional information based on their
> own investigations.
>
> When commenting on these issues, please clearly state which issue you are
> addressing on each occasion. The issues have been given identifying letters
> and numbers to help with this.
>
> At the end of a public discussion period between Mozilla, our community,
> and Certinomis, which we hope will be no longer than a couple of weeks,
> Mozilla will move to make a decision about how to respond to these
> concerns, based on the picture which has then emerged.
>
> - Wayne
>
> [1]
> https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-04-17 Thread Wayne Thayer via dev-security-policy
Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
issued by Certinomis in February 2019 containing an unregistered domain
name. Since the cause described in the incident report is similar, I added
this under issue F.1.

On Tue, Apr 16, 2019 at 11:44 AM Wayne Thayer  wrote:

> Mozilla has decided that there is sufficient concern [1] about the
> activities and operations of the CA Certinomis to collect together a list
> of issues. That list can be found here:
> https://wiki.mozilla.org/CA/Certinomis_Issues
>
> Note that this list may expand or contract over time as issues are
> investigated further, with information either from our or our community's
> investigations or from Certinomis.
>
> We expect Certinomis to engage in a public discussion of these issues and
> give their comments and viewpoint. We also hope that our community will
> make comments, and perhaps provide additional information based on their
> own investigations.
>
> When commenting on these issues, please clearly state which issue you are
> addressing on each occasion. The issues have been given identifying letters
> and numbers to help with this.
>
> At the end of a public discussion period between Mozilla, our community,
> and Certinomis, which we hope will be no longer than a couple of weeks,
> Mozilla will move to make a decision about how to respond to these
> concerns, based on the picture which has then emerged.
>
> - Wayne
>
> [1]
> https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Ban "No Stipulation", Blank, and Missing CP/CPS sections

2019-04-16 Thread Wayne Thayer via dev-security-policy
I went ahead and added this change to the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44

I removed the phrase "In addition to existing rules placed on the structure
of CPs and CPSes that comply with the CA/Browser Forum Baseline
Requirements" because we have S/MIME-only CP/CPS' in our program that don't
have to comply with the BRs.

Given that this is already a required practice, I don't expect there to be
any concerns from CAs with the compliance date. If there are any CAs that
will have difficulty with this date, please explain why and what a more
reasonable date would be.

On Mon, Apr 1, 2019 at 5:18 PM Wayne Thayer  wrote:

> In October we discussed the use of "No Stipulation", empty sections, and
> blank sections in CP/CPSes. [1] The result was an update to the "Required
> Practices" wiki page. [2] I propose moving this into policy by adding the
> following paragraph to the bottom of section 3.3 "CPs and CPSes"
>
> In addition to existing rules placed on the structure of CPs and CPSes
>> that comply with the CA/Browser Forum Baseline Requirements, and effective
>> for versions dated after 30-September, 2019, CPs and CPSes MUST be
>> structured according to RFC 3647 and MUST:
>> * Include at least every section and subsection defined in RFC 3647; and,
>> * Only use the words "*No Stipulation*" to mean that the particular
>> document imposes no requirements related to that section; and,
>> * Contain no sections that are blank and have no subsections.
>>
>
> This is https://github.com/mozilla/pkipolicy/issues/158
>
> I will appreciate everyone's input on this proposal.
>
> - Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/Cth8n4mxxmQ/oWV_DgpNBAAJ
> [2]
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-16 Thread Wayne Thayer via dev-security-policy
My conclusion from this discussion is that we should not add an explicit
requirement for EKUs in end-entity certificates. I've closed the issue.

- Wayne

On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 16/04/2019 08:56, Tadahiko Ito wrote:
> > > On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote:
> > >
> > >> I agree the requirements are already clear. The problem is not the
> > clarity
> > >> of the requirements. Anybody can define a new EKU because EKUs are
> > listed
> > >> in the certificate by OIDs, and anybody can make up an EKU. A standard
> > >> isn't required for a new OID. Further, not agreeing on a specific EKU
> > OID
> > >> for a particular kind of usage is poor practice, and we should
> > discourage
> > >> that poor practice.
> > >>
> > >
> > > It is good that anyone can make OID, so we do not need to violate
> policy.
> > >
> > > However, I have following concerns with increasing private OIDs in the
> > world.
> > > -I think that OID should be CA’s private OID or public OID. because, in
> > the case of a CA is going to out of business, and that business was cared
> > by another CA, we would not want those two CA using same OID for
> different
> > usage.
> > > -In the other hand, CA’s private OIDs will reduce interoperability,
> > which seems to be problematic,
> > > -web browser might just ignore private OIDs, but I am not sure other
> > certificate verification applications,
> > > which is used for certificate of that private EKU OID.
> > >
> > > over all, I think we should have some kind of public OIDs, at least for
> > widely use purpose.
> > >
> > > I believe if it were used for internet, we can write Internet-Draft,
> and
> > ask OIDs on RFC3280 EKU repo.
> > > #I am planing to try that.
> > >
> >
> > The common way to create an OID is to get an OID assigned to your (CA)
> > business, either through a national standards organization or by getting
> > an "enterprise ID" from IANA.
> >
> > Then append self-chosen suffixes to subdivide your new (near infinite)
> > OID name space.  For example, if your national standards organization
> > assigned your CA the OID "9.99.999." (not actually a valid OID btw),
> > you could subdivide like this (fun example).
> >
> > 9.99.999..1  - Certificate policies
> > 9.99.999..1.1 - Your test certificates policy
> > 9.99.999..1.1.2019.3.12 - March 12, 2019 version of that policy
> > 9.99.999..1.2 - Your EV policy
> > 9.99.999..2  - EKUs
> > 9.99.999..2.1 - CA internal Database backup signatures
> > 9.99.999..2.2 - login certificates for the secure room door lock
> > 9.99.999..2.3 - Gateway certificates for custom protocol X
> > 9.99.999..3  - Custom DN elements
> > 9.99.999..3.1 - Paygrade
> > 9.99.999..4  - Certificate/CMS/CRL/OCSP extensions
> > 9.99.999..4.1 - Date and location of photo ID validation
> > 9.99.999..5  - Algorithms
> > 9.99.999..5.1 - Caesar encryption.
> > 9.99.999..5.2 - CRC8 hash
> > 9.99.999..9 - East company division
> > 9.99.999..9.99.999 - This is getting silly.
> >
> > Etc.
> >
> > A different CA would have (by the hierarchical nature of the OID system)
> > a different assigned OID such as 9.88.999. thus not overlapping.
> >
> > Thus no risk of conflicting uses unless someone breaks the basic OID
> > rules.  The actual risk (as illustrated by EV) is getting too many
> > different OIDs for the same thing.
> >
>
> I don't believe there was any confusion about that. Indeed, the message
> you're replying to already acknowledges that CAs can do exactly that.
>
> The only concern, it seems, which this message does not address at all, was
> about the desire to have a common OID used across multiple CAs for
> particular use cases, so that relying party software can trust certificates
> from multiple (different) CAs and validate the end-entity certificates as
> appropriate for that OID.
>
> I think the substance of the message being replied to was missed, and
> hopefully that clarification helps.
> ___
> 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.7 Proposal: Incident Reporting Updates

2019-04-16 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 29, 2019 at 11:59 AM Wayne Thayer  wrote:

> On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi  wrote:
>
>>
>> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer  wrote:
>>
>>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:
>>>
>>>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>>>> dev-security-policy@lists.mozilla.org> wrote:
>>>>
>>>>> **Incidents**
>>>>> > When a CA fails to comply with any requirement of this policy -
>>>>> whether it
>>>>> > be a misissuance, a procedural or operational issue, or any other
>>>>> variety
>>>>> > of non-compliance - the event is classified as an incident. At a
>>>>> minimum,
>>>>> > CAs MUST promptly report all incidents to Mozilla in the form of an
>>>>> Incident
>>>>> > Report <https://wiki.mozilla.org/CA/Responding_To_An_Incident>, and
>>>>> MUST
>>>>> > regularly update the Incident Report until the corresponding bug is
>>>>> > resolved by a Mozilla representative. In the case of misissuance, CAs
>>>>> > SHOULD cease issuance until the problem has been prevented from
>>>>> reoccurring.
>>>>>
>>>> For comparison, Microsoft's policy is
>>>> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident
>>>>
>>> Thanks for the reference. I would note that Microsoft's requirements
>>> appear to be much narrower in scope, applying to "Security Incidents" as
>>> defined in section 6. Having said that, are there specific requirements
>>> that we should consider adding to Mozilla policy?
>>>
>>
>> There are two things that stand out to me that are unclear if you meant
>> to incorporate by reference to the incident report:
>> - Whether it's a policy violation if the CA fails to disclose the
>> affected certificates, which MSFT policy explicitly requires
>>
>
> We would only want this if the certificates were disclosed publicly, and
> that seems challenging. TLS certs will, of course, be logged because of
> other UA's requirements, but for email certs CAs may not have the
> contractual right to disclose publicly. And "GDPR".
>
> - What, if any, timeframe for periodic updates. MSFT policy explicitly
>> states that MSFT shall determine the update cadence. (This may be a
>> non-issue)
>>
>> Conceptually this makes sense, but I would be interested to hear your
> thoughts on what our requirement should be? A one-size-fits-all requirement
> of something like weekly updates could be an enforcement nightmare. We
> already assume the right to set deadlines for responses, so it's not
> obvious to me what we'd want in this requirement.
>
> Additionally, in further consideration of both this proposal and the
>> highlighted difference, it's unclear whether it's intended to create a
>> hierarchy of incidents. I think the language, as worded, does - perhaps
>> inadvertantly - by mentioning misissuance vs a procedural or operational
>> issue.
>>
>> Consider, for example, a CA that determines they're copying the O field
>> directly from CSRs into the final certificates. Such certificates are
>> unquestionably misissued, but the language creates the opportunity that the
>> CA would argue it's a "procedural or operational" issue, and thus they're
>> not required to cease issuance until the problem has been prevented.
>>
>
> This language was cribbed from the wiki page: "In misussuance cases, a CA
> should almost always immediately cease issuance from the affected part of
> your PKI until you have diagnosed the source of the problem, or explain why
> this has not been done"
>
> Perhaps it shouldn't try to account for things like OCSP misconfiguration
> and only state: "CAs SHOULD cease issuance until the problem has been
> prevented from reoccurring."?
>
>

I've drafted a specific proposal for everyone's consideration:

https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb


>> One thing to consider with such a policy is whether to formalize the use
>>>> of Bugzilla to track these. In looking through incident reports that have
>>>> been filed, we see a fair distribution between the initial reporting being
>>>> on the email list vs Bugzilla. We've certainly seen Bugzilla be more useful
>>>> in tracking unacknowledged questions and responses (via the use of
>>>> Needs-Info). Would i

Certinomis Issues

2019-04-16 Thread Wayne Thayer via dev-security-policy
Mozilla has decided that there is sufficient concern [1] about the
activities and operations of the CA Certinomis to collect together a list
of issues. That list can be found here:
https://wiki.mozilla.org/CA/Certinomis_Issues

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

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

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

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

- Wayne

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


Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

2019-04-15 Thread Wayne Thayer via dev-security-policy
Unless additional feedback is posted, I will include this change as
originally proposed in version 2.7 of our policy.

- Wayne

On Fri, Mar 29, 2019 at 11:23 AM Wayne Thayer  wrote:

> On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 28/03/2019 21:52, Wayne Thayer wrote:
>> > Our current Root Store policy assigns two different meanings to the term
>> > "technically constrained":
>> > * in sections 1.1 and 3.1, it means 'limited by EKU'
>> > * in section 5.3 it means 'limited by EKU and name constraints'
>> >
>> > The BRs already define a "Technically Constrained Subordinate CA
>> > Certificate" as:
>> >
>> > A Subordinate CA certificate which uses a combination of Extended Key
>> Usage
>> >> settings and Name Constraint settings to limit the scope within which
>> the
>> >> Subordinate CA Certificate may issue Subscriber or additional
>> Subordinate
>> >> CA Certificates.
>> >>
>> >
>> > I propose aligning Mozilla policy with this definition by leaving
>> > "technically constrained" in section 5.3, and changing "technically
>> > constrained" in sections 1.1 and 3.1 to "technically capable of issuing"
>> > (language we already use in section 3.1.2). Here are the proposed
>> changes:
>> >
>> >
>> https://github.com/mozilla/pkipolicy/commit/91fe7abdc5548b4d9a56f429e04975560163ce3c
>> >
>> > This is https://github.com/mozilla/pkipolicy/issues/159
>> >
>> > I will appreciate everyone's comments on this proposal. In particular,
>> > please consider if the change from "Such technical constraints could
>> > consist of either:" to "Intermediate certificates that are not
>> considered
>> > to be technically capable will contain either:" will cause confusion.
>> >
>>
>> To further reduce confusion, perhaps change the terminology in Mozilla
>> policy to "Technically Constrained to Subscriber", meaning technically
>> constrained to only be capable of issuing for a fully validated
>> subscriber identity (validated as if some hypothetical kind of wildcard
>> EE cert).
>>
>>
> I think that "Technically Constrained to Subscriber" is more confusing and
> not necessarily accurate in the case where the Subscriber is in control of,
> but not the same as one of more of the permitted domain names, IP
> addresses, or email addresses.
>
> This of cause remains applicable to all the kinds of identities
>> recognized and regulated by the Mozilla root program, which currently
>> happens to be server domain, EV organization, and e-mail address
>> identities.
>>
>> I realize that the BR meaning may be intended to be so too, but many
>> discussions over the years have indicated confusion.
>>
>>
> Can you provide an example of the confusion that this additional change
> would help to clarify?
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.7 Proposal: Clarify Point-in-Time Audit Language

2019-04-15 Thread Wayne Thayer via dev-security-policy
I will will include this change in policy version 2.7.

- Wayne

On Wed, Mar 27, 2019 at 8:04 PM Ryan Sleevi  wrote:

> I'm not sure whether it's necessary to indicate support, but since silence
> can sometimes be ambiguously interpreted: I support these changes and
> believe they achieve the desired outcome.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Updated Revocation Best Practices

2019-04-15 Thread Wayne Thayer via dev-security-policy
Ryan - Again, thank you for the feedback, and please forgive me for the
delayed response. I've attempted to address your concerns on the wiki page
(since this isn't official policy, I'm editing the live document):

https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_An_Incident=revision=1210671=1207675

- Wayne

On Mon, Mar 18, 2019 at 12:00 PM Ryan Sleevi  wrote:

>
>
> On Sat, Mar 16, 2019 at 12:49 PM Wayne Thayer  wrote:
>
>> Ryan - Thank you for the feedback.
>>
>> On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi  wrote:
>>
>>> While I realize the thinking is with regards to the recent serial number
>>> issue, a few questions emerge:
>>>
>>> 1) Based on the software vendor reporting, they don’t view this as a
>>> software defect, but a CA misconfiguration. Do you believe the current
>>> policy, as worded, addresses that ambiguity?
>>>
>>>
>> As the language is an example, I don't believe it needs to address this
>> distinction. I intended "defect" to mean a defect in the certificate, so
>> perhaps it would help to specify that - i.e. "certificate defect"?
>>
>
> I guess the challenge is it introduces the ontology that some folks have
> advocated, but no one actually knows where the lines should be drawn, as
> every example has had flaws. That is, a "certificate defect" could be
> everything from granting basicConstraints:CA=true (e.g. as we saw with
> Turktrust [1]) due to a misconfigured certificate profile (which, like
> this, was an "off by one" error) to something like misencoded sequences [2].
>
> My biggest worry with the proposal is that it seems to actually favor not
> revoking/responding to systemic issues (those which can affect a
> significant portion of the CA's issued certificates), whereas I think the
> intent is that non-revocation should be exceptional and that the CA should
> be moving to systemically address things.
>
> I think the end-goal, for both cases, remains the same: that the CA take
> holistic steps to make revocation easier and painless, whether they're
> dealing with systemic issues (such as serial numbers or validation methods)
> or exceptional situations (such as a rogue RA or validation agent). Looking
> at Heartbleed as the example, we know that a massive number of Subscribers
> and certificates were affected - it seems like this example would have
> encouraged non-revocation, by choosing the size of impact as the
> illustrative example.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=825022
> [2]
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
>
>
>> 4) This new policy seems to explicitly allow a CA never revoking a
>>> non-compliant Certificate. Is that your intent? If so, is there any concern
>>> that this introduces the risk of CAs presenting revocation as being
>>> “required by Mozilla” as opposed to the factually correct and accurate
>>> “required by the Baseline Requirements” if Mozilla or this community should
>>> disagree with such a decision?
>>>
>>>
>> Is there any difference between delaying revocation until a certificate
>> expires and not revoking at all? Is there any difference between CAs
>> misrepresenting revocation as "being required by  Mozilla to happen by X
>> date" and "being required by Mozilla"?
>>
>
> Fair points. I think the previous policy encouraged a more concrete plan
> of action ("when"), and did not leave the CA decision making capability
> ("if") which could create a conflict between the CA's decisions and the
> community expectations. That said, you make a good point - if their "when"
> is "when the certificate expires", then it's implicitly an "if" as well,
> and that remains unless/until "when" is more prescreptive.
>
>
>> 5) If multiple CAs are affected by a common incident, this seems to
>>> encourage delaying revocation as long as possible. It’s unclear whether a
>>> CA that can and does revoke their certificates will be more or less
>>> favorably considered, both by the ecosystem and by this community. Given
>>> the economic incentives, it seems to strongly discourage revocation, as a
>>> way of competitive differentiation.
>>>
>>>
>> I'm not following how these changes have the effect of encouraging
>> multiple CAs to delay revocation as long as possible. but I do think it
>> would be useful to state that CAs who violate the BRs will always be looked
>> upon less favorably than those who do not.
>>
>
> If a given CA is faced with a systemic issue - such as serial numbers -
> then they have a decision whether to replace a majority of certificates or
> not. Independent of any analysis, there will naturally be a preference to
> not revoke "if we don't have to". Because the encouragement to post on the
> Forum, and because these discussions show that people's opinions about the
> seriousness/reasonableness of the matter is, in some way, impacted by how
> many other CAs are impacted, there's a natural incentive to delay
> revocation as much as possible (and to draw out discussions as much 

Re: Arabtec Holding public key? [Weird Digicert issued cert]

2019-04-12 Thread Wayne Thayer via dev-security-policy
Jeremy: do you consider the fact that DigiCert signed certs without proof
of private key possession to have been a violation if its CPS?

On Fri, Apr 12, 2019 at 10:04 AM Jeremy Rowley 
wrote:

> The net result were some people created private certs with our root cert
> public key. We signed new certs using that public key after verifying
> domain control. We saw the process happen a few times but didn't worry
> about it too much as the requesters didn't control the private key. We
> ended up shutting off the no-CSR path because we figured the issuance of
> these certs created a potential PR concern, even if there isn't a real
> security risk.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Friday, April 12, 2019 10:56 AM
> To: Wayne Thayer ; Jakob Bohm 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: RE: Arabtec Holding public key? [Weird Digicert issued cert]
>
> I don't mind filling in details.
>
> We have a system that permits creation of certificates without a CSR that
> works by extracting the key from an existing cert, validating the
> domain/org information, and creating a new certificate based on the
> contents of the old certificate. The system was supposed to do a handshake
> with a server hosting the existing certificate as a form of checking
> control over the private key, but that was never implemented, slated for a
> phase 2 that never came. We've since disabled that system, although we
> didn't file any incident report (for the reasons discussed so far).
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Friday, April 12, 2019 10:39 AM
> To: Jakob Bohm 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert]
>
> It's not clear that there is anything for DigiCert to respond to. Are we
> asserting that the existence of this Arabtec certificate is proof that
> DigiCert violated section 3.2.1 of their CPS?
>
> - Wayne
>
> On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 11/04/2019 04:47, Santhan Raj wrote:
> > > On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote:
> > >> On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote:
> > >>> (Resending after I typo'd the ML address)
> > >>>
> > >>> At the risk of further embarrassing myself in the same week, while
> > >>> working further on mimicking Firefox trust decisions I found this
> > >>> pre-certificate for Arabtec Holding PJSC:
> > >>>
> > >>> https://crt.sh/?id=926433948
> > >>>
> > >>> Now there's nothing especially strange about this certificate,
> > >>> except that its RSA public key is shared with several other
> > >>> certificates
> > >>>
> > >>>
> > https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2d
> > ab76254f97fb36b82fc26
> > >>>
> > >>> ... such as the DigiCert Global Root G2:
> > >>>
> > >>> https://crt.sh/?caid=5885
> > >>>
> > >>>
> > >>> I would like to understand what happened here. Maybe I have once
> > >>> again made a terrible mistake, but if not surely this means either
> > >>> that the Issuing authority was fooled into issuing for a key the
> > >>> subscriber doesn't actually have or worse, this Arabtec Holding
> > >>> outfit has the private keys for DigiCert's Global Root G2
> > >>>
> > >>> Nick.
> > >>
> > >> AFAIK there's no requirement in the BRs or Mozilla Root Policy for
> > >> CAs
> > to actually verify that the Applicant actually is in possession of the
> > corresponding private key for public keys included in CSRs (i.e.,
> > check the signature on the CSR), so the most likely explanation is
> > that the CA in question did not check the signature on the
> > Applicant-submitted CSR and summarily embedded the supplied public key
> > in the certificate (assuming Digicert's CA infrastructure wasn't
> > compromised, but I think that's highly unlikely).
> > >>
> > >> A very similar situation was brought up on the list before, but
> > >> with
> > WoSign as the issuing CA:
> > https://groups.google.com/d/msg/mozill

  1   2   3   4   5   6   >