1891331 - NETLOCK: Policy Qualifiers other than id-qt-cps is included in TLS certificates - delayed revocation

Reporter

Description

•

2 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Steps to reproduce:

This bugreport is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1889570

Actual results:

Some of the related certificates were not revoked within the required number of days.

Expected results:

The misissued certificates should have been revoked within 5 days.

Tamás Horváth

Reporter

Comment 1

•

2 years ago

Attached file Incident report — Details

Tamás Horváth

Reporter

Comment 2

•

2 years ago

Incident Report

Summary

Additional IR over https://bugzilla.mozilla.org/show_bug.cgi?id=1889570 as all of the affected certificates was not revoked by the given 5 days based on customer requests.

NETLOCK was notified on 3 April 2024 that one of our TLS certificate (https://crt.sh/?id=11261465680), signed by our "NETLOCK Trust EV CA 3" (https://crt.sh/?id=11261465680 ) intermediate certificate gives an error on the zlint check (https://crt.sh/?id=11261465680&opt=zlint).
The investigation of the certificate above showed that the TLS certificates issued was created with User Notice field, with
Explicit Text: EV SSL certificate. Terms of service at: http://www.netlock.hu/html/dok.html value which is against BRG 2.0 since Sept. 15, 2023.

Affected intermediate issuers, from where the misissued end-user certificates were signed

NETLOCK Trust EV CA 3
NETLOCK Trust Qualified EV CA 3
NETLOCK DVSSL CA

After the initial investigation NETLOCK started the customer communication and planning the revocation of the affected certificates, as described in the Timeline section of the IR.

Impact

after contacting some of our customers of major importance for the national economy regarding the misissuance of the certificates they requested the extension of the revocation deadline because of their internal procedures they are not able to change some of their certificates in their systems in such a short timeframe

Timeline

All times are CEST

Action timestamp	Action taken
2024-04-03 10:52	E-mail arrived to our central address (compliance@netlock.hu)
2024-04-05 10:00	direct and undirect customer communication begung on the error
2024-04-05 12:30	Customer responses arriving regarding the new certificates – either accepting the new cert and the expected change date, or objections
2024-04-06 10:00	Revocations started
2024-04-09 13:21	All misissued certificates not requested to be revoked later by the customers (https://bugzilla.mozilla.org/show_bug.cgi?id=1889570) were revoked
2024-04-30 23:59	Certificates requested to be revoked later will be revoked by 2024-04-09 13:21

Root Cause Analysis

The issue originated from the change of the BRG last year. NETLOCK’s staff investigated the changes in the profiles, but unfortunately the change regarding the policy identifier was not updated.

Lessons Learned

This issue pointed out that our internal systems monitoring should be improved to catch such issues more affectively. NETLOCK has worked hard in the past period on monitoring external and internal data regarding certificate issuance.

What went well

The changes in our internal processes let us handle this issue on a timely manner and we were able to meet the deadlines required by the BRG and Mozilla.

What didn't go well

Some of our customers used the related certificates in such systems, where the changing of the certificates cannot be implemented in such a short period of time.

Where we got lucky

The security of the certificates was not affected by the misissuance. Therefore NETLOCK decided to extend the revocation period for customers of major importance for the national economy.

Action Items

Action Item	Kind	Due Date
Fix of certification profiles	Repair	2024-04-09
Revoke affected certificates	Repair	2024-04-09
Revoke remaining affected certificates (based on customer requests)	Repair	2024-04-30
Extend monitoring capabilities (linting functionality and post checks)	Remediate	2024-05-31

Tamás Horváth

Reporter

Comment 3

•

2 years ago

List of certificates

Ben Wilson

Updated

•

2 years ago

Assignee: nobody → horvath.tamas2

Status: UNCONFIRMED → ASSIGNED

Type: defect → task

Ever confirmed: true

Whiteboard: [ca-compliance] [leaf-revocation-delay]

Tamás Horváth

Reporter

Comment 4

•

2 years ago

Hello All!

All related certificates have been revoked.

Best, Tamas

Ben Wilson

Comment 5

•

2 years ago

Resolution of a delayed revocation bug requires the CA to "perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays." https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation So, I am leaving this incident report open until I can see that this has been done.

Tamás Horváth

Reporter

Comment 6

•

2 years ago

Hello Ben!

Netlock made the profile correction, the issuance of the corrected certificates within the deadline and made them available to the end users. As we have mentioned above, our customers of major importance for the national economy requested the extension of the revocation deadline after we have contacted them, the reason being their internal procedures. They are not able to change all of their certificates in the affected systems in such a short timeframe.
The imminent change would have jeopardized the operations of the mentioned companies.

Tamas

Ben Wilson

Comment 7

•

2 years ago

I think my point hasn't been addressed. Netlock is required to "include a set of remediation actions in the final incident report that aim to prevent future revocation delays." For example, one remediation action would be that Netlock work with its national economy customers to get them to streamline their certificate replacement processes.

Tamás Horváth

Reporter

Comment 8

•

2 years ago

Hello Ben!

We strive to steer clear of errors to avoid the need for withdrawals within 5 days. There is no room for error in security events, in these cases withdrawals are immediately initiated.

We would like to emphasize that our company generated new certificates required for certificate renewals for our clients within 5 days and delivered them to the clients. As mentioned earlier, certificate renewals for customers of major importance for the national economy took more than 5 days. Our company has no influence over the internal processes of these companies, as well as their compliance with regulatory obligations and requirements set by their supervisory authorities.

Customers of major importance for the national economy include:
Government offices
Banks, insurance companies
Telecommunication service providers
National postal service provider

Banks, insurance companies, and telecommunication service providers are under continuous regulatory supervision and cannot carry out updates that may cause downtime at any time. They must announce their system operations in advance and obtain approval from supervisory authorities.

Government and supervisory ministries have the sovereign right to determine system operations. The government is willing to carry out updates only after carefully planned and prepared operations.

The national postal service provider also operates critical national infrastructure, the potential disruption of which could cause significant damage to the country's supply, hence they could not take on this risk.

The mentioned clients have complex, often international decision-making processes, thus the approval processes could not be completed within 5 days.

Considering that our company has no control over the internal processes of the clients, in order to maintain their operations, our company must cooperate.

Beside the cases above - withdrawals due to non-security events -, we aim to process withdrawals as soon as possible, while considering customer demands.

In our communications to all the clients, we requested the certs to be replaced within the 5-day period. We also informed all the affected clients that these certificates would be withdrawn at the 5-day limit. As described above, some of our clients could not complete tha task within the given time-frame and reached out to us asking for additional time. After evaluating these requests one-by-one, we extended the time-frame before withdrawal in only a handful instances.

Tamas

Ben Wilson

Comment 9

•

2 years ago

I intend to close this case on or about Wed. 15-May-2024, with the understanding that Netlock will work toward more prompt certificate replacement with its customers. Netlock should also stay informed about and implement any amended certificate revocation requirements, if and when such are adopted by the CA/Browser Forum.

Flags: needinfo?(bwilson)

Wayne

Comment 10

•

2 years ago

There's still an outstanding action item:

Action Items

Action Item Kind Due Date

Extend monitoring capabilities (linting functionality and post checks) Remediate 2024-05-31

Ben Wilson

Comment 11

•

2 years ago

Comment #10 appears correct based on the Action Items listed in Comment #2.

Depends on: 1889570

Flags: needinfo?(bwilson)

Jesper Kristensen

Comment 12

•

2 years ago

It seems like NETLOCK has no intention of moving towards compliance. Yes, many subscribers currently have lengthy change management processes that hinder efficient certificate replacement. I know from my own work with critical infrastructure in the electricity industry that these process can be very difficult to speed up. But CAs cannot just treat that as something they have no control over and do nothing. CAs need to work with their subscribers on automation of issuance and renewal information so that these events are no longer manual changes that needs to go through the same change management process. And for situations that require special treatment, the CAs need to work with subscribers to get them off publicly trusted certificates and onto solutions more suited for their needs. These changes take multiple years, and ARI is still a new technology, so it will take a long time for subscribers to adopt it, but CAs need to at least show progress towards the goal and not just blame everybody else and give up like NETLOCK seems to be doing. I cannot see any evidence in this bug that indicates that NETLOCK offers or plans to offer the nessesary APIs for automation that would enable subscribers to fulfill their obligations. I can also not see any indication that NETLOCK plans to help their subscribers, for example by educating them about when they should use a private PKI instead.

Ben Wilson

Updated

•

2 years ago

Flags: needinfo?(bwilson)

Ben Wilson

Updated

•

2 years ago

Flags: needinfo?(bwilson) → needinfo?(horvath.tamas2)

Tamás Horváth

Reporter

Comment 13

•

2 years ago

Hello Jesper!

As mentioned before, we continue to work with our customers to meet compliance criteria. The issuance of the new, improved certificates within the expected deadlines has been completed.

It should be noted that there are automated processes for certificate exchanges that operate independently of trust services and service providers. If our partners do not use such automatisms, they will not be able to exchange server certificates, regardless of how quickly NETLOCK as a trust service provider can issue them. As you can see from other Bugzilla announcements dealing with similar issues, the problem is not unique and cannot be solved mainly from the TSP’s perspective.

We are currently working on providing automated solutions to our partners and will support them in the implementation process as soon as we are ready. However, it is a simple fact that if our partners do not integrate automated processes at a level where certificates can be deployed, our efforts to provide a solution will not result in a timely change.

In this case, we have also worked with clients to find out how they might be able to timely replace their certificates. As mentioned, we only did not revoke certificates within five days in situations where the current level of automation or IT support made it impossible. We must emphasize that client-side automation is not a prerequisite for issuing certificates, but we collaborate with clients to improve certificate management.

Flags: needinfo?(horvath.tamas2)

Tim Callan

Comment 14

•

2 years ago

(In reply to Tamás Horváth from comment #13)

we have also worked with clients to find out how they might be able to timely replace their certificates. As mentioned, we only did not revoke certificates within five days in situations where the current level of automation or IT support made it impossible.

Tamás,
I call your attention to bug 1896553 comment 7. Though it is a response to a different comment from a different CA, I believe the points made there are highly applicable to this discussion. As a public CA, your primary obligation is to everyone who uses the internet regardless of where they are located. Your subscriber’s inability to manage basic IT operations correctly is not your problem to fix nor an acceptable excuse for you to fail in your own CA operations. Your comments in this thread suggest that you don’t understand where your primary obligation lies.

Tamás Horváth

Reporter

Comment 15

•

2 years ago

Hello Tim!

We are in complete agreement and fully understand our primary obligations. We are committed to fulfilling our duties in a timely manner and will collaborate with our clients to meet our contractual obligations regarding communication and cooperation. Our focus will be on preventive measures to ensure similar situations do not recur in the future.

Wayne

Comment 16

•

2 years ago

(In reply to Tamás Horváth from comment #13)

In this case, we have also worked with clients to find out how they might be able to timely replace their certificates. As mentioned, we only did not revoke certificates within five days in situations where the current level of automation or IT support made it impossible. We must emphasize that client-side automation is not a prerequisite for issuing certificates, but we collaborate with clients to improve certificate management.

Can you clarify where in Netlock's Certificate Policy there there is a requirement to revoke within five days? 4.9.1's language is 24 hours. Additionally looking at Netlock's General Terms and Conditions on page 25 notes:

The Subscriber shall be responsible for:
...
initiating the modification of the certificate, the replacement or revocation of his key in accordance with Sections 9.6.3 and 4.9.1 of the Service Policy and Sections 4.7 and 4.8 hereof;

Who is actually responsible for handling revocation?

Looking at your CCADB entry for the Certificate Policy I note the following links:

https://netlock.hu/download/sp-qc-en/?wpdmdl=59471&refresh=630e0c0cb24951661864972;
https://netlock.hu/download/sp-c-en/?wpdmdl=53945&refresh=630e0c0cd0a891661864972;
https://netlock.hu/download/sp-nqc-en/?wpdmdl=53944&refresh=630e0c0cc14641661864972

A document from 15/09/2021, and two dead links that predate that original document going by the ids. I will note that the Certificate Practice Statement links are accurate.

I'm also quite unclear as to how your Certificate Policy adheres to CCADB and Chrome Root Program's separate policies on an authoritative English language version. The policy repository and Certificate Policies are telling me that the documents provided are a translation and the Hungarian version is authoritative?

About English versions:
These documents are translations of the original same titled Hungarian-language regulations. The English versions are not the official documents. The official regulations registered by the Supervisory Body are the Hungarian versions that are available on the tab “Hatályos magyar nyelvű szabályzatok”. In case of any difference between the Hungarian and the English version of any documents, Hungarian version is considered the normative regulation. Not all of the documents have been translated.

There is also contract language left in the Certificate Policy where a new one can't come into force until at least 30 days from publication which will cause problems in any policy mistake for re-issuance.

Flags: needinfo?(horvath.tamas2)

Nikolett

Comment 17

•

2 years ago

Hello Wayne!

The service policies and service practice statements have been formulated in accordance with the European Union and Hungarian legislation.
Our service policies and service practice statements precisely define when withdrawal is necessary within 24 hours.
Additionally, the Service Practice Statement includes a declaration of compliance with the 'CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates,' which is published on the website https://www.cabforum.org

The registered office of NETLOCK is located in Hungary and the official language in Hungary is Hungarian.
Accordingly, the language of the service policies and service practice statements is Hungarian, which is considered official.
The English versions are translations, and in the event of any interpretation issues, the Hungarian text shall prevail.
The timing of the preparation, publication, and entry into force of the service policies and service practice statements is governed by legislation, which the supervisory authority considers on each occasion.

NETLOCK does not have the ability to arbitrarily modify the service policies and service practice statements at any time.
The service policies and service practice statements can be accessed at the following link: https://netlock.hu/aktualis-szabalyzatok/#english and can be read after downloading. By clicking the download button, all documents open properly.

Wayne

Comment 18

•

2 years ago

Please re-read my questions as I'm trying to prevent any future incidents.

Netlock's Certificate Policy does not have 5-day revocation available. Section 4.9.1 only covers 24 hours, and 7 days. Due to this your requirement for revocation was 24 hours.
Netlock's General Terms and Conditions mention on page 24 that the Subscriber is responsible for revocation. Is this correct?
Netlock's CCADB entry's for their certificate policy are out of date by years. This needs to be addressed. To be clear I am talking about 6C61DAC3A2DEF031506BE036D2A6FE401994FBD13DF9C8D466599274C446EC98 which is embedded in the Apple, Chrome, Microsoft and Mozilla Root Stores.
I am aware that that language of Hungary is Hungarian. CCADB and Chrome Root Program's have separate policies mandating an authoritative English language version. This needs to be addressed.
I will note Section 2.1.2 as Netlock have created a big problem:

The Service Provider shall, at least 30 days before their entry into force, publish the new versions to be implemented of the Certificate Policy, the Practice Statement and the General Terms and Conditions pertaining to the services based on the present Certificate Policy and affected by the subject modification.

Or in Hungarian:

Szolgáltató weboldalán legalább 30 nappal annak hatálybalépés előtt publikálja a Szolgáltatási Rend és Szolgáltatási Szabályzat bevezetésre váró új verzióit valamint az Általános Szerződési Feltételek jelen szabályzat szerinti szolgáltatásokra vonatkozó módosítással érintett új verzióit.

For reasons I cannot understand there is legal language in your Certificate Policy where it isn't actually in force until it's been available for 30 days. This makes sense in Terms and Conditions, but not for the technical constraints of your certificates. Certificate Policies are effectively contracts attached to certificates by reference, by including this language they are technically non-compliant until 30 days after the Certificate Policy has been published.

Wayne

Comment 19

•

2 years ago

I will note that 7 days have passed without a reply to the above questions.

Nikolett

Comment 20

•

2 years ago

Netlock's Certificate Policy does not have 5-day revocation available. Section 4.9.1 only covers 24 hours, and 7 days. Due to this your requirement for revocation was 24 hours.

As previously mentioned, our Service Practice Statement includes a declaration of compliance with the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates. This means we adhere to the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates and abide by the rules therein.
Section 4.9.1 of the Service Policy for Qualified Certificate Services specifies certain instances that require revocation within 24 hours. This list is exhaustive, meaning the 24-hour revocation period applies only to the cases enumerated in Section 4.9.1.

Netlock's General Terms and Conditions mention on page 24 that the Subscriber is responsible for revocation. Is this correct?

Yes, that is correct. The subscriber is obligated to report the necessity of the revocation. NETLOCK is not responsible if the subscriber does not report the case when revocation is needed.

Netlock's CCADB entry's for their certificate policy are out of date by years. This needs to be addressed. To be clear I am talking about 6C61DAC3A2DEF031506BE036D2A6FE401994FBD13DF9C8D466599274C446EC98 which is embedded in the Apple, Chrome, Microsoft and Mozilla Root Stores.

We investigated the issue. The certification of NetLock Arany (Class Gold) Főtanúsítvány is valid. The audit attestation letter I-NL23T5_TAN-AAL-01 was issued on August 25, 2023, and is valid for one year. The audit period covered all policies from September 1, 2022, to August 22, 2023. Therefore, the date ‘(2022-09-01 to 2023-08-25)’ you see under the link refers to the covered audit period and not the validity of the certification.
https://crt.sh/?q=6C61DAC3A2DEF031506BE036D2A6FE401994FBD13DF9C8D466599274C446EC98

I am aware that that language of Hungary is Hungarian. CCADB and Chrome Root Program's have separate policies mandating an authoritative English language version. This needs to be addressed.

There is no conflict between the two. Our supervisory administration expects the service policies, service practice statements, and other documents to be in the original Hungarian language. As previously mentioned, NETLOCK does not have the ability to arbitrarily modify the service policies and service practice statements at any time. The English language documents are available for those who require them.

I will note Section 2.1.2 as Netlock have created a big problem:
The Service Provider shall, at least 30 days before their entry into force, publish the new versions to be implemented of the Certificate Policy, the Practice Statement and the General Terms and Conditions pertaining to the services based on the present Certificate Policy and affected by the subject modification.
Or in Hungarian:
Szolgáltató weboldalán legalább 30 nappal annak hatálybalépés előtt publikálja a Szolgáltatási Rend és Szolgáltatási Szabályzat bevezetésre váró új verzióit valamint az Általános Szerződési Feltételek jelen szabályzat szerinti szolgáltatásokra vonatkozó módosítással érintett új verzióit.
For reasons I cannot understand there is legal language in your Certificate Policy where it isn't actually in force until it's been available for 30 days. This makes sense in Terms and Conditions, but not for the technical constraints of your certificates. Certificate Policies are effectively contracts attached to certificates by reference, by including this language they are technically non-compliant until 30 days after the Certificate Policy has been published.

NETLOCK must operate in accordance with EU and Hungarian laws. According to the aforementioned legislation, all TSPs (Trust Service Providers) must publish the Certificate Policy and the Practice Statement as draft versions at least 30 days before they come into force. The rationale is straightforward: subscribers must be informed of changes with adequate notice. According to EU laws, this adequate notice period is 30 days. During this 30-day observation period for subscribers, the version of the service practice statement referred to as 'in force' remains in effect until the end of the 30 days.

Dimitris Zacharopoulos

Comment 21

•

2 years ago

According to EU laws, this adequate notice period is 30 days.

Hi, can you please provide some references of EU laws associated with Trust Services that support this statement?

Wayne

Comment 22

•

2 years ago

I'm not sure how I can be more clearer here, I will only focus on my first 3 questions.

Q1: In earlier comments a 5-day limit was mentioned as what was communicated to subscribers:

In our communications to all the clients, we requested the certs to be replaced within the 5-day period. We also informed all the affected clients that these certificates would be withdrawn at the 5-day limit. As described above, some of our clients could not complete tha task within the given time-frame and reached out to us asking for additional time. After evaluating these requests one-by-one, we extended the time-frame before withdrawal in only a handful instances.

This is not in your Certificate Policy at all, and you even agree in replying to me that only 24-hour revocations are allowed. The list is exhaustive, however it would still cover this incident.

Q2: Has been sufficiently answered.

Q3: I am specifically talking about the certificate policy held within CCADB. At no point did I mention an audit. As I said within Comment 16, according to CCADB's records for your 'gold' root the 'Certificate Policy (CP) URL' is:

https://netlock.hu/download/sp-qc-en/?wpdmdl=59471&refresh=630e0c0cb24951661864972; https://netlock.hu/download/sp-c-en/?wpdmdl=53945&refresh=630e0c0cd0a891661864972; https://netlock.hu/download/sp-nqc-en/?wpdmdl=53944&refresh=630e0c0cc14641661864972

Which is: A document from 15/09/2021, and two dead links that predate that original document going by the ids. I will note that the Certificate Practice Statement links are accurate.

While I am looking at that entry the 'CP/CPS Last Updated Date' notes 2023.04.03. I can see a CPS dated 2024-05-30 as linked in the Certificate Practice Statement.

Please read my comments fully before answering.

Wayne

Comment 23

•

2 years ago

It has been over 7 days and both comment 21 and comment 22 have not been answered.

Nikolett

Comment 24

•

2 years ago

Hello Wayne!

Thank you for the notification, we checked and will update the data and links in the CCADB as soon as possible.

As for comment 21:

Hi, can you please provide some references of EU laws associated with Trust Services that support this statement?

(EU) No 910/2014 of the European Parliment and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC governs trust service providers. In Hungary, the detailed rules are provided by Act CCXXII of 2015 on the General Rules for Electronic Administration and Trust Services (Eüt.), and its implementing regulations.
According to Section 80(6) of the Eüt.: A qualified trust service provider shall notify the trust supervisory authority at least 30 days prior to any planned changes in its operations or the provision of trust services compared to the data recorded in the register.
Based on this legal framework and the legal practice of the supervisory administration, the trust service provider is obligated to publish a draft version of its regulations 30 days prior to their effective date.

Wayne

Comment 25

•

2 years ago

I will leave any and all interpretation of the legal language and context to others, but here are the links provided to the documents mentioned that I can see:

(EU) No 910/2014 of the European Parliment and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC governs trust service providers.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

In Hungary, the detailed rules are provided by Act CCXXII of 2015 on the General Rules for Electronic Administration and Trust Services (Eüt.), and its implementing regulations.

https://njt.hu/jogszabaly/en/2015-222-00-00

According to Section 80(6) of the Eüt.: A qualified trust service provider shall notify the trust supervisory authority at least 30 days prior to any planned changes in its operations or the provision of trust services compared to the data recorded in the register.
Based on this legal framework and the legal practice of the supervisory administration, the trust service provider is obligated to publish a draft version of its regulations 30 days prior to their effective date.

All that I will point out of that this is related to eIDAS specifically, and any such binding of services between WebPKI and eIDAS is a decision of NETLOCK's own making. If it is their interpretation that they cannot update their CP/S within 30 days and it is not in force until then, then I wish them good luck. Following that logic any certificate issued within 30 days of that document being published are mis-issued under their own interpretation.

Given current WebPKI standards are to tie a certificate to a CP/S based off of the issuance date and this does not correspond to NETLOCK's practices, what is the remedy?

Dimitris Zacharopoulos

Comment 26

•

2 years ago

(In reply to dr. Nagy Nikolett from comment #24)

As for comment 21:

Hi, can you please provide some references of EU laws associated with Trust Services that support this statement?

(EU) No 910/2014 of the European Parliment and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC governs trust service providers. In Hungary, the detailed rules are provided by Act CCXXII of 2015 on the General Rules for Electronic Administration and Trust Services (Eüt.), and its implementing regulations.
According to Section 80(6) of the Eüt.: A qualified trust service provider shall notify the trust supervisory authority at least 30 days prior to any planned changes in its operations or the provision of trust services compared to the data recorded in the register.
Based on this legal framework and the legal practice of the supervisory administration, the trust service provider is obligated to publish a draft version of its regulations 30 days prior to their effective date.

Thank you for the response. For clarity, the part of your statement that triggered my question was the following (emphasis mine):

According to the aforementioned legislation, all TSPs (Trust Service Providers) must publish the Certificate Policy and the Practice Statement as draft versions at least 30 days before they come into force. The rationale is straightforward: subscribers must be informed of changes with adequate notice. According to EU laws, this adequate notice period is 30 days.

By the information you provided, it is clear that this "30-day rule" is only applicable for TSPs operated in Hungary because of the more specific rules described in "Eüt.", which means that -unless there is something else missing- there is no EU-level Law/rule that requires CP/CPS documents of TSPs, in general, to be published in draft mode for at least 30 days.

Please note that as highlighted in comment 25, these eIDAS rules are applicable to Qualified Trust Services. You might run into a conflict if you issue Qualified Website Authentication Certificates that are simultaneously part of the WebPKI (Publicly Trusted), but other than that it seems that creating a separate CP/CPS for the WebPKI (or the non-Qualified trust services) might be the best way to satisfy both cases (EU-Qualified and WebPKI).

Roman Fischer

Comment 27

•

2 years ago

(In reply to Dimitris Zacharopoulos from comment #26)

Please note that as highlighted in comment 25, these eIDAS rules are applicable to Qualified Trust Services. You might run into a conflict if you issue Qualified Website Authentication Certificates that are simultaneously part of the WebPKI (Publicly Trusted), but other than that it seems that creating a separate CP/CPS for the WebPKI (or the non-Qualified trust services) might be the best way to satisfy both cases (EU-Qualified and WebPKI).

Thanks Dimitris for pointing this out. I think this is valuable advice for all CA's operating in both spaces (WebPKI, eIDAS). 👍

Wayne

Comment 28

•

2 years ago

I will note that this question is outwith the 7-day period. It is a serious question on how to tie a certificate to the appropriate CP/S given NETLOCK's statements to date.

(In reply to Wayne from comment #25)

Given current WebPKI standards are to tie a certificate to a CP/S based off of the issuance date and this does not correspond to NETLOCK's practices, what is the remedy?

To clarify as far as I'm aware unless there's a per-CP/S OID tied to each certificate any check performed is based off of the notBefore date. If the CP/S doesn't have any force until it has been public for 30 days... how is this handled in practice?

Wayne

Comment 29

•

2 years ago

Can I kindly ask that a search party be sent out for NETLOCK? Alternatively came someone else figure out an answer to the above question?

Dorottya

Assignee

Comment 30

•

2 years ago

Dear Wayne, considering the existing regulatory environment, any general modifications to the CP/S must be notified to the authorities 30 days prior to their enforcement. The eIDAS and WebPKI rules are not fully harmonized. It is possible to deviate from the general procedure, but prior consultation with the authorities is requested. Following the consultation, the CP/S can be immediately modified.
In the case of instant CP/S modifications, we apply this process to avoid the above-mentioned issue.

Ben Wilson

Updated

•

2 years ago

Blocks: 1911183

Ben Wilson

Updated

•

1 year ago

Assignee: horvath.tamas2 → nagy.nikolett

Ben Wilson

Updated

•

1 year ago

Whiteboard: [ca-compliance] [leaf-revocation-delay] → [ca-compliance] [leaf-revocation-delay] Next update 2024-11-30

Ben Wilson

Comment 31

•

1 year ago

We continue work on incident-reporting and compliance requirements aimed at reducing delayed revocation, so this bug will remain open until at least February 1, 2025. Meanwhile, CAs should review https://github.com/mozilla/www.ccadb.org/pull/186.

Whiteboard: [ca-compliance] [leaf-revocation-delay] Next update 2024-11-30 → [ca-compliance] [leaf-revocation-delay] Next update 2025-02-01

Ben Wilson

Updated

•

1 year ago

Whiteboard: [ca-compliance] [leaf-revocation-delay] Next update 2025-02-01 → [ca-compliance] [leaf-revocation-delay] Next update 2025-03-03

Ben Wilson

Updated

•

1 year ago

Assignee: nagy.nikolett → vey.dorottya

Ben Wilson

Comment 32

•

1 year ago

Closure Summary is needed. Netlock also needs to express an unequivocal commitment to revoke certificates on a timely basis in accordance with section 4.9.1 of the TLS Baseline Requirements.

Nikolett

Comment 33

•

1 year ago

Hello Everyone,
as indicated previously we raised a new ticket instead of this one, you can find it here: bug 1947691
We answered the questions the community asked us in the Appendix.

Ben Wilson

Updated

•

1 year ago

Status: ASSIGNED → RESOLVED

Closed: 1 year ago

Duplicate of bug: 1947691

Flags: needinfo?(horvath.tamas2)

Resolution: --- → DUPLICATE

Ben Wilson

Updated

•

1 year ago

Whiteboard: [ca-compliance] [leaf-revocation-delay] Next update 2025-03-03 → [ca-compliance] [leaf-revocation-delay]