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

[ramirommunoz--- via dev-security-policy]

> * I am unable to locate a BR audit for the GCSR2016, but the websites trust
> bit has been requested. I first thought that this root was not intended for
> serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC
> CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root.
> Both roots are covered by the latest EV audit.

I have included an Auditor erratum note in 
https://bugzilla.mozilla.org/show_bug.cgi?id=986854 

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

Re: Following up on Trustico: reseller practices and accountability

[Jakob Bohm via dev-security-policy]

How about something simple like:

(Rephrase terminology etc. as necessary)

If a CA has any arrangements with any 3rd parties to act as
intermediaries between the subscriber and the CA, while not being the
party that operates the normal uses of the private key on the
subscribers behalf, the CA must ensure that any activities by such 3rd
parties and related to certificates chaining to the CA comply fully with
the applicable BR and CPS requirements applicable to the CA performing
similar activities.

Additionally, subscribers must not be forced or encouraged to have 3rd
parties operate the normal uses of the private key on the subscribers
behalf.

On 05/03/2018 20:47, Matthew Hardeman wrote:

In terms of an "opportunity" to insert regulation into the reseller
ecosystem, as Mr. Sleevi points out, there is the question of whether the
reseller is just a third party agent acting under contract by the end-user
client vs a party with a special relationship with one or more CAs and
their own end-user sales channel soliciting customers.

Ultimately, the reality is that the resellers all have interfaces offering
some level of automated processing for bulk ordering.  These resellers
aren't acting as literal extra hands on behalf of the end user.

They have specialized access to bulk ordering interfaces, generally
pursuant to a reseller contract.  They're not literally hand-entering data
as though they themselves were the end-user.

It's the existence of that relationship and access which provides an
opportunity for the community to decide "If the CA has relationships in
this nature, the CA has an affirmative duty to ensure as a condition of the
relationship that ___ (insert rules)".



On Mon, Mar 5, 2018 at 8:42 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I think it probably makes more sense to focus on sensitive key material
than non-sensitive CSRs.

As a starting point, how reasonable would it be for CAs to question their
resellers, or to disseminate additional language to add to their reseller
agreements to prohibit non-transactional/ephemeral key storage?

-- Eric

On Mon, Mar 5, 2018 at 9:15 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Considering that the Baseline Requirements explicitly acknowledge that

the

Applicant may delegate the obtaining of their certificates to a

third-party

(Applicant Representative), how would you propose that the applicant's
agents (which, in a legal sense, is the name for their employees - that

is,

those with legal authority to represent the company) and resellers?

What would stop  someone from offering a "CSR-as-a-service" in which they
generate CSRs for users, and then users take that generated CSR to the

CA?

What role are you suggesting that the CA has to play in policing 'how'

the

CSR was generated - since a CSR is-a CSR is-a CSR?

On Mon, Mar 5, 2018 at 8:26 AM, James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Currently, resellers are allowed to submit CSRs on behalf of their
customers and as we've seen this is open to abuse. Maybe it's time to

stop

this practice and restrict submission of CSRs to CA portals only.

On Mon, Mar 5, 2018 at 12:51 PM, okaphone.elektronika--- via
dev-security-policy  wrote:


On Sunday, 4 March 2018 22:44:26 UTC+1, Paul Kehrer  wrote:

On March 4, 2018 at 5:06:41 PM, Eric Mill via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:



It's also clear from the experience that rules of the road for

resellers

are unclear, and that accountability is limited. It seems possible,

or

likely, that other resellers may also be mishandling customer keys

So, what would useful next steps be to improve security and

accountability

for resellers?


As you already suggested an official communication requesting

information

from the CAs about the way their reseller networks manage

subscriber

key

material would be a good start. Eventually I think it's likely that
resellers need to be subject to some limited form of audit (maybe

as

simplistic as a PCI self-assessment questionnaire?). While that

doesn't

prevent bad behavior it would generate an evidence trail for

termination

of

relationships with incompetent/malicious actors.


I'm not sure that that would be reasonable. After all resellers can

have

resellers, and so on so where would that end? With the end user

having

to

accept a "general license agreement"? And distrusting a reseller

could

also

be difficult.

I think it will have to be/remain the responsibility of the CA to

choose

their reselllers in such a way that "not too many questions are being
asked" about them.



Of course, CAs are likely to be reluctant to share a complete list

of

their

resellers since they probably consider that competitive

information.

So,

it

would be nice if we could just make it part of the CA's audits...

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

[ramirommunoz--- via dev-security-policy]

Hi Wyne
here our answers to the ==Bad== issues we are working on the ==Meh== ones.

1 * The inclusion request references a much older CPS [3] that doesn't list the 
2016 versions of these roots or comply with current policies. I only reviewed 
the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the older roots 
that are currently included. I believe this is a compliance issue with the 
currently included AC Camerfirma roots. 

RMM -> EIDAS regulation has been an important milestone that took us to 
consider to setup a new hierarchy (2016) and writing a new CPS apart from the 
other hierarchies and CPS, even more when our final target is to distribute 
certificates only from the 2016 hierarchy. 
This request to incorporate the new 2016 roots affects only to eIDAS CPS 
(1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for the hierarchies 
(2003 and 2008).

2 * I am unable to locate a BR audit for the GCSR2016, but the websites trust 
bit has been requested. I first thought that this root was not intended for 
serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC 
CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root. Both 
roots are covered by the latest EV audit. 

RMM -> AC CAMERFIRMA GLOBAL FOR WEBSITES was audited for BR in the same way 
that was audited for EV. The absence of AC CAMERFIRMA GLOBAL FOR WEBSITES from 
the scope section of the attestation letter have been produced by a mistake, 
since this CA is detailed in Pag.32 of the same document. EV attestation letter 
follow the same model than BR. An auditor's note can be requested, if it is 
need it.

3 * Last year, Camerfirma signed a contract with StartCom as a delegated RA. 
While I don’t believe the StartCom distrust plan [2] specifically forbade this, 
it was found that Camerfirma was not performing domain validation on the OV 
certificates [4] as required by the BRs. 

RMM -> Relationship with STARCOM as a delegated RA has been finalized since 
STARCOM stopped issuing certificates.
STARCOM RA operator’s certificates are revoked from January 2018. 
Last certificate issued by STARCOM as a delegated RA was on December 2017.

4 * The BR section 2.2 requirement that “The CA SHALL publicly give effect to 
these Requirements and represent that it will adhere to the latest published 
version” is not clearly stated in the CPS. Also, the final paragraph of section 
1.2 implies that the CPS takes precedence over BR requirements. 

RMM -> This issue is already clarified in our CPS last version that will be 
publish next March.

5 * CPS section 3.1.8.2.2 displays a misunderstanding of BR section 3.2.2.8 
when it states that ‘This  last  procedure  will  not  be  necessary  if the  
certificate  issuance  uses “Certificate Transparency”  as  indicated in  the  
CABFORUM  BRs.  CA-Browser Forum BR 1.4.4.’ The BRs only exempt CAA checking 
prior to issuing the actual certificate because checking is required prior to 
issuing the corresponding pre-certificate. 

RMM -> This issue is already clarified in our CPS last version that will be 
publish next March. I was due to a misunderstanding of the BR. The procedure 
was corrected in November 2017.

6 * Camerfirma’s CAA domains are not documented in the CPS as required by BR 
section 2.2. 

RMM -> This issue is already included in our CPS last version that will be 
publish next March. AC Camerfirma use "camerfirma.com" as a CAA issuer record.

7 * Camerfirma’s BR Self Assessment states that they use BR methods 2 and 4 for 
domain validation, but the methods are not clearly documented in the CPS as 
required by Mozilla policy section 2.2(3). 

RMM -> This issue is already documented in our CPS last version that will be 
publish next March. In short, we use an email with a random value to domain 
contact that have to be sending back to the CA to prove domain control. BR 
1.5.4 (3.2.2.4.2).

8 * There are a few published, misissued, and currently unrevoked certificates 
in the CCR2016 hierarchy: 
https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01 

RMM ->  Those few (four) misissued certificates are revoked from the very 
moment we were aware of that. We are opening a bug to explain this issue.

Keep on working on ==Meh== ones 
Best regards
Ramiro






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