RE: RAs and the BRs

[Jeremy Rowley via dev-security-policy]

A reasonable control can include contractual controls, thus 6.6 is solved 
simply via contract with the CA. Section 8.7 does give some control (and I 
missed that when going through this the first time), but the audit criteria is 
only that the CA reviews a 3% sample. As long as I documented that I review the 
RA practices and did the 3% review (regardless of the results), then the CA 
escapes oversight on its validation process. 

 

 

From: Wayne Thayer  
Sent: Wednesday, April 18, 2018 1:18 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: RAs and the BRs

 

On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

BR section 1.3.2 defines a Registration Authority as a Delegated Third Party. 
Section 8.7 says:

Except for Delegated Third Parties that undergo an annual audit that meets the 
criteria specified in Section 8.1, the CA SHALL strictly control the service 
quality of Certificates issued or containing information verified by a 
Delegated Third Party by having a Validation Specialist employed by the CA 
perform ongoing quarterly audits against a randomly selected sample of at least 
the greater of one certificate or three percent of the Certificates verified by 
the Delegated Third Party in the period beginning immediately after the last 
sample was taken. The CA SHALL review each Delegated Third Party’s practices 
and procedures to ensure that the Delegated Third Party is in compliance with 
these Requirements and the relevant Certificate Policy and/or Certification 
Practice Statement. 

The CA SHALL internally audit each Delegated Third Party’s compliance with 
these Requirements on an annual basis. 

The WebTrust BR audit criteria include a number of controls related to CA 
oversight of Delegated Third Parties, including 6.6:

 

The CA maintains controls to provide reasonable assurance that the CA 
internally audits each Delegated Third Party’s compliance with the Baseline 
Requirements on an annual basis.



Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  



I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 



Jeremy 



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

Re: Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

[Wayne Thayer via dev-security-policy]

Hearing no objections, I have made the proposed clarification in the
version 2.6 branch:
https://github.com/mozilla/pkipolicy/commit/def9c711163e0cae6a19866fb551e915e3bcef12
- Wayne

On Tue, Apr 17, 2018 at 11:20 AM, Wayne Thayer  wrote:

> Section 5.3 of Mozilla policy states:
>
> All certificates that are capable of being used to issue new certificates,
>> and which directly or transitively chain to a certificate included in
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this
>> policy and MUST either be technically constrained or be publicly disclosed
>> and audited.
>>
>
> This could be interpreted as exempting technically constrained subordinate
> CA certificates from the self-audit requirements in BR section 8.1, or even
> from any BR compliance requirement. Since the original discussion of this
> issue [1] back in 2016, we have updated the scope of our policy to clearly
> include technically constrained certificates, and thus the requirement for
> BR conformance in section 2.3 does apply to these certificates. I believe
> that our current policy already resolves this issue.
>
> I propose that we further clarify the requirements for technically
> constrained certificates by adding a second sentence to the second
> paragraph of section 5.3.1 of the Mozilla policy as follows:
>
> If the certificate includes the id-kp-serverAuth extended key usage, then
>> the certificate MUST be Name Constrained as described in section 7.1.5 of
>> version 1.3 or later of the Baseline Requirements. The Baseline
>> Requirements Conformance policy, as defined in section 2.3, applies to
>> technically constrained subordinate CA certificates.
>>
>
> I would appreciate everyone's input on this topic.
>
> This is: https://github.com/mozilla/pkipolicy/issues/36
>
> [1] https://groups.google.com/d/msg/mozilla.dev.security.
> policy/ZMUjQ6xHrDA/ySofsF_PAgAJ
> ---
>
> This is a proposed update to Mozilla's root store policy for version
> 2.6. Please keep discussion in this group rather than on GitHub. Silence
> is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

To close out discussion on this issue, I've updated the change by removing
the requirement to list each subCA certificate in the CPS:
https://github.com/mozilla/pkipolicy/commit/1bdcd53baf2e8b9006a5e13923ce3d66eeff927e

- Wayne


On Mon, Apr 16, 2018 at 4:51 PM, Wayne Thayer  wrote:

> On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer  wrote:
>
>> As an alternative to requiring newly-issued subCA Certificates to be
>> listed in the relevant CP/CPS prior to issuing certificates, would it be
>> reasonable for Mozilla to require the Certificate Policies extension in
>> these certificates to contain a URL pointing to the relevant policy
>> document(s)? I believe that most subCA certificates already contain this
>> information.
>>
>> Section 7.1.2.2 of the BRs states that the certificatePolicies:
> policyQualifiers:qualifier:cPSuri for a subCA certificate should contain
> a pointer to the **root** CA's policies. If this is correct, then my
> proposal doesn't solve the problem of requiring disclosure of the policies
> that a new subordinate CA certificate is operating under.
>
> In theory, we could also permit three options - add the new subCA
>> certificate to the relevant CP/CPS, include a Certificate Policies pointer,
>> or publish an attestation, but I'd prefer a single, consistent mechanism
>> that allows a relying party to determine which policies apply.
>>
>> Based on the feedback so far, none of these options is desirable. I
> propose that we only make the change to section 5.3.2 of the Mozilla policy
> that clarifies the audit requirements for new subCA certificates, as
> follows:
>
> If the subordinate CA has a currently valid audit report at the time of
>> creation of the certificate, it MUST appear on the subordinate CA's next
>> periodic audit reports.
>>
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think you should consider an an exception Issuing CAs including Name
> Constraints. This would keep allowing root signing services for corporate
> CAs without forcing multiple CAs.
>

Thank you for the suggestion. It seems reasonable to me. If no one objects,
I will move the proposed language to section 5.3.2 so that it applies only
to unconstrained intermediates.

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

Re: Transforming a trade name into ASCII in the O field of an OV cert

[Wayne Thayer via dev-security-policy]

Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. If
this were an EV cert I would argue that it was misissued.

On Mon, Apr 23, 2018 at 12:13 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Apr 23, 2018 at 1:11 PM, Henri Sivonen via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > First, it seems to me that the Baseline Requirements allow
> > transformations of the organization's name only if the CA documents
> > such transformations. I am unable to find such documentation in
> > DigiCert's CP and CPS documents. Am I missing something?
> >
>
> At present, these are not required to be in the public documentation.
> Merely, the requirement is that the CA "documents" - i.e. it is presently
> acceptable to only include this documentation in information provided to
> the auditors.
>
>
> > Second, while verifying that the applicant indeed represents a
> > specific real organization is a difficult problem, in the case where
> > the country that the certificate designates operates an
> > online-queryable database of registered businesses, associations,
> > etc., it should be entirely feasible to eliminate the failure mode
> > where the certificate's organization field is (absent documented
> > transformations permitted under the Baseline Requirements) not
> > canonically equivalent (in the Unicode sense) to the name of any
> > organization registered in the country that the certificates
> > designates. That (inferring from the certificate for
> > www.alandsbanken.fi) there isn't technical process that would by
> > necessity remove diacritical marks from the organization field and
> > that the certificate for www.saastopankki.fi has them removed is
> > strongly suggestive that DigiCert's process for validating
> > Finland-based organization does not include as a mandatory part either
> > the retrieval of the organization's name via an online API to the
> > business registry or a human CA representative copying and pasting the
> > organization's name from a browser view to the business registry.
> >
>
> The Baseline Requirements do not dictate the datasource used in various
> jurisdictions. Thus even when there is a canonical source through
> legislation, the BRs do not require its use.
>
>
> >  I wonder: When a given country
>
> has an online-queryable business registry, why isn't it either
> > recommended or required to import names digitally from the business
> > registry into certificates? Such practice would eliminate the failure
> > mode of the certificate designating a name that doesn't match any
> > entry in the business registry for such country. (Obviously, if it was
> > _required_, the BRs would need to include a list of countries whose
> > business registry is considered online-queryable in the sense that the
> > requirement would apply, but unwillingness to maintain such a list
> > does not explain why it isn't even recommended.)
> >
>
> "Recommended" is pointless. Required is the only thing that makes sense,
> and the complexities and overhead involved precisely explain why it isn't
> required.
> ___
> 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: Transforming a trade name into ASCII in the O field of an OV cert

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 23, 2018 at 1:11 PM, Henri Sivonen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> First, it seems to me that the Baseline Requirements allow
> transformations of the organization's name only if the CA documents
> such transformations. I am unable to find such documentation in
> DigiCert's CP and CPS documents. Am I missing something?
>

At present, these are not required to be in the public documentation.
Merely, the requirement is that the CA "documents" - i.e. it is presently
acceptable to only include this documentation in information provided to
the auditors.


> Second, while verifying that the applicant indeed represents a
> specific real organization is a difficult problem, in the case where
> the country that the certificate designates operates an
> online-queryable database of registered businesses, associations,
> etc., it should be entirely feasible to eliminate the failure mode
> where the certificate's organization field is (absent documented
> transformations permitted under the Baseline Requirements) not
> canonically equivalent (in the Unicode sense) to the name of any
> organization registered in the country that the certificates
> designates. That (inferring from the certificate for
> www.alandsbanken.fi) there isn't technical process that would by
> necessity remove diacritical marks from the organization field and
> that the certificate for www.saastopankki.fi has them removed is
> strongly suggestive that DigiCert's process for validating
> Finland-based organization does not include as a mandatory part either
> the retrieval of the organization's name via an online API to the
> business registry or a human CA representative copying and pasting the
> organization's name from a browser view to the business registry.
>

The Baseline Requirements do not dictate the datasource used in various
jurisdictions. Thus even when there is a canonical source through
legislation, the BRs do not require its use.


>  I wonder: When a given country

has an online-queryable business registry, why isn't it either
> recommended or required to import names digitally from the business
> registry into certificates? Such practice would eliminate the failure
> mode of the certificate designating a name that doesn't match any
> entry in the business registry for such country. (Obviously, if it was
> _required_, the BRs would need to include a list of countries whose
> business registry is considered online-queryable in the sense that the
> requirement would apply, but unwillingness to maintain such a list
> does not explain why it isn't even recommended.)
>

"Recommended" is pointless. Required is the only thing that makes sense,
and the complexities and overhead involved precisely explain why it isn't
required.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Transforming a trade name into ASCII in the O field of an OV cert

[Henri Sivonen via dev-security-policy]

On Sun, Apr 15, 2018 at 6:47 PM, Ryan Sleevi  wrote:
>
> On Sun, Apr 15, 2018 at 9:13 AM Henri Sivonen via dev-security-policy
>  wrote:
>>
>> (Mozilla hat off.)
>>
>> After reading about the California versus Delaware thing when it comes
>> to the certificate for stripe.com, out of curiosity, I took a fresh
>> look at the ISO 3166-1 code in the EV certificates of some of the
>> banks that operate in Finland. (Result: https://www.nordea.fi/ is SE,
>> https://www.handelsbanken.fi/ is SE but https://danskebank.fi/ is FI
>> and not DK.)
>>
>> While at it, I noticed that the certificate for
>> https://www.saastopankki.fi/ is an OV cert whose O field says
>> "Saastopankkiliitto osk". However, according to
>>
>> https://tietopalvelu.ytj.fi/yritystiedot.aspx?yavain=25460=F663C7B776290379F1DAB6A4E251EE3FA727742A
>> , the trade name of the entity is "Säästöpankkiliitto osk". It also
>> has parallel trade names "Sparbanksförbundet anl" (Swedish translation
>> of the primary name) and "Savings Banks' Union Coop" (English
>> translation of the primary name) and auxiliary trade names
>> "Säästöpankkikeskus" and "Sparbankscentralen". But no
>> "Saastopankkiliitto osk".
>>
>> While I don't think there is any risk of confusion in this particular
>> case[1], I'm wondering: What in the Baseline Requirements authorizes
>> DigiCert to omit the diaereses from the trade name?
>>
>> The Baseline Requirements have this to say: "If present, the
>> subject:organizationName field MUST contain either the Subject’s name
>> or DBA as verified under Section 3.2.2.2. The CA may include
>> information in this field that differs slightly from the verified
>> name, such as common variations or abbreviations, provided that the CA
>> documents the difference and any abbreviations used are locally
>> accepted abbreviations; e.g., if the official record shows “Company
>> Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company
>> Name”."
>>
>> The variation covered by the example would have authorized the use of
>> the abbreviation "osk" had the registered name contained "osuuskunta"
>> (but it contained "osk" to begin with) or to drop "osk".
>>
>> Is it documented anywhere what transformations other than ones that
>> are analogous to transforming "Incorporated" to "Inc." (or dropping
>> it) are acceptable as differing "slightly"?
>
>
> No. It is presently up to the CA and the Auditor, if the Auditor happens to
> examine that certificate. Otherwise it’s left up to the RA and their ability
> to follow the CA’s policies - presuming they have them documented, and not
> just a blanket waiver like you cited.

Two observations:

First, it seems to me that the Baseline Requirements allow
transformations of the organization's name only if the CA documents
such transformations. I am unable to find such documentation in
DigiCert's CP and CPS documents. Am I missing something?

Second, while verifying that the applicant indeed represents a
specific real organization is a difficult problem, in the case where
the country that the certificate designates operates an
online-queryable database of registered businesses, associations,
etc., it should be entirely feasible to eliminate the failure mode
where the certificate's organization field is (absent documented
transformations permitted under the Baseline Requirements) not
canonically equivalent (in the Unicode sense) to the name of any
organization registered in the country that the certificates
designates. That (inferring from the certificate for
www.alandsbanken.fi) there isn't technical process that would by
necessity remove diacritical marks from the organization field and
that the certificate for www.saastopankki.fi has them removed is
strongly suggestive that DigiCert's process for validating
Finland-based organization does not include as a mandatory part either
the retrieval of the organization's name via an online API to the
business registry or a human CA representative copying and pasting the
organization's name from a browser view to the business registry.

While the Baseline Requirements clearly permit relying on an opinion
letter, which is vulnerable to failure modes such as the author of the
opinion letter helpfully omitting diacritical marks (perhaps assuming
that foreign systems couldn't deal with them) or the recipient of an
opinion letter failing to precisely input a name displayed on the
opinion letter into a computer system, I wonder: When a given country
has an online-queryable business registry, why isn't it either
recommended or required to import names digitally from the business
registry into certificates? Such practice would eliminate the failure
mode of the certificate designating a name that doesn't match any
entry in the business registry for such country. (Obviously, if it was
_required_, the BRs would need to include a list of countries whose
business registry is considered online-queryable in the sense that the

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

Here's the summary of the audit reminder email that was sent last 
Tuesday, while I was on Spring Break.


Kathleen

 Forwarded Message 
Subject:Summary of April 2018 Audit Reminder Emails
Date:   Tue, 17 Apr 2018 19:00:32 + (GMT)
From:   Mozilla CA Program Manager 
To: kwil...@mozilla.com 


Mozilla: Audit Reminder
Root Certificates:
   GDCA TrustAUTH R5 ROOT
Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf
Audit Statement Date: 2017-04-14
BR Audit: https://cert.webtrust.org/SealFile?seal=2232=pdf
BR Audit Statement Date: 2017-04-14
EV Audit: https://cert.webtrust.org/SealFile?seal=2233=pdf
EV Audit Statement Date: 2017-04-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SZAFIR ROOT CA2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
Audit Statement Date: 2017-04-12
BR Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
BR Audit Statement Date: 2017-04-12
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA
Standard Audit: 
https://bug1368471.bmoattachments.org/attachment.cgi?id=8872330

Audit Statement Date: 2017-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SecureSign RootCA11
Standard Audit: https://cert.webtrust.org/SealFile?seal=2251=pdf
Audit Statement Date: 2017-05-10
BR Audit: https://bug1369520.bmoattachments.org/attachment.cgi?id=8873589
BR Audit Statement Date: 2017-05-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   DigiCert Assured ID Root G3
   DigiCert High Assurance EV Root CA
   DigiCert Trusted Root G4
Standard Audit: https://cert.webtrust.org/SealFile?seal=2228=pdf
Audit Statement Date: 2017-04-13
BR Audit: https://cert.webtrust.org/SealFile?seal=2229=pdf
BR Audit Statement Date: 2017-04-13
EV Audit: https://cert.webtrust.org/SealFile?seal=2230=pdf
EV Audit Statement Date: 2017-04-13
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Trustis Limited - Trustis FPS Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Amazon Root CA 3**
   Amazon Root CA 2**
   Starfield Services Root Certificate Authority - G2**
   Amazon Root CA 1**
   Amazon Root CA 4**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://cert.webtrust.org/SealFile?seal=2217=pdf
Audit Statement Date: 2017-03-28
BR Audit: https://cert.webtrust.org/SealFile?seal=2218=pdf
BR Audit Statement Date: 2017-03-28
EV Audit: https://cert.webtrust.org/SealFile?seal=2219=pdf
EV Audit Statement Date: 2017-03-28
CA Comments: null





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