Re: Audits for new subCAs

[Peter Bowen via dev-security-policy]

Both :)

Having a new audit per online CA is going to be very expensive and
cause TSPs heavily limit the number of online CAs they have.
Additionally all of these would be point-in-time audits, which only
report on design of controls.  Assuming the design is consistent
between CAs, then there is no value in having additional audit
reports.

However I do think there is value in having the CA provide a statement
that the same controls will apply to the new CA and commit to
including the CA in the next audit.  Otherwise it could be over a year
before it is noted that the CA does not have adequate controls.  The
"same audit as parent" does not make sense for new CAs, as the new CA
is not included in the audit scope.  I'm sure automated audit report
processing will notice this and throw an error once it is online.

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

Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

Mozilla policy section 3.1.2.2 states:

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

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

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

---

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

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

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

[Tim Hollebeek via dev-security-policy]

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


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

Incident Report - IP Address in dNSName form

[Bruce via dev-security-policy]

Entrust issued two certificates where the IP Address was indicated in the 
dNSName form. Both certificates have been revoked. The bug has been resolved.

Details of the incident report can be found here, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1448986.


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

Policy 2.6 Proposal: Permit issuance during change in ownership

[Wayne Thayer via dev-security-policy]

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

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

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

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

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

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

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

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

Policy 2.6 Proposal: Require audits back to first issuance

[Wayne Thayer via dev-security-policy]

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

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

BR section 8.1 contains the following paragraph:

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

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

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

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

---

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

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

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

[Wayne Thayer via dev-security-policy]

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

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

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

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

---

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

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

AC Camerfirma misissued certificates automated analysis results

[juanangel.martingomez--- via dev-security-policy]

We've done an automated analysis on 2018-03-13 of TSL/SSL certificates that 
have been issued by our CAs:
- Camerfirma Corporate Server II - 2015
- Camerfirma Corporate Server - 2009
- AC CAMERFIRMA AAPP

We discovered 81 certificates that we didn't discover in our previous manual 
analyzes of crt.sh. These misissued certificates were due to the fact that we 
had incorrect implementations of TSL/SSL certificates, each of the errors was 
previously corrected.

The reasons why they are incorrect are:
- (3) cablint ERROR commonNames in BR certificates must be from SAN entries
- (1) cablint ERROR DNSName is not FQDN
- (1) cablint ERROR DNSName is not in preferred syntax
- (11) cablint ERROR Incorrectly encoded TeletexString in Certificate
- (15) cablint FATAL ASN.1 Error in X520countryName: BER decoding failed at 
octet 0: Parse error
- (30) cablint ERROR BR certificates must not contain directoryName type 
alternative name
- (18) x509lint ERROR organizationName too long
- (2) x509lint ERROR The string contains non-printable control characters

For all of these certificates, the registration process of the domains and 
organizations included in them was carried out correctly.

>From the moment they were detected, we began the process of replacing them.

There're 4 that have already expired.

We've revoked 44 of the aforementioned certificates and we are in contact with 
the rest of the subscribing organizations to proceed with their substitution, 
given that most of them are Spanish public administration bodies that offer 
public services and they are unable to replace them in an agile way.

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

We've implemented at 2018-02-14 a technical control that prevents the issuance 
of a TSL/SSL certificate in case cablint or x509lint show an error of type 
'FATAL' or 'ERROR' so it is expected that there are no new certificates with 
these errors issued by 'Camerfirma Corporate Server II - 2015'. 'AC CAMERFIRMA 
AAPP' & 'Camerfirma Corporate Server - 2009' are disabled for the issuance of 
certificates in our system.

A report with the detected certificates is avaliable at: 
https://bugzilla.mozilla.org/attachment.cgi?id=8962396

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

Re: Audits for new subCAs

[Wayne Thayer via dev-security-policy]

Peter,

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

On Fri, Mar 23, 2018 at 6:18 PM, Peter Bowen  wrote:

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