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

[Wayne Thayer via dev-security-policy]

Thanks everyone for your input. This discussion has reached the conclusion
that Mozilla should deny the inclusion request for the AC Camerfirma
CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT -
2016

As suggested, AC Camerfirma is welcome to submit a new inclusion request
for a newly generated root using a new key pair.

- 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

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

El miércoles, 4 de abril de 2018, 4:10:16 (UTC+2), Matt Palmer  escribió:
> On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via 
> dev-security-policy wrote:
> > Completely agree with you about that a new root by itself do not solve the 
> > problem.
> 
> The phrase you're looking for is "necessary but not sufficient".  That is,
> it is necessary to create new roots to restore trust, but not sufficient to
> do so.  You also have to demonstrate a high degree of competence in running
> a CA, and understanding and responding to legitimate concerns.
> 
> > The issue now is choosing the starting point.
> > 
> > 1.- New root 2018
> > 
> > 2.- 2016 root, after revoke all certificates (< 100 units) and pass an
> > "Point in Time" BR compliant audit.  (Camerfirma proposal)
> 
> The problem with the 2016 roots is that there is no way to rehabilitate them
> to the point that they will be as worthy of trust as new, fresh roots, for
> several reasons.
> 
> Firstly, revocation is "fail open".  Not every relying party checks
> revocation information, and when the checks are made but they fail, it is
> *usually* OK to continue, so user agents do so.
> 
> Revocation is the ejection seat of PKI.  It's the option of last resort when
> everything else has gone to hell, and you can only hope it does the job. 
> You don't build a crappy fighter aircraft whose wings fall off periodically,
> and then justify it by saying "oh, it's OK, it's got an ejection seat".  No,
> you build the best 'plane you can, and you add the ejection seat as the
> "well, it's *slightly* better than nothing" final option.  Because they hurt
> to use.  A lot.  And for various reasons they don't always work quite right. 
> But they give you a better chance of survival than a crash.
> 
> However, back to the point at hand: even if revocation were 100% reliable,
> there's still the possibility of incomplete enumeration of certificates.  I
> cannot think of a way you could possibly prove that there is zero chance of
> there being undisclosed certificates chaining to the old roots.  New roots,
> on the other hand, have that zero chance, because they're new, and have been
> under effective audited control since day zero.  So, again, new roots would
> be more trustworthy than the old roots.
> 
> - Matt

Thanks for your comments Matt

Regards
Ramiro
___
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

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

El martes, 3 de abril de 2018, 23:48:32 (UTC+2), okaphone.e...@gmail.com  
escribió:
> On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com  wrote:
> > El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com  
> > escribió:
> > > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com 
> > > > > wrote:
> > > > > > I fully understand the proposed solution about 2018 roots but as I 
> > > > > > previously said some concerns arise, [...]
> > > > > 
> > > > > 
> > > > > That is unfortunate for Camerfirma, but it is not Mozilla or this 
> > > > > lists issue. While people have provided some suggestions on how you 
> > > > > can create a root that *might* be acceptable, I don't think any of 
> > > > > the participants care if Camerfirma has a root accepted; given the 
> > > > > issues previously identified and the responses to those issues, I 
> > > > > think a number of participants would be just as happy if Camerfirma 
> > > > > doesn't get accepted.
> > > > > 
> > > > 
> > > > Hi Tom
> > > > I'm just trying to provide a different scenario than create a new root. 
> > > > Sure that many participants do not care about our particular 
> > > > situation:-(, but this make a big difference for us and also for our 
> > > > customers. If the only way to going forward is to create a new root, we 
> > > > will do it, but our obligation is trying to provide a more convenient 
> > > > solution for Camerfirma without jeopardize the trustworthiness of the 
> > > > ecosystem.
> > > 
> > > Creating a new root by itself will not solve anything. The problem you 
> > > have is with trust. It's up to you to offer a root that can be used as a 
> > > trust anchor. Reasons why the 2016 root has become unsuitable for this 
> > > have been discussed in detail.
> > > 
> > > The way out can be creating a new root, but that makes only sense if/when 
> > > you are sure all problems have been solved and will not happen with the 
> > > certificates that would be issued from this new root. If you are not 100% 
> > > sure about this, the new root will most likely soon become as useless 
> > > (for thrust) as the old one. Please don't do it before you are ready.
> > > 
> > > CU Hans
> > 
> > Thank Hans for your comments.
> > 
> > Completely agree with you about that a new root by itself do not solve the 
> > problem.
> > 
> > We have been working on those aspect detected by Wayne at the beginning of 
> > this thread. CPS issues, CAA issues..etc. So we think we are now ready to 
> > keep on with the root inclusion. Are we 100% sure ?, No one can assure that 
> > of their own systems, but we have placed controls to avoid the known 
> > problems, and detect the unknown ones.
> > 
> > The issue now is choosing the starting point.
> > 
> > 1.- New root 2018
> > 
> > 2.- 2016 root, after revoke all certificates (< 100 units) and pass an 
> > "Point in Time" BR compliant audit. (Camerfirma proposal)
> > 
> > 3.- We have send two root to the inclusion process. "Chambers of commerce 
> > root 2016", this is the root which has issue a few(4) missunsed 
> > certificates 
> > https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-01-01, all of 
> > them revoked. But we have sent "Chambersign Global Root 2016" as well, and 
> > this root is free of issuing errors.
> > 
> > Our claim to the community is to use as starting point option 2 or option 3.
> 
> You still don't seem to understand. This is not about hoops you need to jump 
> through to get your root included. It is about trust and it is entirely up to 
> you to do whatever is needed to (re)gain that.
> 
> You won't get any "requirements" other than the ones you already know all 
> about. Some people here may offer you advice they think will help you move 
> forward with this. But if that doesn't suit you for one reason or another 
> then that is just your choice, no problem. And if you do choose to follow 
> somebody's advice, that doesn't imply your root will be included. It's just 
> what they think is your best option. But as I said, creating a new root won't 
> help you one bit if the problems have not been solved in a way that makes 
> sure they won't happen again. Or if further problems will surface.
> 
> The bottom line is nothing more and nothing less than making it sufficiently 
> plausible as a CA that the root you would like to see included is (and will 
> stay) a suitable trust anchor. How you want to do that is your decision. The 
> community will and can not make that decision for you. All they have for you 
> is feedback (see above).
> 
> (Actually I have no idea why I'm telling you all this. You should already 
> understand it as a CA. Anyway, just trying to help... ;-)
> 
> CU Hans

Thanks for you help Hans

Regards
Ramiro
___
dev-security-policy ma

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

[Matt Palmer via dev-security-policy]

On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via 
dev-security-policy wrote:
> Completely agree with you about that a new root by itself do not solve the 
> problem.

The phrase you're looking for is "necessary but not sufficient".  That is,
it is necessary to create new roots to restore trust, but not sufficient to
do so.  You also have to demonstrate a high degree of competence in running
a CA, and understanding and responding to legitimate concerns.

> The issue now is choosing the starting point.
> 
> 1.- New root 2018
> 
> 2.- 2016 root, after revoke all certificates (< 100 units) and pass an
> "Point in Time" BR compliant audit.  (Camerfirma proposal)

The problem with the 2016 roots is that there is no way to rehabilitate them
to the point that they will be as worthy of trust as new, fresh roots, for
several reasons.

Firstly, revocation is "fail open".  Not every relying party checks
revocation information, and when the checks are made but they fail, it is
*usually* OK to continue, so user agents do so.

Revocation is the ejection seat of PKI.  It's the option of last resort when
everything else has gone to hell, and you can only hope it does the job. 
You don't build a crappy fighter aircraft whose wings fall off periodically,
and then justify it by saying "oh, it's OK, it's got an ejection seat".  No,
you build the best 'plane you can, and you add the ejection seat as the
"well, it's *slightly* better than nothing" final option.  Because they hurt
to use.  A lot.  And for various reasons they don't always work quite right. 
But they give you a better chance of survival than a crash.

However, back to the point at hand: even if revocation were 100% reliable,
there's still the possibility of incomplete enumeration of certificates.  I
cannot think of a way you could possibly prove that there is zero chance of
there being undisclosed certificates chaining to the old roots.  New roots,
on the other hand, have that zero chance, because they're new, and have been
under effective audited control since day zero.  So, again, new roots would
be more trustworthy than the old roots.

- Matt

___
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

[okaphone.elektronika--- via dev-security-policy]

On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com  wrote:
> El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com  
> escribió:
> > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > > > I fully understand the proposed solution about 2018 roots but as I 
> > > > > previously said some concerns arise, [...]
> > > > 
> > > > 
> > > > That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> > > > issue. While people have provided some suggestions on how you can 
> > > > create a root that *might* be acceptable, I don't think any of the 
> > > > participants care if Camerfirma has a root accepted; given the issues 
> > > > previously identified and the responses to those issues, I think a 
> > > > number of participants would be just as happy if Camerfirma doesn't get 
> > > > accepted.
> > > > 
> > > 
> > > Hi Tom
> > > I'm just trying to provide a different scenario than create a new root. 
> > > Sure that many participants do not care about our particular 
> > > situation:-(, but this make a big difference for us and also for our 
> > > customers. If the only way to going forward is to create a new root, we 
> > > will do it, but our obligation is trying to provide a more convenient 
> > > solution for Camerfirma without jeopardize the trustworthiness of the 
> > > ecosystem.
> > 
> > Creating a new root by itself will not solve anything. The problem you have 
> > is with trust. It's up to you to offer a root that can be used as a trust 
> > anchor. Reasons why the 2016 root has become unsuitable for this have been 
> > discussed in detail.
> > 
> > The way out can be creating a new root, but that makes only sense if/when 
> > you are sure all problems have been solved and will not happen with the 
> > certificates that would be issued from this new root. If you are not 100% 
> > sure about this, the new root will most likely soon become as useless (for 
> > thrust) as the old one. Please don't do it before you are ready.
> > 
> > CU Hans
> 
> Thank Hans for your comments.
> 
> Completely agree with you about that a new root by itself do not solve the 
> problem.
> 
> We have been working on those aspect detected by Wayne at the beginning of 
> this thread. CPS issues, CAA issues..etc. So we think we are now ready to 
> keep on with the root inclusion. Are we 100% sure ?, No one can assure that 
> of their own systems, but we have placed controls to avoid the known 
> problems, and detect the unknown ones.
> 
> The issue now is choosing the starting point.
> 
> 1.- New root 2018
> 
> 2.- 2016 root, after revoke all certificates (< 100 units) and pass an "Point 
> in Time" BR compliant audit. (Camerfirma proposal)
> 
> 3.- We have send two root to the inclusion process. "Chambers of commerce 
> root 2016", this is the root which has issue a few(4) missunsed certificates 
> https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-01-01, all of them 
> revoked. But we have sent "Chambersign Global Root 2016" as well, and this 
> root is free of issuing errors.
> 
> Our claim to the community is to use as starting point option 2 or option 3.

You still don't seem to understand. This is not about hoops you need to jump 
through to get your root included. It is about trust and it is entirely up to 
you to do whatever is needed to (re)gain that.

You won't get any "requirements" other than the ones you already know all 
about. Some people here may offer you advice they think will help you move 
forward with this. But if that doesn't suit you for one reason or another then 
that is just your choice, no problem. And if you do choose to follow somebody's 
advice, that doesn't imply your root will be included. It's just what they 
think is your best option. But as I said, creating a new root won't help you 
one bit if the problems have not been solved in a way that makes sure they 
won't happen again. Or if further problems will surface.

The bottom line is nothing more and nothing less than making it sufficiently 
plausible as a CA that the root you would like to see included is (and will 
stay) a suitable trust anchor. How you want to do that is your decision. The 
community will and can not make that decision for you. All they have for you is 
feedback (see above).

(Actually I have no idea why I'm telling you all this. You should already 
understand it as a CA. Anyway, just trying to help... ;-)

CU Hans
___
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

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 3, 2018 at 8:19 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com
> escribió:
> > On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com
> wrote:
> > > > > I fully understand the proposed solution about 2018 roots but as I
> previously said some concerns arise, [...]
> > > >
> > > >
> > > > That is unfortunate for Camerfirma, but it is not Mozilla or this
> lists issue. While people have provided some suggestions on how you can
> create a root that *might* be acceptable, I don't think any of the
> participants care if Camerfirma has a root accepted; given the issues
> previously identified and the responses to those issues, I think a number
> of participants would be just as happy if Camerfirma doesn't get accepted.
> > > >
> > >
> > > Hi Tom
> > > I'm just trying to provide a different scenario than create a new
> root. Sure that many participants do not care about our particular
> situation:-(, but this make a big difference for us and also for our
> customers. If the only way to going forward is to create a new root, we
> will do it, but our obligation is trying to provide a more convenient
> solution for Camerfirma without jeopardize the trustworthiness of the
> ecosystem.
> >
> > Creating a new root by itself will not solve anything. The problem you
> have is with trust. It's up to you to offer a root that can be used as a
> trust anchor. Reasons why the 2016 root has become unsuitable for this have
> been discussed in detail.
> >
> > The way out can be creating a new root, but that makes only sense
> if/when you are sure all problems have been solved and will not happen with
> the certificates that would be issued from this new root. If you are not
> 100% sure about this, the new root will most likely soon become as useless
> (for thrust) as the old one. Please don't do it before you are ready.
> >
> > CU Hans
>
> Thank Hans for your comments.
>
> Completely agree with you about that a new root by itself do not solve the
> problem.
>
> We have been working on those aspect detected by Wayne at the beginning of
> this thread. CPS issues, CAA issues..etc. So we think we are now ready to
> keep on with the root inclusion. Are we 100% sure ?, No one can assure that
> of their own systems, but we have placed controls to avoid the known
> problems, and detect the unknown ones.
>
> The issue now is choosing the starting point.
>
> 1.- New root 2018
>
> 2.- 2016 root, after revoke all certificates (< 100 units) and pass an
> "Point in Time" BR compliant audit. (Camerfirma proposal)
>
> 3.- We have send two root to the inclusion process. "Chambers of commerce
> root 2016", this is the root which has issue a few(4) missunsed
> certificates https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-
> 01-01, all of them revoked. But we have sent "Chambersign Global Root
> 2016" as well, and this root is free of issuing errors.
>
> Our claim to the community is to use as starting point option 2 or option
> 3.
>

Ramiro,

I don't think option 2 or option 3 really meaningfully address the concerns
being raised here. It's unclear if you don't understand those concerns, or
whether you disagree with those concerns. A root that has not operated
according to expected policy fundamentally is not a good starting point for
trust - there will always be a cloud of suspicion over it, that on a
technical level cannot be ameliorated. In that regard, Option 1 is the only
option that provides a meaningful starting point for trust going forward.
___
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

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

El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com  
escribió:
> On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > > I fully understand the proposed solution about 2018 roots but as I 
> > > > previously said some concerns arise, [...]
> > > 
> > > 
> > > That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> > > issue. While people have provided some suggestions on how you can create 
> > > a root that *might* be acceptable, I don't think any of the participants 
> > > care if Camerfirma has a root accepted; given the issues previously 
> > > identified and the responses to those issues, I think a number of 
> > > participants would be just as happy if Camerfirma doesn't get accepted.
> > > 
> > 
> > Hi Tom
> > I'm just trying to provide a different scenario than create a new root. 
> > Sure that many participants do not care about our particular situation:-(, 
> > but this make a big difference for us and also for our customers. If the 
> > only way to going forward is to create a new root, we will do it, but our 
> > obligation is trying to provide a more convenient solution for Camerfirma 
> > without jeopardize the trustworthiness of the ecosystem.
> 
> Creating a new root by itself will not solve anything. The problem you have 
> is with trust. It's up to you to offer a root that can be used as a trust 
> anchor. Reasons why the 2016 root has become unsuitable for this have been 
> discussed in detail.
> 
> The way out can be creating a new root, but that makes only sense if/when you 
> are sure all problems have been solved and will not happen with the 
> certificates that would be issued from this new root. If you are not 100% 
> sure about this, the new root will most likely soon become as useless (for 
> thrust) as the old one. Please don't do it before you are ready.
> 
> CU Hans

Thank Hans for your comments.

Completely agree with you about that a new root by itself do not solve the 
problem.

We have been working on those aspect detected by Wayne at the beginning of this 
thread. CPS issues, CAA issues..etc. So we think we are now ready to keep on 
with the root inclusion. Are we 100% sure ?, No one can assure that of their 
own systems, but we have placed controls to avoid the known problems, and 
detect the unknown ones.

The issue now is choosing the starting point.

1.- New root 2018

2.- 2016 root, after revoke all certificates (< 100 units) and pass an "Point 
in Time" BR compliant audit. (Camerfirma proposal)

3.- We have send two root to the inclusion process. "Chambers of commerce root 
2016", this is the root which has issue a few(4) missunsed certificates 
https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-01-01, all of them 
revoked. But we have sent "Chambersign Global Root 2016" as well, and this root 
is free of issuing errors.

Our claim to the community is to use as starting point option 2 or option 3.

Best Regards
Ramiro
___
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

[okaphone.elektronika--- via dev-security-policy]

On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com  wrote:
> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > I fully understand the proposed solution about 2018 roots but as I 
> > > previously said some concerns arise, [...]
> > 
> > 
> > That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> > issue. While people have provided some suggestions on how you can create a 
> > root that *might* be acceptable, I don't think any of the participants care 
> > if Camerfirma has a root accepted; given the issues previously identified 
> > and the responses to those issues, I think a number of participants would 
> > be just as happy if Camerfirma doesn't get accepted.
> > 
> 
> Hi Tom
> I'm just trying to provide a different scenario than create a new root. Sure 
> that many participants do not care about our particular situation:-(, but 
> this make a big difference for us and also for our customers. If the only way 
> to going forward is to create a new root, we will do it, but our obligation 
> is trying to provide a more convenient solution for Camerfirma without 
> jeopardize the trustworthiness of the ecosystem.

Creating a new root by itself will not solve anything. The problem you have is 
with trust. It's up to you to offer a root that can be used as a trust anchor. 
Reasons why the 2016 root has become unsuitable for this have been discussed in 
detail.

The way out can be creating a new root, but that makes only sense if/when you 
are sure all problems have been solved and will not happen with the 
certificates that would be issued from this new root. If you are not 100% sure 
about this, the new root will most likely soon become as useless (for thrust) 
as the old one. Please don't do it before you are ready.

CU Hans
___
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

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

El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > I fully understand the proposed solution about 2018 roots but as I 
> > previously said some concerns arise, [...]
> 
> 
> That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> issue. While people have provided some suggestions on how you can create a 
> root that *might* be acceptable, I don't think any of the participants care 
> if Camerfirma has a root accepted; given the issues previously identified and 
> the responses to those issues, I think a number of participants would be just 
> as happy if Camerfirma doesn't get accepted.
> 

Hi Tom
I'm just trying to provide a different scenario than create a new root. Sure 
that many participants do not care about our particular situation:-(, but this 
make a big difference for us and also for our customers. If the only way to 
going forward is to create a new root, we will do it, but our obligation is 
trying to provide a more convenient solution for Camerfirma without jeopardize 
the trustworthiness of the ecosystem.

> > 
> > [...] A complete revocation of any SSL certificate issued by 2016 root [...]
> 
> There are at least a couple of problems with this
> 1. Revocation, while a useful tool to have, there are a number of issues 
> surrounding it, including distribution of those revocations. Given that the 
> root isn't currently trusted it doesn't make sense for Mozilla to start 
> trusting it but also need to ship a bunch of revocations for mis-issued 
> certificates from it.

I do know fully understand your comment. We would like to start from the 
beginning with this SubCA linked to the 2016 Root.  We are talking about one 
hundred or less certificates. This SubCA is already placed in the EUTL that’s 
why we insist in this solution.

> 2. Given the issues that have already occured with this root, there is going 
> to be questions of whether all the certificates that it has issued are 
> properly recorded, so that they can now be revoked. 

No problems are open with those certificates. They are all disclosed and CT 
logged.

> That is, given the existing issues, how can Mozilla be confident that all the 
> certificates will be revoked. This is not a question of willingness, but 
> rather capability to identify and revoke all the certificates signed by this 
> root.
> 
We offer an external “point in time” BR audit to prove that this situation has 
been reached.

> -- Tom

BR
Ramiro

___
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

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 2, 2018 at 11:02 AM, Julian Inza via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > I fully understand the proposed solution about 2018 roots but as I
> previously said some concerns arise, [...]
> >
> >
> > That is unfortunate for Camerfirma, but it is not Mozilla or this lists
> issue. While people have provided some suggestions on how you can create a
> root that *might* be acceptable, I don't think any of the participants care
> if Camerfirma has a root accepted; given the issues previously identified
> and the responses to those issues, I think a number of participants would
> be just as happy if Camerfirma doesn't get accepted.
> >
> > >
> > > [...] A complete revocation of any SSL certificate issued by 2016 root
> [...]
> >
> > There are at least a couple of problems with this
> > 1. Revocation, while a useful tool to have, there are a number of issues
> surrounding it, including distribution of those revocations. Given that the
> root isn't currently trusted it doesn't make sense for Mozilla to start
> trusting it but also need to ship a bunch of revocations for mis-issued
> certificates from it.
> > 2. Given the issues that have already occured with this root, there is
> going to be questions of whether all the certificates that it has issued
> are properly recorded, so that they can now be revoked. That is, given the
> existing issues, how can Mozilla be confident that all the certificates
> will be revoked. This is not a question of willingness, but rather
> capability to identify and revoke all the certificates signed by this root.
> >
> > -- Tom
>
> I think the Camerfirma proposed solution is as acceptable as a new root
> with cross certification.
>
> At the end, you trust on that specific CA either directly or through the
> cross certification mechanism.
>
> Cross certification generates several problems for environments not based
> in browsers.
>

Such as?


>
> EU TSL (Trusted Service Status List) has been already been issued (this
> means the approval of a Supervisory Body). See also
> http://tlbrowser.tsl.website/tools/


I fail to see the issue here. Does the EU TSL prevent the issuance of
intermediates? If not, then this is an entirely irrelevant point.


> Confomity Assessment Bodies audits have been carried out.
>
> Shorter hierarchies are better maintained and generate less problems.
>

I see nothing to support the claim that shorter hierarchies are better
maintained or generate less problems. The entire hierarchy is relevant to
trust, and if there is a question about a part of the hierarchy (for
example, the 2016 root), then it's necessary to excise those parts that are
problematic, to ensure a reliable starting point.


> At the end we are dealing about how security and operational meassures are
> taken by a CA and how to demonstrate them to those with the power to
> withdraw the CA from a Trusted List.
>
> These past years european legislation regarding qualified trust services
> has evolved to define the European Regulation UE 910/2014 (also known as
> EIDAS). With that unbrella, several technical standards have been
> published, among them EN 319 412 and EN 319 411. Those standards include
> requirements from "CAB Forum Baseline Requirements Documents" and "Extended
> Validation SSL Certificate Guidelines". Withs those standards, Conformity
> Assessment Bodies (CABs) audit certification authorities. CABs also are
> audited by National Accreditation Bodies and their Assessment Reports are
> analyzed by National Supervisory Bodies, which in turn can request
> additional inofmation before approving the qualified status and including
> the CA in the TSL.
>
> This appears as an European-American confrontation.
>

I don't think this is a particularly useful framing. Indeed, it sets an
unnecessary framing when, as others have pointed out, this approach has
been consistently applied to both WebTrust and ETSI audited CAs.


> Of course, any service can be improved, and Mozilla rules for CA inclusion
> in the Mozilla root program conforms a consistent verification framework.
>
> But at the end, CABs also perform their duty harmonizing requirements from
> ETSI standards and CAB Forum requirements, to assess Certification
> Authorities which not only issue SSL certificates, but also natural person
> certificates for qualified electronic signatures, legal person certificates
> for qualified electronic seals, qualified electronic tiestamping, and other
> rlated trust services.
>
> So, one of the critical poits would be to identify what CABs are not doing
> well when assessing CAs.
>
> Because once CABs issue their Conformity Assessment Report stating thay
> some specific CA is complying with all requirements, the problem is not in
> the CA, is in the CAB.
>
> Sorry for this long description of the European P

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

[Julian Inza via dev-security-policy]

El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince  escribió:
> On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > I fully understand the proposed solution about 2018 roots but as I 
> > previously said some concerns arise, [...]
> 
> 
> That is unfortunate for Camerfirma, but it is not Mozilla or this lists 
> issue. While people have provided some suggestions on how you can create a 
> root that *might* be acceptable, I don't think any of the participants care 
> if Camerfirma has a root accepted; given the issues previously identified and 
> the responses to those issues, I think a number of participants would be just 
> as happy if Camerfirma doesn't get accepted.
> 
> > 
> > [...] A complete revocation of any SSL certificate issued by 2016 root [...]
> 
> There are at least a couple of problems with this
> 1. Revocation, while a useful tool to have, there are a number of issues 
> surrounding it, including distribution of those revocations. Given that the 
> root isn't currently trusted it doesn't make sense for Mozilla to start 
> trusting it but also need to ship a bunch of revocations for mis-issued 
> certificates from it.
> 2. Given the issues that have already occured with this root, there is going 
> to be questions of whether all the certificates that it has issued are 
> properly recorded, so that they can now be revoked. That is, given the 
> existing issues, how can Mozilla be confident that all the certificates will 
> be revoked. This is not a question of willingness, but rather capability to 
> identify and revoke all the certificates signed by this root.
> 
> -- Tom

I think the Camerfirma proposed solution is as acceptable as a new root with 
cross certification.

At the end, you trust on that specific CA either directly or through the cross 
certification mechanism.

Cross certification generates several problems for environments not based in 
browsers.

EU TSL (Trusted Service Status List) has been already been issued (this means 
the approval of a Supervisory Body). See also 
http://tlbrowser.tsl.website/tools/

Confomity Assessment Bodies audits have been carried out.

Shorter hierarchies are better maintained and generate less problems.

At the end we are dealing about how security and operational meassures are 
taken by a CA and how to demonstrate them to those with the power to withdraw 
the CA from a Trusted List.

These past years european legislation regarding qualified trust services has 
evolved to define the European Regulation UE 910/2014 (also known as EIDAS). 
With that unbrella, several technical standards have been published, among them 
EN 319 412 and EN 319 411. Those standards include requirements from "CAB Forum 
Baseline Requirements Documents" and "Extended Validation SSL Certificate 
Guidelines". Withs those standards, Conformity Assessment Bodies (CABs) audit 
certification authorities. CABs also are audited by National Accreditation 
Bodies and their Assessment Reports are analyzed by National Supervisory 
Bodies, which in turn can request additional inofmation before approving the 
qualified status and including the CA in the TSL.

This appears as an European-American confrontation.

Of course, any service can be improved, and Mozilla rules for CA inclusion in 
the Mozilla root program conforms a consistent verification framework.

But at the end, CABs also perform their duty harmonizing requirements from ETSI 
standards and CAB Forum requirements, to assess Certification Authorities which 
not only issue SSL certificates, but also natural person certificates for 
qualified electronic signatures, legal person certificates for qualified 
electronic seals, qualified electronic tiestamping, and other rlated trust 
services.

So, one of the critical poits would be to identify what CABs are not doing well 
when assessing CAs.

Because once CABs issue their Conformity Assessment Report stating thay some 
specific CA is complying with all requirements, the problem is not in the CA, 
is in the CAB.

Sorry for this long description of the European PKI Assessment model, but I 
thought it could be useful.

Best regards

Julián Inza
___
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

[Tom Prince via dev-security-policy]

On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> I fully understand the proposed solution about 2018 roots but as I previously 
> said some concerns arise, [...]


That is unfortunate for Camerfirma, but it is not Mozilla or this lists issue. 
While people have provided some suggestions on how you can create a root that 
*might* be acceptable, I don't think any of the participants care if Camerfirma 
has a root accepted; given the issues previously identified and the responses 
to those issues, I think a number of participants would be just as happy if 
Camerfirma doesn't get accepted.

> 
> [...] A complete revocation of any SSL certificate issued by 2016 root [...]

There are at least a couple of problems with this
1. Revocation, while a useful tool to have, there are a number of issues 
surrounding it, including distribution of those revocations. Given that the 
root isn't currently trusted it doesn't make sense for Mozilla to start 
trusting it but also need to ship a bunch of revocations for mis-issued 
certificates from it.
2. Given the issues that have already occured with this root, there is going to 
be questions of whether all the certificates that it has issued are properly 
recorded, so that they can now be revoked. That is, given the existing issues, 
how can Mozilla be confident that all the certificates will be revoked. This is 
not a question of willingness, but rather capability to identify and revoke all 
the certificates signed by this root.

-- Tom
___
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

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

El domingo, 1 de abril de 2018, 16:29:08 (UTC+2), westm...@gmail.com  escribió:
> Hi, Ramiro.
> But how will the problems persecuting your CA disappear, even if the root is 
> sterile.
> 
> Andrew

Thank you Andrew for your comment.

We have already solve the problems located in this bug, and develop the 
technical controls that will avoid to be replicated in the future.

Our proposal is:

Revoke all certificates issued under this root. This is not strictly necessary 
since all live certificates under this root are correctly issued.
 
Provide a "point in time" BR audit to prove to the community that all control 
are placed to avoid new misissued certificates, and that this root fulfill BR 
requirement.

Finally starting to issue new certificates.

IOHO these actions can avoid to start a new root from the scratch. 

I do know if this answer your question. 

BR
Ramiro
___
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

[westmail24--- via dev-security-policy]

Hi, Ramiro.
But how will the problems persecuting your CA disappear, even if the root is 
sterile.

Andrew
___
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

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

El viernes, 30 de marzo de 2018, 17:06:35 (UTC+2), Wayne Thayer  escribió:
> 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&opt=cablint,zlint,x509lint&minNotBefore=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
> >
> >
Hi Wayne
Thank you again for your answer

I fully understand the proposed solution about 2018 roots but as I previously 
said some concerns arise, not only for timing issues, but also from unexpected 
behaviours in some environment (EUTL, Spanish Public Administration validation 
platforms...etc) that could have a significant impact in our certificate 
distribution, so if we can we would like to avoid this solution.

What about Camerfirma proposal:

1.- A complete revocation of any SSL certificate issued by 2016 root
2.- "Point in time" BR audit
3.- Start issuing certificates from a clean environment from 2016 root

This would be a quicker and good solution for us and we think this guarantee 
the community that everything is corrected and ok from this point on.

Best Regards
Ramiro

___
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&opt=cablint,zlint,x509lint&minNotBefore=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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

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

On Wednesday, March 28, 2018 at 7:34:25 AM UTC+2, Adrian R. wrote:
> Hello
> can you please sign the PDF files on that site?
> 
> the very first page of CPS_eidas_EN_v_1_2_3.pdf says
> "Document valid only in digital format digitally signed by the Policy 
> Authority"
> 
> but the PDF that i was offered to download is not signed and was delivered 
> via a plain http link, are those working draft versions and not final?
> 
> 
> I also looked at a few of the older/other versions published there:
> 
> CPS_EN_v_3_3.pdf - PDF not signed but that phrase is not present either.
> 
> CPS_eidas_v_1_2_1_EN.pdf - (april 2017) same phrase is present on the first 
> page but the PDF file is not signed.
> 
> CPS_eidas_EN_v_1_1.pdf - (nov 2016) - signed PDF (and that phrase is not 
> present)
> 
> 
> Adrian R.
> 
> 
> 
> On Tuesday, 27 March 2018 12:42:50 UTC+3, ramiro...@gmail.com  wrote:
> > 
> > 
> > New versions of CPS are being published today in our WebSite.
> > 
> > http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/
> > 
> > CPS-EIDAS (2016 root) v 1.2.3
> > CPS (2003 2008 roots) v.3.3
> > 
> > Regards
> > Ramiro

Hi Adrian
Thank you for your feedback.
Already signed and published.
We have cleaned the webpage with the last CPS for the sake of simplicity.
There is a historical CPS version inside the documents.
Best Regards
Ramiro

___
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

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

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.  

> 
> 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. 

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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Adrian R. via dev-security-policy]

Hello
can you please sign the PDF files on that site?

the very first page of CPS_eidas_EN_v_1_2_3.pdf says
"Document valid only in digital format digitally signed by the Policy Authority"

but the PDF that i was offered to download is not signed and was delivered via 
a plain http link, are those working draft versions and not final?


I also looked at a few of the older/other versions published there:

CPS_EN_v_3_3.pdf - PDF not signed but that phrase is not present either.

CPS_eidas_v_1_2_1_EN.pdf - (april 2017) same phrase is present on the first 
page but the PDF file is not signed.

CPS_eidas_EN_v_1_1.pdf - (nov 2016) - signed PDF (and that phrase is not 
present)


Adrian R.



On Tuesday, 27 March 2018 12:42:50 UTC+3, ramiro...@gmail.com  wrote:
> 
> 
> New versions of CPS are being published today in our WebSite.
> 
> http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/
> 
> CPS-EIDAS (2016 root) v 1.2.3
> CPS (2003 2008 roots) v.3.3
> 
> Regards
> Ramiro
___
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]

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.

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.


> Best Regards
> Ramiro
> ___
> 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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

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

> ==Bad==
> * 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.


New versions of CPS are being published today in our WebSite.

http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/

CPS-EIDAS (2016 root) v 1.2.3
CPS (2003 2008 roots) v.3.3

Regards
Ramiro

___
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

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

On Friday, March 23, 2018 at 4:20:51 PM UTC+1, Ryan Sleevi wrote:
> On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote:
> > > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > Hi Ryan
> > > > Many thanks for your report. I will try to answer to your concerns
> > about
> > > > our root inclusión.
> > > >
> > > > > In attempt to discuss continued trust, I have attempted to summarize
> > the
> > > > > patterns and issues of note, along with the timeline from reporting
> > to
> > > > > remediation. It is my goal that this will allow the public to make an
> > > > > objective assessment of the risks introduced by Camerfirma, as well
> > as
> > > > the
> > > > > responsiveness towards remediation. While the ecosystem continues to
> > > > > improve both its understanding of the requirements and expectations,
> > we
> > > > > must nevertheless consider the full picture.
> > > > >
> > > > > Issue 1: Invalid dNSNames/CNs (
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
> > > > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> > > > > 2017-08-13 - Jonathan Rudenberg contacts the CA
> > > > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> > > > > 2017-08-17 - Camerfirma Responds
> > > > > 2017-09 - Scheduled remediation
> > > > > 2017-12 - First attempted remediation
> > > > > 2018-02-14 - Actual remediation, as per
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> > > > >
> > > > > Issue 2: Unrevoked Internal Servernames (
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > > > 2016-10-01 - Deadline for revoking internal server name certificates
> > > > > 2017-08-24 - Camerfirma shares list of misissued certificates
> > affected by
> > > > > Issue 1, along with their response
> > > > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to
> > identify
> > > > and
> > > > > revoke internal server name certificates -
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> > > > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
> > > > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> > > > > responded to outstanding questions -
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> > > > > 2017-12-21 - Camerfirma responds to the substance of the questions
> > > > >
> > > > > Issue 3 - Improperly Configured OCSP -
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> > > > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> > > > > configurations at
> > > > >
> > > >
> > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> > > > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance
> > by
> > > > > Camerfirma
> > > > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one
> > of
> > > > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22,
> > to
> > > > > implement these changes. Camerfirma did not self-report this
> > > > > non-compliance, despite acknowledging it on 12-12.
> > > > > 2018-01-03 - Camerfirma completes a minimal incident report with all
> > > > > required information.
> > > > >
> > > > > Issue 4 - Improper CAA checking (
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> > > > > 2017-09-08 - Baseline Requirements require checking CAA
> > > > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> > > > > Camerfirma
> > > > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> > > > > because they found "and for which CAA was checked" to be confusing
> > and
> > > > > indicating that CAA checking was optional.
> > > > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
> > > > >
> > > >
> > > > All previous bugs as you said are closed successfully.
> > > >
> > > > >
> > > > > Issue 5 - Duplicate dNSNames and invalid
> > > > localityName/stateOrProvinceName (
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > > > > 2017-04-17 - Issue reported
> > > > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The
> > issue
> > > > > is apparently a Camerfirma issue, and with improper logging as well
> > as
> > > > > certificate configuration.
> > > > > 2017-10-13 - StartCom provides incident report, as a Camerfirma
> > reseller
> > > > > Note: No response was provided by Camerfirma in this incident report.
> > > > >
> > > > We were not aware that an answer from us was needed. The incident
> > report
> > > > provided by StartCom was coordinated with us.
> > > > >
> > > > > Issue 6 - Out of date CP/CPSes
> > > > > 2016-06 - Last published version of the CPS at
> > > > 

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

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote:
> > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Hi Ryan
> > > Many thanks for your report. I will try to answer to your concerns
> about
> > > our root inclusión.
> > >
> > > > In attempt to discuss continued trust, I have attempted to summarize
> the
> > > > patterns and issues of note, along with the timeline from reporting
> to
> > > > remediation. It is my goal that this will allow the public to make an
> > > > objective assessment of the risks introduced by Camerfirma, as well
> as
> > > the
> > > > responsiveness towards remediation. While the ecosystem continues to
> > > > improve both its understanding of the requirements and expectations,
> we
> > > > must nevertheless consider the full picture.
> > > >
> > > > Issue 1: Invalid dNSNames/CNs (
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
> > > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> > > > 2017-08-13 - Jonathan Rudenberg contacts the CA
> > > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> > > > 2017-08-17 - Camerfirma Responds
> > > > 2017-09 - Scheduled remediation
> > > > 2017-12 - First attempted remediation
> > > > 2018-02-14 - Actual remediation, as per
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> > > >
> > > > Issue 2: Unrevoked Internal Servernames (
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > > 2016-10-01 - Deadline for revoking internal server name certificates
> > > > 2017-08-24 - Camerfirma shares list of misissued certificates
> affected by
> > > > Issue 1, along with their response
> > > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to
> identify
> > > and
> > > > revoke internal server name certificates -
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> > > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
> > > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> > > > responded to outstanding questions -
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> > > > 2017-12-21 - Camerfirma responds to the substance of the questions
> > > >
> > > > Issue 3 - Improperly Configured OCSP -
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> > > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> > > > configurations at
> > > >
> > >
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> > > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance
> by
> > > > Camerfirma
> > > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one
> of
> > > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22,
> to
> > > > implement these changes. Camerfirma did not self-report this
> > > > non-compliance, despite acknowledging it on 12-12.
> > > > 2018-01-03 - Camerfirma completes a minimal incident report with all
> > > > required information.
> > > >
> > > > Issue 4 - Improper CAA checking (
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> > > > 2017-09-08 - Baseline Requirements require checking CAA
> > > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> > > > Camerfirma
> > > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> > > > because they found "and for which CAA was checked" to be confusing
> and
> > > > indicating that CAA checking was optional.
> > > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
> > > >
> > >
> > > All previous bugs as you said are closed successfully.
> > >
> > > >
> > > > Issue 5 - Duplicate dNSNames and invalid
> > > localityName/stateOrProvinceName (
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > > > 2017-04-17 - Issue reported
> > > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The
> issue
> > > > is apparently a Camerfirma issue, and with improper logging as well
> as
> > > > certificate configuration.
> > > > 2017-10-13 - StartCom provides incident report, as a Camerfirma
> reseller
> > > > Note: No response was provided by Camerfirma in this incident report.
> > > >
> > > We were not aware that an answer from us was needed. The incident
> report
> > > provided by StartCom was coordinated with us.
> > > >
> > > > Issue 6 - Out of date CP/CPSes
> > > > 2016-06 - Last published version of the CPS at
> > > >
> > >
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> > > > 2018-05 - Next proposed update of the CPS, as stated elsewhere on
> this
> > > > thread
> > > >
> > > We already have a new CPS version, next week we will publish it, and a
> new
> > > v

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

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

On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote:
> On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hi Ryan
> > Many thanks for your report. I will try to answer to your concerns about
> > our root inclusión.
> >
> > > In attempt to discuss continued trust, I have attempted to summarize the
> > > patterns and issues of note, along with the timeline from reporting to
> > > remediation. It is my goal that this will allow the public to make an
> > > objective assessment of the risks introduced by Camerfirma, as well as
> > the
> > > responsiveness towards remediation. While the ecosystem continues to
> > > improve both its understanding of the requirements and expectations, we
> > > must nevertheless consider the full picture.
> > >
> > > Issue 1: Invalid dNSNames/CNs (
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
> > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> > > 2017-08-13 - Jonathan Rudenberg contacts the CA
> > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> > > 2017-08-17 - Camerfirma Responds
> > > 2017-09 - Scheduled remediation
> > > 2017-12 - First attempted remediation
> > > 2018-02-14 - Actual remediation, as per
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> > >
> > > Issue 2: Unrevoked Internal Servernames (
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > > 2016-10-01 - Deadline for revoking internal server name certificates
> > > 2017-08-24 - Camerfirma shares list of misissued certificates affected by
> > > Issue 1, along with their response
> > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify
> > and
> > > revoke internal server name certificates -
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
> > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> > > responded to outstanding questions -
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> > > 2017-12-21 - Camerfirma responds to the substance of the questions
> > >
> > > Issue 3 - Improperly Configured OCSP -
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> > > configurations at
> > >
> > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
> > > Camerfirma
> > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
> > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
> > > implement these changes. Camerfirma did not self-report this
> > > non-compliance, despite acknowledging it on 12-12.
> > > 2018-01-03 - Camerfirma completes a minimal incident report with all
> > > required information.
> > >
> > > Issue 4 - Improper CAA checking (
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> > > 2017-09-08 - Baseline Requirements require checking CAA
> > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> > > Camerfirma
> > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> > > because they found "and for which CAA was checked" to be confusing and
> > > indicating that CAA checking was optional.
> > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
> > >
> >
> > All previous bugs as you said are closed successfully.
> >
> > >
> > > Issue 5 - Duplicate dNSNames and invalid
> > localityName/stateOrProvinceName (
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > > 2017-04-17 - Issue reported
> > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> > > is apparently a Camerfirma issue, and with improper logging as well as
> > > certificate configuration.
> > > 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> > > Note: No response was provided by Camerfirma in this incident report.
> > >
> > We were not aware that an answer from us was needed. The incident report
> > provided by StartCom was coordinated with us.
> > >
> > > Issue 6 - Out of date CP/CPSes
> > > 2016-06 - Last published version of the CPS at
> > >
> > http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> > > 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> > > thread
> > >
> > We already have a new CPS version, next week we will publish it, and a new
> > version when it was RFC 3647 compliant.
> >
> > >
> > > I'm not sure whether to track issues with the new hierarchy, so I will
> > > simply note the following:
> > > 2017-08-23 - Last issued certificate with invalid dNSName (
> > >
> > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
> > > )
> > > 2017-12-13 - Last iss

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

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan
> Many thanks for your report. I will try to answer to your concerns about
> our root inclusión.
>
> > In attempt to discuss continued trust, I have attempted to summarize the
> > patterns and issues of note, along with the timeline from reporting to
> > remediation. It is my goal that this will allow the public to make an
> > objective assessment of the risks introduced by Camerfirma, as well as
> the
> > responsiveness towards remediation. While the ecosystem continues to
> > improve both its understanding of the requirements and expectations, we
> > must nevertheless consider the full picture.
> >
> > Issue 1: Invalid dNSNames/CNs (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
> > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> > 2017-08-13 - Jonathan Rudenberg contacts the CA
> > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> > 2017-08-17 - Camerfirma Responds
> > 2017-09 - Scheduled remediation
> > 2017-12 - First attempted remediation
> > 2018-02-14 - Actual remediation, as per
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> >
> > Issue 2: Unrevoked Internal Servernames (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > 2016-10-01 - Deadline for revoking internal server name certificates
> > 2017-08-24 - Camerfirma shares list of misissued certificates affected by
> > Issue 1, along with their response
> > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify
> and
> > revoke internal server name certificates -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
> > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> > responded to outstanding questions -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> > 2017-12-21 - Camerfirma responds to the substance of the questions
> >
> > Issue 3 - Improperly Configured OCSP -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> > configurations at
> >
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
> > Camerfirma
> > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
> > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
> > implement these changes. Camerfirma did not self-report this
> > non-compliance, despite acknowledging it on 12-12.
> > 2018-01-03 - Camerfirma completes a minimal incident report with all
> > required information.
> >
> > Issue 4 - Improper CAA checking (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> > 2017-09-08 - Baseline Requirements require checking CAA
> > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> > Camerfirma
> > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> > because they found "and for which CAA was checked" to be confusing and
> > indicating that CAA checking was optional.
> > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
> >
>
> All previous bugs as you said are closed successfully.
>
> >
> > Issue 5 - Duplicate dNSNames and invalid
> localityName/stateOrProvinceName (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > 2017-04-17 - Issue reported
> > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> > is apparently a Camerfirma issue, and with improper logging as well as
> > certificate configuration.
> > 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> > Note: No response was provided by Camerfirma in this incident report.
> >
> We were not aware that an answer from us was needed. The incident report
> provided by StartCom was coordinated with us.
> >
> > Issue 6 - Out of date CP/CPSes
> > 2016-06 - Last published version of the CPS at
> >
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> > 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> > thread
> >
> We already have a new CPS version, next week we will publish it, and a new
> version when it was RFC 3647 compliant.
>
> >
> > I'm not sure whether to track issues with the new hierarchy, so I will
> > simply note the following:
> > 2017-08-23 - Last issued certificate with invalid dNSName (
> >
> https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
> > )
> > 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> > requirements that "CAs conforming to this profile MUST use either the
> > PrintableString or UTF8String encoding of DirectoryString, with two
> > exceptions" (
> https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-0

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

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

Hi Ryan
Many thanks for your report. I will try to answer to your concerns about our 
root inclusión.

> In attempt to discuss continued trust, I have attempted to summarize the
> patterns and issues of note, along with the timeline from reporting to
> remediation. It is my goal that this will allow the public to make an
> objective assessment of the risks introduced by Camerfirma, as well as the
> responsiveness towards remediation. While the ecosystem continues to
> improve both its understanding of the requirements and expectations, we
> must nevertheless consider the full picture.
> 
> Issue 1: Invalid dNSNames/CNs (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
> 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> 2017-08-13 - Jonathan Rudenberg contacts the CA
> 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> 2017-08-17 - Camerfirma Responds
> 2017-09 - Scheduled remediation
> 2017-12 - First attempted remediation
> 2018-02-14 - Actual remediation, as per
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> 
> Issue 2: Unrevoked Internal Servernames (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> 2016-10-01 - Deadline for revoking internal server name certificates
> 2017-08-24 - Camerfirma shares list of misissued certificates affected by
> Issue 1, along with their response
> 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify and
> revoke internal server name certificates -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
> 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> responded to outstanding questions -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> 2017-12-21 - Camerfirma responds to the substance of the questions
> 
> Issue 3 - Improperly Configured OCSP -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> configurations at
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
> Camerfirma
> 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
> their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
> implement these changes. Camerfirma did not self-report this
> non-compliance, despite acknowledging it on 12-12.
> 2018-01-03 - Camerfirma completes a minimal incident report with all
> required information.
> 
> Issue 4 - Improper CAA checking (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> 2017-09-08 - Baseline Requirements require checking CAA
> 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> Camerfirma
> 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> because they found "and for which CAA was checked" to be confusing and
> indicating that CAA checking was optional.
> 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
>

All previous bugs as you said are closed successfully.

> 
> Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> 2017-04-17 - Issue reported
> 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> is apparently a Camerfirma issue, and with improper logging as well as
> certificate configuration.
> 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> Note: No response was provided by Camerfirma in this incident report.
> 
We were not aware that an answer from us was needed. The incident report 
provided by StartCom was coordinated with us.
>
> Issue 6 - Out of date CP/CPSes
> 2016-06 - Last published version of the CPS at
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> thread
> 
We already have a new CPS version, next week we will publish it, and a new 
version when it was RFC 3647 compliant.

>
> I'm not sure whether to track issues with the new hierarchy, so I will
> simply note the following:
> 2017-08-23 - Last issued certificate with invalid dNSName (
> https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
> )
> 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> requirements that "CAs conforming to this profile MUST use either the
> PrintableString or UTF8String encoding of DirectoryString, with two
> exceptions" ( https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 
> )
>
there is an open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 where 
previous bug are treated.

> 
> Notable is that Camerfirma includes the organizationIdentifier,
> OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from
> the original message, within Section 3.1.1, wi

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

[Ryan Sleevi via dev-security-policy]

Wayne,

Thank you for your detailed review of the CP/CPS.

In attempt to discuss continued trust, I have attempted to summarize the
patterns and issues of note, along with the timeline from reporting to
remediation. It is my goal that this will allow the public to make an
objective assessment of the risks introduced by Camerfirma, as well as the
responsiveness towards remediation. While the ecosystem continues to
improve both its understanding of the requirements and expectations, we
must nevertheless consider the full picture.

Issue 1: Invalid dNSNames/CNs (
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
2017-08-13 - Jonathan Rudenberg contacts the CA
2017-08-16 - Kathleen Wilson opens a Bugzilla incident
2017-08-17 - Camerfirma Responds
2017-09 - Scheduled remediation
2017-12 - First attempted remediation
2018-02-14 - Actual remediation, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33

Issue 2: Unrevoked Internal Servernames (
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
2016-10-01 - Deadline for revoking internal server name certificates
2017-08-24 - Camerfirma shares list of misissued certificates affected by
Issue 1, along with their response
2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify and
revoke internal server name certificates -
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
2017-11-28 - Gerv Markham highlights that Camerfirma has still not
responded to outstanding questions -
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
2017-12-21 - Camerfirma responds to the substance of the questions

Issue 3 - Improperly Configured OCSP -
https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
configurations at
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
Camerfirma
2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
implement these changes. Camerfirma did not self-report this
non-compliance, despite acknowledging it on 12-12.
2018-01-03 - Camerfirma completes a minimal incident report with all
required information.

Issue 4 - Improper CAA checking (
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
2017-09-08 - Baseline Requirements require checking CAA
2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
Camerfirma
2017-11-29 - Camerfirma confirms misissuance, believing it was valid
because they found "and for which CAA was checked" to be confusing and
indicating that CAA checking was optional.
2017-11-29 - Camerfirma claims CAA checking is activated on all RAs

Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName (
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
2017-04-17 - Issue reported
2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
is apparently a Camerfirma issue, and with improper logging as well as
certificate configuration.
2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
Note: No response was provided by Camerfirma in this incident report.

Issue 6 - Out of date CP/CPSes
2016-06 - Last published version of the CPS at
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
2018-05 - Next proposed update of the CPS, as stated elsewhere on this
thread

I'm not sure whether to track issues with the new hierarchy, so I will
simply note the following:
2017-08-23 - Last issued certificate with invalid dNSName (
https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
)
2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
requirements that "CAs conforming to this profile MUST use either the
PrintableString or UTF8String encoding of DirectoryString, with two
exceptions" (
https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 )

Notable is that Camerfirma includes the organizationIdentifier,
OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from
the original message, within Section 3.1.1, with the validation process
described in 3.1.8.1. However, the CP/CPS lacks details as to the
construction and validation - it appears to be a construction of "VAT"
[member state] "-" [VAT number]


In this, we see a pattern of issues, with a strong reliance on trusting RAs
(which included entities such as StartCom, known to not be validating
correctly) and, when failure detected, on technical controls. We see a
pattern of delayed remediation, misunderstanding of expectations in the
face of misissuance, and misunderstandings of the requirements themselves.
If there is any one remark that perfectly captures this, it would be

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

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

Hi Wayne
Here my answers to the ==Meh== questions.

1 * Camerfirma has had a number of recent compliance issues as listed below:
Resolved:
  * Non-BR-compliant OCSP responders:
   
https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
  * CAA checking failure:
  
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871
  * Duplicate SANs and without localityName or 
stateOrProvinceName:
   
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067
  * Invalid DNS Names:
   
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 (just resolved today)

Still Open:
  * Non-printable characters in OU field:
  
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 (this issue was reported 
by Camerfirma)

RMM --> We are working on the "still open" bug to close it as soon as possible.


2 * CPS [5] section 1.2.1.1 appears to exempt test certificates from BR 
requirements.

RMM --> AC Camerfirma do not issue SSL test certificates anymore. AC Camerfirma 
will clarify this issue in the next CPS version

3 * Section 3.1.8.2.2 of the CPS implies that CAA checking is done manually. 
While this isn’t forbidden, it is easily susceptible to errors.

RMM --> See https://bugzilla.mozilla.org/show_bug.cgi?id=1390977. 
At the moment a non-technical check over the CAA value is done by the RA 
Operator before issue any certificate. 
We plan to have the CAA technical control in March 2018,

4 * CPS section 1.2.1.4.1.3 states that the GCSR2016 “is only used for the 
purpose of carrying out the accreditation processes with different browsers.” 
We recently decided to relax the requirements for inclusion, but this statement 
does imply that there is no value to Mozilla users in enabling the websites 
trust bit for this root.

RMM --> We use this Root as a possible contingency. We would like to keep it as 
it. If the community considers it's a risk, AC Camerfirma has no objection to 
leave it out of the scope.

5 * CPS section 1.5.5 indicates that delegated RAs are permitted, but it does 
not clearly indicate that domain validation functions may not be delegated.

RMM -> AC Camerfirma will clarify this issue in the next CPS version. Since it 
was stated by BR AC Camerfirma has always performed domain validation.

6 * CPS section 2.5.3 states that “Camerfirma currently offers the OCSP service 
free-of-charge but reserves the right to invoice for these services.” If OCSP 
service were to be blocked for all but paying users, I believe that would be a 
BR violation.

RMM -> AC Camerfirma will correct this issue in the next CPS version. 
Nevertheless AC Camerfirma never ever has charged for OCSP access.

BR
Ramiro
___
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

[Ramiro Muñoz via dev-security-policy]

> 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).
>
> Roots from the older hierarchies are currently included in the Mozilla
> CA program, but the CPS that applies to these roots does not comply with 
> Mozilla policy (it hasn't been revised since 2015) - is that correct? If so, 
> how and when do you intend to correct the problem?

RMM -> Certainly we have focused on the eIDAS CPS roots 2016 that is affecting 
this bug.
Although the CPS version of the root (2003 and 2008) is dated 2015, procedures 
and controls used to issue SSL certificates are the same for all roots and 
fulfill the BR requirements as indicated by our WEBTRUST CA,BR,EVaudit 
reports.
We are currently working on both DPC to fulfill the requirement of adaptation 
to the RFC3647 structure required by CABFORUM.  We plan to publish them next 
April. In any case we will publish them before 2018-05-31 limit required by 
CABFORUM providing a solution to this issue. Although we would like wait for 
the April RFC3647 adapted version, If the community consider that a version 
should be publish immediately, AC Camerfirma have no objection to do that.

Regards
Ramiro

___
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 Tue, Mar 6, 2018 at 4:45 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> 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).
>
> Roots from the older hierarchies are currently included in the Mozilla CA
program, but the CPS that applies to these roots does not comply with
Mozilla policy (it hasn't been revised since 2015) - is that correct? If
so, how and when do you intend to correct the problem?

- 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

[kanepyork--- via dev-security-policy]

On Tuesday, March 6, 2018 at 3:45:47 AM UTC-8, ramiro...@gmail.com wrote:
> 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&opt=cablint,zlint,x509lint&minNotBefore=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

Several times you mention in your response:

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

Why wait an entire year to publish a new version of the CPS? The Certificate 
Practices Statement should be an accurate description of the certificate 
authority's current or near future operational practices, so you should be 
publishing new versions as necessary to reflect changes in operations.
__

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

[Juan Angel Martin via dev-security-policy]

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

We've opened a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1443857
___
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

[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: 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&opt=cablint,zlint,x509lint&minNotBefore=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

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

[Wayne Thayer via dev-security-policy]

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:
>
> [snipped]
>
> NOTE: The fact that I have snipped some of the items under "==Bad=="
> does not mean I consider them unimportant. However, the items on
> which I comment I consider to be most important.
>
> > ==Bad==
> > * 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.
>
> Is the above not sufficient to terminate the public review?
>
> My comment may be confusing. The newer CPS specifically covers the roots
we're discussing, and the CPS is compliant with policy with the exception
of things noted in other comments. I would like Camerfirma to comment on my
conclusion about the older CPS and it's applicability to the older roots.

[snipped]
>
> > * 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.
>
> I would strongly suggest that further action be deferred until the cited
> contract can be confirmed to have been terminated.
>
> I would like to hear from Camerfirma on this, but StartCom did announce
that they have "terminated the company":
https://groups.google.com/d/msg/mozilla.dev.security.policy/DxbMjAN7VbY/VJ0W9LQhBwAJ


> [snipped]
>
> > * There are a few published, misissued, and currently unrevoked
> > certificates in the CCR2016 hierarchy:
> > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&;
> minNotBefore=2011-01-01
>
> If Camerfirma had been already approved and its root added to the RSS
> database, would not the above item be sufficient to remove that root?
>
> It would be treated as an incident, but in isolation seems unlikely to
rise to the level of root removal.

[snipped]
> --
> David E. Ross
> 
>
> President Trump:  Please stop using Twitter.  We need
> to hear your voice and see you talking.  We need to know
> when your message is really your own and not your attorney's.
> ___
> 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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[David E. Ross via dev-security-policy]

On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:

[snipped]

NOTE: The fact that I have snipped some of the items under "==Bad=="
does not mean I consider them unimportant. However, the items on
which I comment I consider to be most important.

> ==Bad==
> * 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.

Is the above not sufficient to terminate the public review?

[snipped]

> * 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.  

I would strongly suggest that further action be deferred until the cited
contract can be confirmed to have been terminated.

[snipped]

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

If Camerfirma had been already approved and its root added to the RSS
database, would not the above item be sufficient to remove that root?

[snipped]
-- 
David E. Ross


President Trump:  Please stop using Twitter.  We need
to hear your voice and see you talking.  We need to know
when your message is really your own and not your attorney's.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy