1506607 - SwissSign: Misissuance of Intermediate Certificates because of incorrect organizationIdentifier

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Mike Guenther]

Issue description: 
Misissuing of Intermediate Certificates because of incorrect organizationIdentifier
For the intermediate CA listed below the organizationIdentifier= NTRL-FL-0002.523.017-8 is wrong. The correct value is 'NTRLI-FL-0002.523.017-8'

This is an incident report for the issue above according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

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.
On Friday Nov 09, 2018 during an internal review as a preparation for a new product we became aware of the issue described above. 

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.

a. Nov 09, 2018 A SwissSign employee detected as part of an internal review  a possible issue. He discussed the finding with his colleagues and contacted the internal Information Security group (InfSec)

b. Nov 09, 2018 (afternoon) SwissSign InfSec started the internal incident management process. Next to other tasks this included 
	i. Confirming the issue by checking https://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/01.02.01_60/ts_11941201v010201p.pdf chapter 5.1.4; 2 character ISO 3166 is demanded => 'LI' for the EU Member state Liechtenstein, but 'L' had been used in the intermediate certs
	ii. Checking for additional affected certificates: a total of 6 intermediate certificates with the same issue are detected. 
	iii. Checking for affected leaf certificates: no leaf certificates (client certs) were issued by these CA. A total of 0 (zero) leaf certificates (client certs) was detected to be hit by the problem.
	iv. Informing responsible management
	v. Informing our Auditors TÜV Trust IT (TÜV Austria)
	vi. Checking deadlines for revocation: 24h for leaf certificates, 7 days for intermediate certificates

c. Nov 12, 2018 SwissSign starts the root cause analysis to gather data for this incident report
	i. Check of Key Ceremony protocol (as IC are affected): The organizationIdentifier had been set correctly in the key ceremony protocol (for all 6 IC).
	ii. A review of the CP/CPS (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed that the organizationIdentifier had not been documented correctly for some of the issuing CAs: organizationIdentifier is documented as 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8'

d. Nov 12, 2018 Preparation for revocation of intermediate certificates

e. Nov 12, 2018 SwissSign publishes this incident report on Bugzilla and mozilla.dev.security.policy

The following follow-up measures are scheduled:
○ Publish the affected CP/CPS with correct organizationIdentifier
○ internal check for similar flaws like those started.
○ process improvement procedure started.
○ correction process for CP/CPS started.
○ external auditor asked to schedule re audit.
The details of the follow-up will be posted as soon as corresponding results are available.

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.

The listed CAs were not yet used to issue leaf certificates (end user certs) other than internal test certificates during audits. These test certificates have been revoked during those audits. 

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.

A total of 6 intermediate CAs are affected. These CAs were not yet productive. There are no leaf certificates except for the OCSP responder which we consider a part of the PKI infrastructure and therefore are not revoked within 24h. The CAs were created on June 27, 2017.

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.

○ SwissSign LI Platinum Person CA 2017 - G22 https://crt.sh/?sha256=8e35171dbc1351cf19e4d9911f367786a3b88c540529602cef9c9eba4ebac33e
○ SwissSign LI Platinum Server CA 2017 - G22 https://crt.sh/?sha256=a2f021cfe19a1c56986f0dfa6398f1a0fcc1b6504e47e0ad7fcbe5330e04aa2f
○ SwissSign LI TSA Platinum CA 2017 - G22 https://crt.sh/?sha256=988ba0b6eb48cb076060bcda65ef2c3022788dafa37948341c67d15fb17f8ae7
○ SwissSign LI Platinum Server CA 2017 - G3 https://crt.sh/?sha256=5dcdaf64fd220b593d5905332b9f49f76b45c98d548fe02165f6b2c473945e82  
○ SwissSign LI Platinum Person CA 2017 - G3 https://crt.sh/?sha256=d1b3e166d428c329218a8f5b613c77576c2af702e3d99db477dbacee1bfd1b3a
○ SwissSign LI Platinum TSA CA 2017 - G3 https://crt.sh/?sha256=fda6049b266153b9c843662a77c50d2f0a06b8cdc8111666378bb118e7215ace

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Based on the data gathered we concluded that the mistake was based on a human error. During the setup in the CA GUI the organizationIdentifier was miswritten throughout the certificate generation ceremony and then copy/pasted for the 5 other CAs. 

We did not detect these misissuances as none of the CAs were in production. While preparing for a first product the engineer discovered the issue and reported it to Information Security.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

a. Re-publish corrected CP/CPS 
b. Short term we improve the creation process for issuing CAs by additional items in the checklist
c. At the same time we plan to improve the quality of the creation process for IC by analyzing the creation as well as the documentation guides for CP/CPS
d. Additionally we will development technically enforced safeguard that checks the compliance of the OrganizationIdentifier during the setup process (e.g. first block needs to be 5 letters or letters 4 and 5 are an ISO country code as defined in ISO 3166)

For b. we would like to report back to the community about our lessons learned and steps taken. 

This bug is posted also at mozilla.dev.security.policy.

Thank you 
Mike Guenther
Information Security Officer 
SwissSign AG

Comment 1

[Wayne Thayer]

Thank you for this incident report. Please update this bug as actions described in item #7 are completed.

Comment 2

[Ryan Sleevi]

Mike,

Thanks for posting this. I have a few comments inline.

(In reply to Mike Guenther from comment #0)
> 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.

A few notes here; as captured in these directions, the intent is to go for something date-and-time stamped. Afternoon doesn't really provide clarity here; if anything, this provides an opportunity for SwissSign to demonstrate how fast they responded.

That said, it sounds like in evaluating the root cause, it's necessary to go back further. There are a number of conspicuous absences from this timeline - for example, when the certificate profile for these intermediates was created, when it was reviewed, when the ceremony was performed, any post-ceremony verification activities, etc. In short, it's important to walk back in time to understand the factors that lead to this issue - from the moment it was decided to create the intermediate, to when the issue was introduced, to when it was resolved, to any follow-up tasks.

You've focused mostly on the detect-and-remediate, which, while good to understand, is only as important as the understanding of when and how the issue was introduced. That's the timeline that helps an organization, and the community at large, evaluate what factors were contributing. You touch on this a bit later, but part of the goal of the timeline is to understand these events in a common form.


> c. Nov 12, 2018 SwissSign starts the root cause analysis to gather data for
> this incident report
> 	i. Check of Key Ceremony protocol (as IC are affected): The
> organizationIdentifier had been set correctly in the key ceremony protocol
> (for all 6 IC).
> 	ii. A review of the CP/CPS
> (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed
> that the organizationIdentifier had not been documented correctly for some
> of the issuing CAs: organizationIdentifier is documented as
> 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8'

I think this provides a good amount of substance to understanding and exploring the root cause. It sounds like your Key Ceremony was not appropriately followed and your CP/CPS was not consistent with practices - is that a fair statement?

> The following follow-up measures are scheduled:
> ○ Publish the affected CP/CPS with correct organizationIdentifier
> ○ internal check for similar flaws like those started.
> ○ process improvement procedure started.
> ○ correction process for CP/CPS started.
> ○ external auditor asked to schedule re audit.
> The details of the follow-up will be posted as soon as corresponding results
> are available.

When are these scheduled for? Having a commitment from the CA about the timelines to beginning things, and their expected completion, is an important part of the remediation process.

> 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.
> 
> A total of 6 intermediate CAs are affected. These CAs were not yet
> productive. There are no leaf certificates except for the OCSP responder
> which we consider a part of the PKI infrastructure and therefore are not
> revoked within 24h. The CAs were created on June 27, 2017.

This is why I poked on the timeline - it sounds like quite a few events have happened since then.

> 6. Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now.
> 
> Based on the data gathered we concluded that the mistake was based on a
> human error. During the setup in the CA GUI the organizationIdentifier was
> miswritten throughout the certificate generation ceremony and then
> copy/pasted for the 5 other CAs. 
> 
> We did not detect these misissuances as none of the CAs were in production.
> While preparing for a first product the engineer discovered the issue and
> reported it to Information Security.

I think this bears further explanation and discussion. For example, in understanding a root cause, understanding what your practices around key ceremonies are. For example, did your key ceremony rely on the "four eyes" principle? Why did multiple people fail to detect the issue?

From a ceremony perspective, one thing that has come out from other CA post-mortems is that GUI-based configuration, of certificate profiles or of ceremonies, is a very risky proposition, because it relies solely on human factor review. Has any consideration been given to restructuring how key ceremonies are performed?

Additionally, a common-practice is to perform a 'dry-run' ceremony prior to production, and similarly examine the results to ensure the ceremony produces the expected and desired output. This may involve review from parties other than the ceremony participants/writers, to ensure robustness from 'expected' and 'actual'. Was this something practiced?

I'm quite happy your engineer detected the issue - if anything, their attentiveness to that level of detail is a credit, as this was clearly something subtle, and I hope their alerting for the issue is not seen as a negative. I'm more concerned about how to bring those skills to the table earlier in the process, from before the ceremony is executed to immediately after, so that we can have more robust assurances.

> d. Additionally we will development technically enforced safeguard that
> checks the compliance of the OrganizationIdentifier during the setup process
> (e.g. first block needs to be 5 letters or letters 4 and 5 are an ISO
> country code as defined in ISO 3166)

In the context of ETSI, it seems like there's more prescriptive guidance given here. For example, EN 319 412-1 (and TS 119 412 v1.2.1 / TS 119 495) seem to provide greater prescriptive guidance around the use of the organizationIdentifier that would be applicable to linting.

Comment 3

[Mike Guenther]

(In reply to Ryan Sleevi from comment #2)
> Mike,
> 
> Thanks for posting this. I have a few comments inline.
> 
Dear Ryan, thanks for your feedback. We agree that there is still information missing. Our goal was to give a first summary to the community of what happened as fast as possible even if more information needs to be gathered. Therefore, we published what we knew to be true and accurate.

Below I tried to give some additional feedback to the questions that I am able to answer without having further investigation results available right now. The plan is to deliver an additional update this Friday. I hope this meets your expectations.  

> (In reply to Mike Guenther from comment #0)
> > 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.
> 
> A few notes here; as captured in these directions, the intent is to go for
> something date-and-time stamped. Afternoon doesn't really provide clarity
> here; if anything, this provides an opportunity for SwissSign to demonstrate
> how fast they responded.
> 
> That said, it sounds like in evaluating the root cause, it's necessary to go
> back further. There are a number of conspicuous absences from this timeline
> - for example, when the certificate profile for these intermediates was
> created, when it was reviewed, when the ceremony was performed, any
> post-ceremony verification activities, etc. In short, it's important to walk
> back in time to understand the factors that lead to this issue - from the
> moment it was decided to create the intermediate, to when the issue was
> introduced, to when it was resolved, to any follow-up tasks.
> 
> You've focused mostly on the detect-and-remediate, which, while good to
> understand, is only as important as the understanding of when and how the
> issue was introduced. That's the timeline that helps an organization, and
> the community at large, evaluate what factors were contributing. You touch
> on this a bit later, but part of the goal of the timeline is to understand
> these events in a common form.
> 
> 
> > c. Nov 12, 2018 SwissSign starts the root cause analysis to gather data for
> > this incident report
> > 	i. Check of Key Ceremony protocol (as IC are affected): The
> > organizationIdentifier had been set correctly in the key ceremony protocol
> > (for all 6 IC).
> > 	ii. A review of the CP/CPS
> > (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed
> > that the organizationIdentifier had not been documented correctly for some
> > of the issuing CAs: organizationIdentifier is documented as
> > 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8'
> 
> I think this provides a good amount of substance to understanding and
> exploring the root cause. It sounds like your Key Ceremony was not
> appropriately followed and your CP/CPS was not consistent with practices -
> is that a fair statement?
> 
> > The following follow-up measures are scheduled:
> > ○ Publish the affected CP/CPS with correct organizationIdentifier
> > ○ internal check for similar flaws like those started.
> > ○ process improvement procedure started.
> > ○ correction process for CP/CPS started.
> > ○ external auditor asked to schedule re audit.
> > The details of the follow-up will be posted as soon as corresponding results
> > are available.
> 
> When are these scheduled for? Having a commitment from the CA about the
> timelines to beginning things, and their expected completion, is an
> important part of the remediation process.

We will update this section this Friday. 
 
> > 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.
> > 
> > A total of 6 intermediate CAs are affected. These CAs were not yet
> > productive. There are no leaf certificates except for the OCSP responder
> > which we consider a part of the PKI infrastructure and therefore are not
> > revoked within 24h. The CAs were created on June 27, 2017.
> 
> This is why I poked on the timeline - it sounds like quite a few events have
> happened since then.
> 
> > 6. Explanation about how and why the mistakes were made or bugs introduced,
> > and how they avoided detection until now.
> > 
> > Based on the data gathered we concluded that the mistake was based on a
> > human error. During the setup in the CA GUI the organizationIdentifier was
> > miswritten throughout the certificate generation ceremony and then
> > copy/pasted for the 5 other CAs. 
> > 
> > We did not detect these misissuances as none of the CAs were in production.
> > While preparing for a first product the engineer discovered the issue and
> > reported it to Information Security.
> 
> I think this bears further explanation and discussion. For example, in
> understanding a root cause, understanding what your practices around key
> ceremonies are. For example, did your key ceremony rely on the "four eyes"
> principle? Why did multiple people fail to detect the issue?
> 
> From a ceremony perspective, one thing that has come out from other CA
> post-mortems is that GUI-based configuration, of certificate profiles or of
> ceremonies, is a very risky proposition, because it relies solely on human
> factor review. Has any consideration been given to restructuring how key
> ceremonies are performed?
> 
> Additionally, a common-practice is to perform a 'dry-run' ceremony prior to
> production, and similarly examine the results to ensure the ceremony
> produces the expected and desired output. This may involve review from
> parties other than the ceremony participants/writers, to ensure robustness
> from 'expected' and 'actual'. Was this something practiced?
> 
> I'm quite happy your engineer detected the issue - if anything, their
> attentiveness to that level of detail is a credit, as this was clearly
> something subtle, and I hope their alerting for the issue is not seen as a
> negative. I'm more concerned about how to bring those skills to the table
> earlier in the process, from before the ceremony is executed to immediately
> after, so that we can have more robust assurances.

I can say with great confidence that we not only value the input of our people, we rather have the policy to encourage them to look actively for possible mistakes. Our management recognizes that mistakes may happen and that input as in the current case help us to improve. If we had started to publish leaf certificates and recognized the mistake at a later point in time the outcome would have been much worse. 

> 
> > d. Additionally we will development technically enforced safeguard that
> > checks the compliance of the OrganizationIdentifier during the setup process
> > (e.g. first block needs to be 5 letters or letters 4 and 5 are an ISO
> > country code as defined in ISO 3166)
> 
> In the context of ETSI, it seems like there's more prescriptive guidance
> given here. For example, EN 319 412-1 (and TS 119 412 v1.2.1 / TS 119 495)
> seem to provide greater prescriptive guidance around the use of the
> organizationIdentifier that would be applicable to linting.

Agreed, there is more. My goal was to present examples for what we want to add for the internal linting we currently do. This certainly is not a finalized list. 

As said in the beginning the next update is planed for this Friday.
Mike

Comment 4

[Mike Guenther]

(In reply to Ryan Sleevi from comment #2)
> Mike,
> 
> Thanks for posting this. I have a few comments inline.
> 
> (In reply to Mike Guenther from comment #0)
> > 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.
> 
> A few notes here; as captured in these directions, the intent is to go for
> something date-and-time stamped. Afternoon doesn't really provide clarity
> here; if anything, this provides an opportunity for SwissSign to demonstrate
> how fast they responded.
> 
> That said, it sounds like in evaluating the root cause, it's necessary to go
> back further. There are a number of conspicuous absences from this timeline
> - for example, when the certificate profile for these intermediates was
> created, when it was reviewed, when the ceremony was performed, any
> post-ceremony verification activities, etc. In short, it's important to walk
> back in time to understand the factors that lead to this issue - from the
> moment it was decided to create the intermediate, to when the issue was
> introduced, to when it was resolved, to any follow-up tasks.
> 
> You've focused mostly on the detect-and-remediate, which, while good to
> understand, is only as important as the understanding of when and how the
> issue was introduced. That's the timeline that helps an organization, and
> the community at large, evaluate what factors were contributing. You touch
> on this a bit later, but part of the goal of the timeline is to understand
> these events in a common form.
> 
> 
> > c. Nov 12, 2018 SwissSign starts the root cause analysis to gather data for
> > this incident report
> > 	i. Check of Key Ceremony protocol (as IC are affected): The
> > organizationIdentifier had been set correctly in the key ceremony protocol
> > (for all 6 IC).
> > 	ii. A review of the CP/CPS
> > (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed
> > that the organizationIdentifier had not been documented correctly for some
> > of the issuing CAs: organizationIdentifier is documented as
> > 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8'
> 
This is an updated & more detailed timeline. Time stamps are added to actions when adding value. All times are CET

June 26, 2017 Creation of CA in the CA UI
June 27, 2017 Key Ceremony Offline CA
May/June 2018 First audit which included the LI CAs (https://it-tuv.com/wp-content/uploads/2018/07/AA2018070301_Audit_Attestation_TA_CERT__SwissSign_Platinum_G2_signed.pdf and https://it-tuv.com/wp-content/uploads/2018/10/20180918_Audit_Attestation_TA_CERT__SwissSign_Platinum_G3_signed.pdf)
June 2018 SwissSign decides to start preparation for a EU-certified time stamping authority

July to Nov 2018 Work is progressing for the EU time stamping authority
Nov 09, 2018 A SwissSign engineer detected as part of an internal review a possible issue. He discussed the finding with his colleagues
Nov 09, 2018; 11:49 The engineer contacted the internal Information Security group (InfSec)by e-mail.
Nov 09, 2018; ~13:00 SwissSign InfSec started the internal incident management process.
Next to other tasks this included
i. Confirming the issue by checking https://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/01.02.01_60/ts_11941201v010201p.pdf chapter 5.1.4; 2 character ISO 3166 is demanded => 'LI' for the EU Member state Liechtenstein, but 'L' had been used in the intermediate certs
ii. Checking for additional affected certificates: a total of 6 intermediate certificates with the same issue are detected.
iii. Checking for affected leaf certificates: no leaf certificates (client certs) were issued by these CA. A total of 0 (zero) leaf certificates (client certs) was detected to be hit by the problem.
iv. Informing responsible management
v. Informing our Auditors TÜV Trust IT (TÜV Austria) (Nov 09, 2018 ~15:00 telco)
vi. Checking deadlines for revocation: 24h for leaf certificates, 7 days for intermediate certificates

Nov 12, 2018; 8:30 - 11:00 SwissSign starts the root cause analysis to gather data for this incident report
i. Check of Key Ceremony protocol (as IC are affected): The organizationIdentifier had been set correctly in the key ceremony protocol (for all 6 IC).
ii. A review of the CP/CPS (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed that the organizationIdentifier had not been documented correctly for some of the issuing CAs: organizationIdentifier is documented as 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8'

Nov 12, 2018; ~ 11:00 updated our auditors and agreement of action plan
Nov 12, 2018; 16:12 Published the incident report on Bugzilla
Nov 13, 2018; 08:50 Published the incident report on mozilla.dev.security.policy
Nov 13, 2018; 17:45 updated our auditors on status and action plan
Nov 14, 2018; 13:21 Approval by management board to revocate the affected CA's
Nov 14, 2018; 15:41 Revocation of affected CAs
Nov 15, 2018; 10:30 CRL offline signing
Nov 15, 2018; 13:00 publishing of updated CRL
Nov 15, 2018; 16:00 hand over of revocation evidences to auditors for review
Nov 16, 2018; 10:00 updated our auditors on status and action plan follow-up
Nov 16, 2018; 14:00 Updated CCADB status to 'revoked'

> > The following follow-up measures are scheduled:
> > ○ Publish the affected CP/CPS with correct organizationIdentifier
As all Intermediate CAs for the LI-branch have been revoked we decided that the current version (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) will be archived by Nov 21, 2018. We will publish an updated version of the CP/CPS before we will create new intermediate CAs for LI-branch.

> > ○ internal check for similar flaws like those started.
To be finalized by end of year

> > ○ process improvement procedure started.
Planed to be finished by end of year. New intermediate CAs will only be created if this process is completed.

> > ○ correction process for CP/CPS started.
see above

> > ○ external auditor asked to schedule re audit.
actions agreed with auditors
○ Audit of immediate measures/evidences concerning CA treatment (revocation) and CP/CPS will be performed by Friday, Nov. 23rd 
○ Audit Attestation will be updated and a corrected version released by Friday, Nov. 30th 
○ General process related correction measures are scheduled to be audited right after their implementation by SwissSign 
○ Effectiveness of general process related correction measures (evidences) is scheduled to be audited at next regular audit (provided new intermediate CA have been generated and corresponding evidence is herewith available) 

The next updated is planed for the end of next week. 
Thanks Mike

Comment 5

[Mike Guenther]

Short update of our ongoing efforts

CP/CPS
The affected CP/CPS is now archived and an information for website visitors has been published. 
Corrections to the CP/CPS have been performed. As soon as we are ready to issue new LI CAs the CP/CPS will undergo a final review and then presented to our auditors before re-publishing.

Search for similar flaws
Ongoing. No similar flaws are detected up-to-date. End of review is now expected in January 2019

Process improvements
We need more sessions allocated to this process. Therefore, we extend the period into the new year. The statement "New intermediate CAs will only be created if this process is completed" still holds.

Technical enforcement
We are adding a technical safeguard which ensures that only predefined profiles for organizationIdentifier can be selected. The definition of profiles is executed in dual control. The release of this safeguard is part of a release early 2019.

Comment 6

[Mike Guenther]

Update
Search for similar flaws
In dual control we checked the parameters of our Issuing CAs with the documentation for each individual CA. Additionally, we also reviewed the available documentation (reason for the delay). The review resulted in a positive outcome.

Process improvements
We finished the review of the creation process for new issuing CAs and identified some additional points for improvements (such as additional dual controls during definition of the parameters). We believe that the changes improve the process as a whole. This process will be tested in the near future during the creation of a private Issuing CA.

Technical enforcement
We are adding a technical safeguard which ensures that only predefined profiles for organizationIdentifier can be selected. The definition of profiles is executed in dual control. The release of this safeguard is part of a release in Spring 2019.

We consider this ticket as resolved.
Thank you Mike

Comment 7

[Wayne Thayer]

Mike: thank you for the update. Please update this bug when the technical safeguard has been deployed.

Comment 8

[Mike Guenther]

With regret I have to report that the implementation might take up to end of May 2019.

The statement "New intermediate CAs will only be created if the technical safeguard is implemented" still holds.

Comment 9

[Mike Guenther]

The technical safeguard (described in comment #6) has been successfully deployed to our productive systems on the weekend. With the last remediation done I ask that this incident is closed.

Comment 10

[Wayne Thayer]

It appears that remediation has been completed.