Bugzilla

Updated

•

5 years ago

Assignee: wthayer → eusebio.herrera

Type: defect → task

Whiteboard: [ca-compliance]

Comment 1

•

5 years ago

Eusebio: Thanks for filing this.

I'm a bit confused why it's being filed on 2019-06-04, when the issue was detected in 2018-04-10. Did I miss something in the report?

With respect to the details, Answer 3/7 doesn't really provide insight into what went wrong or how the steps taken were sufficient to prevent this. I'm hoping you can expand further.

Flags: needinfo?(eusebio.herrera)

Eusebio Herrera

Assignee

Comment 2

•

5 years ago

(In reply to Ryan Sleevi from comment #1)

Eusebio: Thanks for filing this.

I'm a bit confused why it's being filed on 2019-06-04, when the issue was detected in 2018-04-10. Did I miss something in the report?

The misissued certificates were detected on these days and were revoked.
At the time these incidents occurred, we were not fully aware of the need to register bugs immediately.
At that time we were acting by asking for incident reports to our subCAs and ordering for revoking these certificates.
This incidents are included in subCA Infocert audits.
Now we know this was our fail and we should have disclosed this incident report inmediatly.
We also have detected a similar incident with our subCA "Intesa SanPaolo". We are going to enter a new bug with this issue.
In order to avoid these cases, we previously added additional staff to the team responsible for detecting, resolving and reporting incidents of this type.

With respect to the details, Answer 3/7 doesn't really provide insight into what went wrong or how the steps taken were sufficient to prevent this. I'm hoping you can expand further.

a) In this case, the CA software didn't check that dnsnames included in the subject alternative name can't start with a ".". Once we detected the error, we notified Infocert stuff. They stopped issuing certificates and worked in a patch to add controls at the dnsnames included in the SAN extension. After 4 hours this patch was deployed in production environment and restarted the issuing of certificates.

b) In this case, the patch was developed quicker -the software only had to change the maximum lenght of the organitationname- and it was deployed in production environment in an hour, and the issuing of certificates could be restarted.

In both cases, we reviewed the certificates issued until the issuing interruption, and checked that any additional certificate was misissued.

Flags: needinfo?(eusebio.herrera)

Comment 3

•

5 years ago

Thanks, this is helpful.

I now understand why quick fixes were deployed, but I don't see what steps are systemically being taken to address issues, such as why these controls weren't there in the first place, and what sort of systemic evaluation has been done. For example, it's not clear what the controls are for the dNSName now, or whether they're sufficient, and it's not clear that just because the organizationName length restrictions are in place, whether other fields are in place.

With respect to Camerfirma's supervision of Infocert, it's great that post-issuance examination is happening, but what sort of pre-issuance involvement does Camerfirma have? For example, has Camerfirma reviewed Infocert's systems and implementation, to make sure that they meet Camerfirma's level of expectations?

Preissuance checks are great, but they're no substitute for systemic controls. For example, if a preissuance lint fails, that should be a strong signal of a systemic control failure - the lint is merely the last line of defense, not the first line. What sort of processes have changed regarding that, to help ensure robust controls and defense in depth?

Flags: needinfo?(eusebio.herrera)

Comment 4

•

5 years ago

Emailed POCs on 2019-07-04 regarding this issue, highlighting https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed

Eusebio Herrera

Assignee

Comment 5

•

5 years ago

These are the Infocert's preissuance checks:
• some simple checks performed by the application that receives the csr, such as length of the subjectDN fields, characters included in subjectDN fields and subject alternative name extension, URLs in subject alternative name extension being in valid TLDs
• checks performed by the CA when generating the pre-certificate, in a first release according to X.509 and X.520 specifications, in successive releases checks derived from CAB Forum BR & EV GuideLines have been added
• checks performed by invoking a local zlint service before sending the pre-certificate to CT logs
• checks performed by the CA when generating the certificate, as above, in a first release according to X.509 and X.520 specifications, in successive releases checks derived from CAB Forum BR & EV GuideLines have been added.

In addition Infocert audit department make checks perfomed every month by involving 10% of the certificates issued

Flags: needinfo?(eusebio.herrera)

Comment 6

•

5 years ago

This did not address all of the questions raised in Comment #3.

Flags: needinfo?(eusebio.herrera)

Juan Angel Martin

Comment 7

•

5 years ago

Camerfirma moitors the subCAs that are under our charge requesting an audit for the purpose it has according to Mozilla Root Store Policy performed by a qualified auditor.

Three months before the end of the year, Camerfirma notifies the POC of that subCA requesting information about the audit to be carried out.

As we reported in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1524871_bug.cgi?id=1524871 Camerfirma will deploy a lint tool to perform a pre-emission check before those subCAs send the pre-certificate to the CT logs.

Comment 8

•

5 years ago

I'm not sure I'm particularly reassured that your proposed remediation for this issue (checking that a sub-CA has audits). That does not seem to address the underlying issue, and it seems the extent of supervision is to merely attempt to prevent certificates from being detected, rather than to understand the systemic control failures, as mentioned in Comment #3.

I highlight this, because Camerfirma has now had multiple issues with subordinate CAs. I see Bug 1557085, Bug 1502957, Bug 1534429, and concerningly, Bug 1549861. If we look back through past bugs, we also see Bug 1509002, Bug 1481862, Bug 1455147, and Bug 1426233.

Looking through the past, we see that Camerfirma's proposed response to issues like Bug 1443857 is to deploy linting, and yet failed to do so for the sub-CAs it oversees. We similarly see that even the RA engagements that Camerfirma has engaged in, such as Bug 1357067, have resulted in a lack of adequate supervision and compliance.

At this point, I'm concerned about the systemic pattern of issues Camerfirma is showing, especially with respect to how it partners with and supervises organizations. I'm not sure what an appropriate recommendation is; for example, one option would be to begin a public discussion to holistically examine these patterns, in the form of a wiki, to gather broad community feedback about the future of Camerfirma within the root program. Another option, if deemed more surgical, might be to revoke the existing subordinates (via OneCRL) and, (via policy), forbid Camerfirma from delegating authority to third-parties, either as CAs or RAs. I'm adding a N-I for Wayne here, given the above mentioned patterns.

In any event, and again echo'ing Comment #3, a more comprehensive mitigation plan, beyond linting, which demonstrates the steps Camerfirma is taking to supervise its subordinates (and I realize that MULTICERT is by far the worse offender), is of vital importance. I'm happy to open this as a separate bug, to track the pattern, if it would be more helpful.

Flags: needinfo?(wthayer)

Comment 9

•

5 years ago

Hi Ryan

Thanks for your comments.

Agree with you. Audits are not the only answer to control a delegated SubCA, but it’s a root program requirement. We could implement some other measures if the root program required it. Nevertheless, I would like to provide you and the community with a deeper explanation of our process to issue a delegated SubCA certificate and the current controls we have already implemented and those we want to implement in order to gain control over every certificate issued under any Camerfirma root.

1.- First of all, every SubCA certificate issuance must be approved by our Board of Directors. All requests are evaluated in base of the organization activity, financial situation and technical knowledge. In fact, all of our SubCA are ruled by organizations with a previous commercial and/or institutional relationship with Camerfirma. So far Camerfirma have issued only three delegated SSL SubCAs: Infocert (institutional), Intesa SanPaolo (commercial relationship through Infocert ) and Multicert (previous commercial relationship).

2.- We control them legally by means of a contract which states that Camerfirma could take any action in case of any violation of our Policies, CPS, BR and EV requirement. We had already included in the contract the need of revoking misissued certificates in the terms stated by the BR requirements, otherwise a complete report with a remediation plan is needed.

3.- Every delegated SubCAs have its own lint control but a second pre-issuance checking against Camerfirma central lint (working as a REST service from 2019-03-22) must be carry out. Only after a successful checking against Camerfirma central lint the certificate is issued otherwise an error message is sent by the REST service. Moreover, a quality control operator make a daily post-issuance control (crt.sh) of every certificate issued by any of our SubCAs. This last step is helping us improve our central lint, in case of we still found misissued certificates.

All certificates issued by Intesa and Infocert since April 2018 have been issued properly thanks to Camerfirma central lint control. This is also true for Multicert since the bugs detected are related to other issues like audit reports, revocation period. etc, and without taking into account the entropy issue.

The bugs you mentioned also show that we are, in some cases, not answering to your requirements in a timely manner and with a no comprehensive and deep description. In this way we are going to change the way we interact with the root programs improving bug management and strengthen the controls at a Directive level.

Regarding the Bug 1557085,
(Certificates misissued in April 2018) This bug was detected by Camerfirma quality team in a corrective post issuance control. Lint control was not working in those days.

Additionally, we have an issue about revoking time. We found that we should be more precise about the explanation, case by case. To solve this problem, Camerfirma will work with the delegated SubCAs to define a contingence procedure to substitute the misissued certificates in a timely basis. To achieve this is important to involve end user in this contingence plan and make them aware of this possible situation.

Bug 1502957,
Missing Audit. At this moment all audit issues have been solved. Nevertheless, we will increase the control about audit timing. Camefirma review the audit presented by the delegated SuBCA previously to disclosed in the CCADB. Sometimes we found problems about the scope or some bugs not declared in the audit report and a new version is needed. This process is time consuming and jeopardize fulfilling the CCADB disclosed deadline.

Bug 1534429,
In this bug we weren’t able, as many other CA´s, to detect by means of the lint control this mistake. We already fixed this problem in our central lint in order to avoid this problem in the future.

Regarding the Multicert Audit is already solved. Problems with the audit report already described in the previous bug. Camerfirma works with the delegated SUbCAs in order to solve this problems.

We face the same issue about revocation period. We have notified SubCAs obligation to fulfil the period of revocation and disclose this information for all customers this issue. A complete information must be providing in case wasn’t possible due to produce a high-risk situation.

Bug 1549861.
To solve this issue more resources have been dedicated to delegated SubCAs management and control. People from the compliance area has been added to the Technical staff team.

Bug 1509002 (Camerfirma: MULTICERT certificates with a validity period greater than 825 days), Resolved by the Camerfirma Central Lint

Bug 1481862 (MULTICERT organizationName Too Long), Resolved by the Camerfirma Central Lint

Bug 1455147 Camerfirma: (Missing audit for Intermediate certificate), New team: Technical & compliance is working from now on to control audit report timing with the delegated SubCAs.

and Bug 1426233 (Infocert - Non-BR-Compliant OCSP Responders). At the moment we have a team in charge of identifying changes to make sure that, all ramifications of all changes to the BRs are incorporated into our operations both procedural and technical.

1443857 (Non-BR-Compliant Issuance - DNSName is empty) In this case lint is for internal use in Camerfirma (to be ready next August the 15th), not for SubCA.

1357067 (certs with duplicate SANs and without localityName or stateOrProvinceName),

This case is also for internal Camerfirma PKI platform use (external RA) 2 years ago and was corrected. At that moment Camerfirma do not have delegated RA for SSL.

As we have mentioned before Multicert as the other delegated SUbCA will be controled by the special multifuntional team, in order to get a full direct and impartial knowledge of Multicert procedures, and the already working preissuance central lint control filter as well.

In conclusion, based on the previous comments, we would like to emphasize that from Camerfirma we have dedicated, and continue dedicating, resources and efforts to improve and increase our levels of requirement to comply with the BR and EV ones. Although the vicissitudes of the experiences can sometimes generate errors or quality defects, at least these have the merit of generating the improvement of our procedures, in particular thanks to the reinforcement of our quality and compliance departments and the application of internal procedures and external controls related to the BR and even more. We want to convince the Community that our procedures, as well as the additional improvements we are proposing now, are applied (and will be applied) in a strict way and not only regarding to a technical level but also in our identification procedure and document requirements prior to the certificates issuance, which are not always visible to the Community.

You can rest assured that our main interest is that the Community trusts us just like we trust the Community, and for these purposes we are working and collaborating to solve any problems that can happen regarding to Camerfirma certificates and delegated SubCA certificates.

Best Regards
Ramiro.

Comment 10

•

5 years ago

(In reply to Ramiro Muñoz Muñoz from comment #9)

Thanks for your comments.

Thanks for this very detailed response. This is the kind of response we're looking for with the incident response process, in that it provides context and explanation for the issues, what existing controls may have existed to mitigate or reduce the harm, and what steps are being taken to holistically address it.

Agree with you. Audits are not the only answer to control a delegated SubCA, but it’s a root program requirement. We could implement some other measures if the root program required it.

Right. However, as you note later, each root is ultimately held responsible for the behaviour of its SubCAs, and bears full culpability. So while audits are required, generally root CAs that are issuing to other organizations are taking on 100% of the risk if that Sub-CA makes a mistake, and thus it is within their best interest to ensure that Sub-CAs are as-good-or-better in every thing they do than the root CA.

The means of achieving this varies, and you've highlighted some of the steps you had in place or are taking, and I appreciate this. I do want to reiterate, though, that if anything goes wrong with any of these, Camerfirma ultimately bears responsibility, so you should always consider going above or beyond. Alternatively, if the idea of allowing a third-party to jeopardize the trust in your organization scares you, using managed Sub-CAs and not entering into third-party agreements is a different path to take.

The minimum that a Root is required to do is to ensure audits and perform sampling. That doesn't absolve culpability, but makes sure the root takes at least some minimum steps to avoid harm. As noted on m.d.s.p., there are proposals to add even more requirements, such as public discussion/review for organizations new/not operating roots.

Bug 1502957,
Missing Audit. At this moment all audit issues have been solved. Nevertheless, we will increase the control about audit timing. Camefirma review the audit presented by the delegated SuBCA previously to disclosed in the CCADB. Sometimes we found problems about the scope or some bugs not declared in the audit report and a new version is needed. This process is time consuming and jeopardize fulfilling the CCADB disclosed deadline.

Thanks for the update. It would be good to share this update on that bug, and we can follow-up there.

In conclusion, based on the previous comments, we would like to emphasize that from Camerfirma we have dedicated, and continue dedicating, resources and efforts to improve and increase our levels of requirement to comply with the BR and EV ones. Although the vicissitudes of the experiences can sometimes generate errors or quality defects, at least these have the merit of generating the improvement of our procedures, in particular thanks to the reinforcement of our quality and compliance departments and the application of internal procedures and external controls related to the BR and even more. We want to convince the Community that our procedures, as well as the additional improvements we are proposing now, are applied (and will be applied) in a strict way and not only regarding to a technical level but also in our identification procedure and document requirements prior to the certificates issuance, which are not always visible to the Community.

Thanks. One thing I want to highlight and emphasize is that CAs can (and arguably, should) monitor for all CA compliance bugs, and not just their own, to ensure that they are truly staying aware of industry best practice. You can monitor these issues on Bugzilla by editing your Settings/Preferences, going to the "Component Watching", and watching the CA Certificate Compliance module within the NSS program. This ensures you will be automatically notified for each and every bug and comment for any CA. You can use this to review with your compliance team to ensure that Camerfirma is actually following industry minimum practices within its procedures and that of its Sub-CAs.

In terms of the answers to Comment #8, I cannot help but feel that Comment #9 puts a rather strong reliance on the linting mandated to your sub-CAs on 2019-03-22, and your review of the audits of those Sub-CAs. There is a lot more you can be doing, as shown from other CA incident bugs (and that is why I highlighted the above).

For example:

Camerfirma can appoint or contract with the auditor to ensure they receive the full audit report, and not merely the attestation letter
Camerfirma can increase the amount of certificates its compliance team samples, and the method and selection of that sampling (e.g. sampling per variable that the sub-CA is allowed to employ)
Switching such independently-operated sub-CAs onto a Managed Sub-CA platform, providing API access or (restricted) RA access as needed for these organizations.
Revoking Sub-CAs that have demonstrated patterns of issues. For example, DigiCert recently shared the cessionsation of nearly 300 independently-operated sub-CA certs as part of their remediation plan for the Verizon hierarchy, due to the risks such relationships posed to their roots.
Frequent and comprehensive communication on issues, ensuring that Camerfirma is intimately involved in the reports of every subordinate CA, as they are ultimately accountable for them.
Review of, and possible replacement of, the CA platform software used at these organizations to one that is more secure, reliable, and standards compliant - or easier to ensure such.
Careful review and audit, performed by Camerfirma staff, of all of the sub-CAs configuration, to ensure it matches Camerfirma's standards

These are just some of the 'low hanging fruit' that other CAs have engaged in, and why I highlighted my dissatisfaction with linting as a control. Any sub-CA that attempts to issue a certificate, but which fails Camerfirma's central lint, is a signal that the sub-CA has encountered a critical control failure, and should be treated as a serious incident that jeopardizes Camerfirma's root. That Camerfirma caught it was lucky, but that shouldn't be seen as a defense - merely, a great warning signal to possible issues, both technical and procedural.

Comment 11

•

5 years ago

Ramiro or Eusebio: will you please provide a remediation plan with dates as Ryan suggested in comment #8: "...a more comprehensive mitigation plan, beyond linting, which demonstrates the steps Camerfirma is taking to supervise its subordinates (and I realize that MULTICERT is by far the worse offender), is of vital importance"

Flags: needinfo?(wthayer) → needinfo?(ramirom)

Comment 12

•

5 years ago

Sure Wayne
We will send a remediation plan in the next days. In any case before July the 24th.

Flags: needinfo?(ramirom)

Comment 13

•

5 years ago

Hi Ryan

First of all, I want to thank you for your answer to my report. We will try to follow this model and provide a full and comprehensive report.
We have been reviewing internally our delegated SubCA procedure and thinking about how we can improve control in order to avoid misissued certificates. Our aim when a SubCA request arrives is to use our platform to manage it (lesser risk), sometimes the customer requirements take us to another ways.

After some deliberation we have detailed the following steps to carry out a Signing SubCA process (some of them are already done).

a) Receive the certification request (current procedure).
b) Camerfirma issues a positive internal assessment about financial, legal, commercial and technical situation to assure the organization has the suitable resources and knowledge to run a SubCA. (current procedure)
c) Camerfirma issues a positive answer to the board of directors in base on this previous assessment (current procedure).
d) Elaborate and sign a contract with the following requirements:

Provide a PKI HW and SW infrastructure document (new).
Provide a PKI Network schema (new)
Provide an annual penetration test over the PKI (new)
Provide an annual vulnerability test over the PKI (new)
At least a three-month incident report and bugs management. (new)
Contact availability 24x7 with Camerfirma supervisor staff. (current procedure but not formal)
Provide a contingency plan for certificate revocation and replacing with end users. Define different scenarios to face a hypothetical situation of multiple revocation. (new)
Provide an annual full audit report Webtrust-ETSI (current procedure)
Provide a test EE certificate for any profile issued. (new)
Use the Central Camerfirma Lint before issuing any SSL certificate. Camerfirma will carried out a post issuance control (crt.sh over any SSL certificate issued under any of Camerfirma roots, this is already done). Camerfirma will check that the BR changes are included in the Lint and crt.sh checking.

These ten points will be required to any new SubCA request.

Regarding already running SubCA (Obviously Multicert included) an addendum to the current SubCA contracts to be signed before October 2019 is being written by our legal department .

Best regards
Ramiro

Comment 14

•

5 years ago

Hi Ramiro,

In general I think that these are positive steps (I have asked some specific questions below), but they are focused on requirements that new subCAs must meet, rather than how Camerfirma will improve ongoing oversight of existing subCAs, which is the problem that needs to be fixed.

(In reply to Ramiro Muñoz Muñoz from comment #13)

Hi Ryan

First of all, I want to thank you for your answer to my report. We will try to follow this model and provide a full and comprehensive report.
We have been reviewing internally our delegated SubCA procedure and thinking about how we can improve control in order to avoid misissued certificates. Our aim when a SubCA request arrives is to use our platform to manage it (lesser risk), sometimes the customer requirements take us to another ways.

After some deliberation we have detailed the following steps to carry out a Signing SubCA process (some of them are already done).

a) Receive the certification request (current procedure).
b) Camerfirma issues a positive internal assessment about financial, legal, commercial and technical situation to assure the organization has the suitable resources and knowledge to run a SubCA. (current procedure)
c) Camerfirma issues a positive answer to the board of directors in base on this previous assessment (current procedure).
d) Elaborate and sign a contract with the following requirements:

Provide a PKI HW and SW infrastructure document (new).

Provide a PKI Network schema (new)

Provide an annual penetration test over the PKI (new)

Provide an annual vulnerability test over the PKI (new)

At least a three-month incident report and bugs management. (new)

Will you please explain what this means and how it is different from the current audits Camerfirma performs on subCAs?

Contact availability 24x7 with Camerfirma supervisor staff. (current procedure but not formal)

Provide a contingency plan for certificate revocation and replacing with end users. Define different scenarios to face a hypothetical situation of multiple revocation. (new)

Will this plan describe how the subCA will meet the BR revocation requirements?

Provide an annual full audit report Webtrust-ETSI (current procedure)

Provide a test EE certificate for any profile issued. (new)

Will this certificate be issued from at test hierarchy? We have repeatedly seen misissuances caused by the practice of signing "test" certificates with trusted CA certificates.

Use the Central Camerfirma Lint before issuing any SSL certificate. Camerfirma will carried out a post issuance control (crt.sh over any SSL certificate issued under any of Camerfirma roots, this is already done). Camerfirma will check that the BR changes are included in the Lint and crt.sh checking.

Am I correct to understand that Camerfirma's existing externally operated subCAs are already using this service?

These ten points will be required to any new SubCA request.

Regarding already running SubCA (Obviously Multicert included) an addendum to the current SubCA contracts to be signed before October 2019 is being written by our legal department .

I am most interested in how these new requirements will be enforced for existing subCAs. Does the statement abeove mean that all existing subCAs will be required to meet these requirements before October 2019? What if the do not?

Best regards
Ramiro

Flags: needinfo?(ramirom)

Comment 15

•

5 years ago

Hi Wayne
I will try to answer your questions:
Sure we have defined this new requirement for new SubCA but also for existing ones, in fact we are going to sign a adendum to the current contract (I have previously shred those terms with them and found no problem).

At least a three-month incident report and bugs management. (new)
Will you please explain what this means and how it is different from the current audits Camerfirma performs on subCAs?
This is a three month control (instead a yearly control) focus on knowing what kind of errors they have faced in this time and a follow up of the bug in process. Nevertheless the SubCA bug also are controled by the Camerfirma staff.

Provide a contingency plan for certificate revocation and replacing with end users. Define different scenarios to face a hypothetical situation of multiple revocation. (new)
Will this plan describe how the subCA will meet the BR revocation requirements?

Yes, we know that this issue is one of the most difficults to fullfil and we want to be sure that the SubCA is aware of that.

Provide a test EE certificate for any profile issued. (new)
Will this certificate be issued from at test hierarchy? We have repeatedly seen misissuances caused by the practice of signing "test" certificates with trusted CA certificates.

Sure!!

Use the Central Camerfirma Lint before issuing any SSL certificate. Camerfirma will carried out a post issuance control (crt.sh over any SSL certificate issued under any of Camerfirma roots, this is already done). Camerfirma will check that the BR changes are included in the Lint and crt.sh checking.
Am I correct to understand that Camerfirma's existing externally operated subCAs are already using this service?

Yes!!

I am most interested in how these new requirements will be enforced for existing subCAs. Does the statement abeove mean that all existing subCAs will be required to meet these requirements before October 2019? What if the do not?

Yes Wayne, as I told you before we already share those terms and condition whit the running SUbCAs and no problems found.

Best Regards
Ramiro

Flags: needinfo?(ramirom)

Comment 16

•

5 years ago

Thank you Ramiro. After reviewing the answers above, I believe that the last remediation step is "an addendum to the current SubCA contracts to be signed before October 2019". I have set the next expected update to 1-October. Please update this bug by then or when the new contract addendum has been signed by all existing CAs.

Flags: needinfo?(eusebio.herrera)

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-October 2019

Ana Lopes

Comment 17

•

5 years ago

Hi Wayne,
As we defined in our plan, we already sent all the addendums to our SubCAs to be signed.
The current situation of the addendum for each of our SubCAs is the following:

Andorra: The addendum was signed by them on September 30th, 2019. According to the information provided to them, the addendum entered into force on October 1st, 2019.
Infocert / Intesa: We notified the situation and sent the addendum on September 27th, 2019 and we received the acknowledgement of receipt on September 30th, 2019, but we have not received the document signed yet. According to the information provided to them, the addendum entered into force on October 1st, 2019.
Multicert: We notified the situation and sent the addendum on the September 27th, 2019 and we received the acknowledgement of receipt on September 30th, 2019, but we have not received the document signed yet. According to the information provided to them, the addendum entered into force on October 1st, 2019.
CGCOM: We notified the situation and sent the addendum on September 30th, 2019 and we did not receive response, so we claimed the lack of the sign on October 8th, 2019. According to the information provided to them, the addendum entered into force on October 1st, 2019.
Ivnosys: We notified the situation and sent the addendum on September 30th, 2019 and we did not receive response, so we claimed the lack of the sign on October 8th, 2019. According to the information provided to them, the addendum entered into force on October 1st, 2019.
DigitalSign: We notified the situation and sent the addendum on September 30th, 2019 and we did not receive response, so we claimed the lack of the sign on October 9th, 2019. According to the information provided to them, the addendum entered into force on October 1st, 2019.

We will keep you informed about the progress.

Kind regards

Comment 18

•

5 years ago

Ana: an update on this incident is long overdue.

Flags: needinfo?(ana.lopes)

Whiteboard: [ca-compliance] - Next Update - 01-October 2019 → [ca-compliance]

Ana Lopes

Comment 19

•

5 years ago

Hi Wayne,
Sorry for the delay. We have been waiting for all our SubCAs to accept and sign the addendum before updating the bug.
We already have all the addendum signed since November 22nd.
Regards

Flags: needinfo?(ana.lopes)

Comment 20

•

4 years ago

Wayne: I'm not happy with the delay either, and I would hope a more meaningful explanation (e.g. who the stragglers were and what's being taken to prevent future delays) would be provided, but I defer to your judgement on that. Otherwise, it does seem that the requested information has been provided.

Flags: needinfo?(wthayer)