Re: AC Camerfirma's CP & CPS disclosure
Hi Wayne here you are a response to the qualified audits. As you remarks we have include links to the previously reported bugs. We will keep you informed about the remediation process plan. Sorry for the delay as you know Juan Angel is the person in charge of this Work and is on vacation for some days. 1- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. As a result of the annual Webtrst CA BR EV AC Camerfirma has been required by our auditors by means a Qualified Audit Reports a series of changes. W4CA-1. Some discrepancies between CPS and CP W4CA-2. Some CPs do not disclose all topics in RFC3647 W4CA-3. Camerfirma had issued certificates with error (already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1431164). W4CA-4. Camerfirma had not revoked certificates within the time frame in accordance with the disclosed business practices (already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977) W4CA5. For a few certificates OCSP information was inconsistent between the OCSP and CRL service under certain circumstances. WBR-1. No sufficient controls to ensure that the CA implements the latest version of the Baseline Requirements. WBR-2. Camerfirma had issued certificates with errors according to the CA/B Forum requirements. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1431164) WBR-3. Investigation of Certificate Problem Reports within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977). WBR-4. During our procedures, we noted that for some revocation requests the subscriber Certificates were not revoked within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977). WBR-5. Not evidence self-assessments on at least a quarterly basis against a randomly selected sample of at least three percent of the Certificates issued. WEV-1. Camerfirma had issued certificates with errors according to the CA/B Forum requirements. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1431164) WEB-2. For a few certificates OCSP information was inconsistent between the OCSP and CRL service under certain circumstances. WEB-3. During our procedures, we noted that for some revocation requests the subscriber Certificates were not revoked within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977). WEB4. Investigation of Certificate Problem Reports within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977). 2- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. During the Audit process our auditors detected some differences answers form OCSP services and CRL. We detected some problems in the Trigger system that synchronize PKI platform and the OCSP platform. We decided to perform a full check in the OCSP platform and fix the inconsistences discovered. 2018-07-14 -> Release of the Qualified Audit Report 2018-09-20 -> CP/CPS modification & clarification published (W4CA-1 W4CA-2 WBR-1 WBR-5) 2018-09-10 -> Complete DDBB OCSP/PKI/CRL reviewed and fixed (W4CA-5 WEV-2) 2018-09-17 -> technical controls and synchronization reports deployed. (W4CA-5 WEV-2) October-2018 -> Depending on the Auditor availability PIT Audit. 3- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. CP/CPS issues are certificate are not a certificate issuing problem. OCSP/CRL We have no found new issues in our OCSP manual controls. All certificates are correctly issued. 4- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. CP/CPS issues. Do not affect to any certificate. OCSP/CRL issue. Certificates are issued correctly. Nevertheless we are detecting wich certificates could have been affected by the inconsistences. We will provide a list in the next days. 5- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. CP/CPS issues. Do not affect to any certificate. OCSP/CRL issue. Certificates are issued correctly. Nevertheless we are detecting wich certificates could have been affected by the inconsistences. We will provide a list in
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
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
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=50473=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 mailing list
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
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=50473=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
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
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
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=cablint,zlint,x509lint=2011-01-01
>
> Moreover, all of the CPS issues that I identified apply to the 2016 roots,
> and many of the other issues - such as CAA failures - apply equally to
> these roots. So why do you believe that the '2016 root is not affected by
> those problems'?
>
> Nevertheless We offer a "Point in time audit" over 2016 root in order to
> > provide to the community a clear assurance that all technical controls are
> > in place and fulfill the BR requirements. Previously, to start from a clean
> > point, We offer as well to revoke all WebSite certificates issued under
> > this root.
> >
> > We think that this proposal should provide a similar situation that we
> > would have if a new 2018 root were set up.
> >
> > Regards
> > Ramiro
> >
> >
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
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
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
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=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=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 > > &g
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
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=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=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
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
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=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=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=cablint,zlint,x509lint=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=50473=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, with the validation process > described in
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
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
> * 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
Hi Wyne here our answers to the ==Bad== issues we are working on the ==Meh== ones. 1 * The inclusion request references a much older CPS [3] that doesn't list the 2016 versions of these roots or comply with current policies. I only reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the older roots that are currently included. I believe this is a compliance issue with the currently included AC Camerfirma roots. RMM -> EIDAS regulation has been an important milestone that took us to consider to setup a new hierarchy (2016) and writing a new CPS apart from the other hierarchies and CPS, even more when our final target is to distribute certificates only from the 2016 hierarchy. This request to incorporate the new 2016 roots affects only to eIDAS CPS (1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for the hierarchies (2003 and 2008). 2 * I am unable to locate a BR audit for the GCSR2016, but the websites trust bit has been requested. I first thought that this root was not intended for serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root. Both roots are covered by the latest EV audit. RMM -> AC CAMERFIRMA GLOBAL FOR WEBSITES was audited for BR in the same way that was audited for EV. The absence of AC CAMERFIRMA GLOBAL FOR WEBSITES from the scope section of the attestation letter have been produced by a mistake, since this CA is detailed in Pag.32 of the same document. EV attestation letter follow the same model than BR. An auditor's note can be requested, if it is need it. 3 * Last year, Camerfirma signed a contract with StartCom as a delegated RA. While I don’t believe the StartCom distrust plan [2] specifically forbade this, it was found that Camerfirma was not performing domain validation on the OV certificates [4] as required by the BRs. RMM -> Relationship with STARCOM as a delegated RA has been finalized since STARCOM stopped issuing certificates. STARCOM RA operator’s certificates are revoked from January 2018. Last certificate issued by STARCOM as a delegated RA was on December 2017. 4 * The BR section 2.2 requirement that “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version” is not clearly stated in the CPS. Also, the final paragraph of section 1.2 implies that the CPS takes precedence over BR requirements. RMM -> This issue is already clarified in our CPS last version that will be publish next March. 5 * CPS section 3.1.8.2.2 displays a misunderstanding of BR section 3.2.2.8 when it states that ‘This last procedure will not be necessary if the certificate issuance uses “Certificate Transparency” as indicated in the CABFORUM BRs. CA-Browser Forum BR 1.4.4.’ The BRs only exempt CAA checking prior to issuing the actual certificate because checking is required prior to issuing the corresponding pre-certificate. RMM -> This issue is already clarified in our CPS last version that will be publish next March. I was due to a misunderstanding of the BR. The procedure was corrected in November 2017. 6 * Camerfirma’s CAA domains are not documented in the CPS as required by BR section 2.2. RMM -> This issue is already included in our CPS last version that will be publish next March. AC Camerfirma use "camerfirma.com" as a CAA issuer record. 7 * Camerfirma’s BR Self Assessment states that they use BR methods 2 and 4 for domain validation, but the methods are not clearly documented in the CPS as required by Mozilla policy section 2.2(3). RMM -> This issue is already documented in our CPS last version that will be publish next March. In short, we use an email with a random value to domain contact that have to be sending back to the CA to prove domain control. BR 1.5.4 (3.2.2.4.2). 8 * There are a few published, misissued, and currently unrevoked certificates in the CCR2016 hierarchy: https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01 RMM -> Those few (four) misissued certificates are revoked from the very moment we were aware of that. We are opening a bug to explain this issue. Keep on working on ==Meh== ones Best regards Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
El jueves, 17 de agosto de 2017, 12:26:05 (UTC+2), ramiro...@gmail.com escribió: > El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió: > > On 08/08/17 14:33, Alex Gaynor wrote: > > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > > > heard back from them, nor have they taken any action. What is the > > > appropriate next step here? > > > > I have emailed the primary Point of Contact at Camerfirma to enquire as > > to what is going on. > > > > Gerv > Hi Gev and Alex > > We have been trying to contact with our customer to replace the wrong > certificate otherwise we could block our customers services. We found > difficulties to reach the right person due to the holidays period. > > We have already revoke > - https://crt.sh/?id=5129200=cablint > - https://crt.sh/?id=42531587=cablint > and we are working on > - https://crt.sh/?id=112929021=cablint > We expect to be revoked along this day > > All of then are mistakes from the request form that are not been detected by > the AR operator. > > placing "http://; or "https://; in the domain name. > > We are going to improve control over the domain name entry form and report to > the AR operators. > > Best regards https://crt.sh/?id=112929021=cablint is a precertificate. You can see the CT Precertificate Poison critical extention. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió: > On 08/08/17 14:33, Alex Gaynor wrote: > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > > heard back from them, nor have they taken any action. What is the > > appropriate next step here? > > I have emailed the primary Point of Contact at Camerfirma to enquire as > to what is going on. > > Gerv Hi Gev and Alex We have been trying to contact with our customer to replace the wrong certificate otherwise we could block our customers services. We found difficulties to reach the right person due to the holidays period. We have already revoke - https://crt.sh/?id=5129200=cablint - https://crt.sh/?id=42531587=cablint and we are working on - https://crt.sh/?id=112929021=cablint We expect to be revoked along this day All of then are mistakes from the request form that are not been detected by the AR operator. placing "http://; or "https://; in the domain name. We are going to improve control over the domain name entry form and report to the AR operators. Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham escribió: > On 19/07/17 14:53, Alex Gaynor wrote: > > I'd like to report the following instance of miss-issuance: > > Thank you. Again, I have drawn this message to the attention of the CAs > concerned (Government of Venezuela and Camerfirma). > > Gerv Hi all Regarding Camerfirma certificates, we have follow the rules imposed by the local public administration to regulate the profile of several certificates. SSL certificates for public administration websites included. There is a entry in cabforum where this issue is described https://cabforum.org/pipermail/public/2016-June/007896.html. New eIDAS regulation has forced to Spanish Administration to fix this problem so from now on we can issue certificate that fully fulfil the cabforum rules. AC Camerfirma will offer to our public administration customers to renew the SSL certificates with our new eIDAS 2016 CAs. Best regards. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
