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

[Wayne Thayer via dev-security-policy]

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

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

- Wayne


On Mon, Mar 26, 2018 at 12:59 PM, Tim Hollebeek 
wrote:

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

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

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

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

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

Thanks,

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

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Tim,

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

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

1. prepare and follow a Key Generation Script and
> 2. have a Qualified Auditor witness the Root CA Key Pair generation
> process or record a video of the entire Root CA Key Pair generation process.
>
>
If you are commenting on the word "Root" in #2, then I think this is meant
to apply to both Root and subordinate CA key pairs, so both instances of
the word "Root" should be struck.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

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

>
>
> On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer  wrote:
>
>> On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi  wrote:
>>
>>>
>>> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 When the Francisco Partners acquisition of Comodo was announced, it was
 pointed out [1] that a strict reading of the current policy section 8.1
 would have forced Comodo to stop issuing certificates for some period of
 time:

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

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

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

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

 [1]
 https://groups.google.com/d/msg/mozilla.dev.security.policy/
 AvGlsb4BAZo/gQe5ggE6BQAJ
>>>
>>>
>>> I'm having a little bit of difficulty imagining what you see the change
>>> looking like. Do you have draft text in mind, to look for possible
>>> exploitable loopholes?
>>>
>>> Here's a proposal: https://github.com/mozilla/pki
>> policy/commit/565250b9bbc16c1a4e3d4165f0171e8702b2b21d
>>
>
> Thanks, that's much easier to visualize.
>
> I think it's a positive change, but it may be worth emphasizing that a
> complete change in ownership does not otherwise exempt a CA from the other
> reporting - such as changes in operational personnel, material changes in
> the CA's operations (CP/CPS), etc. This is covered by Section 8.2 and 8
> overall, so it may not bear mentioning explicitly, or it may be worth
> noting that the receiving or acquiring company will be bound by the policy,
> in full, including any notifications of further changes.
>

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

> This section applies when one company buys or takes a controlling stake in
> a CA, or when an organization buys the private key of a certificate in
> Mozilla's root program.
>
> Mozilla MUST be notified of any resulting changes in the CA's CP or CPS.
>
> If the receiving or acquiring company is new to the Mozilla root program,
> it must comply with the entirety of this policy and there MUST be a public
> discussion regarding their admittance to the root program, which Mozilla
> must resolve with a positive conclusion in order for the affected
> certificate(s) to remain in the root program. If the entire CA operation is
> not included in the scope of the transaction, issuance is not permitted
> until the discussion has been resolved with a positive conclusion.
>
Unless there are further comments on this topic, I'll include this change
in version 2.6

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

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

[Wayne Thayer via dev-security-policy]

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

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

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

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

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

Re: Policy 2.6 Proposal: Require audits back to first issuance

[crawfordtimj--- via dev-security-policy]

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

The standard audit cycle, we normally see for a brand new CA, is as follows:

1.  Draft CP/CPS
2.  Perform RKGC, observed and reported on by auditor
3.  Point in time reporting
4.  Period of time reporting

Most CAs elect to perform a RKGC before a point in time engagement, because 
without any CA activities in place most of the WebTrust criteria would not be 
applicable at the point time of reporting.  As an example, much of the 
following sections would not be applicable:

4.0 – CA Key Lifecycle Management Controls
6.0 – Certificate Lifecycle Management  

These sections represent a substantial portion of the WebTrust Principles and 
Criteria. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audits for new subCAs

[crawfordtimj--- via dev-security-policy]

On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote:
> On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:

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

I think BR 6.1.1.1 is  a little confusing on when a root key generation 
observation report is required, because it uses the term “Root CA Key Pair” in 
a section that seems to be addressing CAs that are not root CAs. 

For other CA Key Pairs created after the Effective Date that are for the 
operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 

1. prepare and follow a Key Generation Script and 
2. have a Qualified Auditor witness the Root CA Key Pair generation process or 
record a video of the entire Root CA Key Pair generation process. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy