1551369 - Kamu SM: "Some-State" in stateOrProvinceName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Two Kamu SM certificates containing a stateOrProvinceName of "Some-State" were published at https://misissued.com/batch/53/ This is apparently the default placed in OpenSSL CSRs, indicating that this field was not validated. BR section 7.1.4.2.2(f) states: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. The EVGLs reference the BRs.

Please provide an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Comment 1

[Melis Şimşek]

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.

   We became aware of the problem via mail notification of Alex Cohn in mozilla.dev.security on 2019/05/13.

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.

   2019/05/13 8:30 AM GMT+3 We became aware of the problem in the Subject StateOrProvince field via the mail notification by mozilla.dev-security-policy.

   2019/05/13 9:30 AM GMT+3 We made an investigation on all of the issued certificates and confirmed that other certificates were not affected except two certificates.

   2019/05/13 10:40 AM GMT+3 We notified the incident to the customer.

   According to the BR Section 4.9.1.1, we will revoke related certificates in five (5) days and inform you about the progress.

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.

   Throughout the issuance process a control program named ARMA is used to assess the CAB BR conformance of certificate signing requests and their associated certificates since 2018/10/12. In addition to ARMA, the certificates are also checked using certificate linters via crt.sh since 2017/11/01. From now on, we are planning to make improvements in ARMA to catch the improper statements in the Locality and StateOrProvince fields.

   p.s. ARMA already checks the Country field and rejects encoding other than TR.

4. A summary of the problematic certificates. For each problem: the number of certs, and the date the first and last certs with that problem were issued.

   https://misissued.com/batch/53/

   2 certificates listed on the above site are subject to the problem.

   2017/05/11 Two problematic certificates were issued.

   We made an investigation on all of the issued certificates and found no certificates with this problem except given certificates above.

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.

   Following two certificates are affected by this issue:
   https://crt.sh/?id=225526045
   https://crt.sh/?id=199509319

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

   Kamu SM checks the identity and head office address of the government agency requesting certificate whether it is the same as the information in the certificate signing request based on the legal documents and by calling the applicant representative. This type of certificate misissuance is a single human error, not a systemic one. The improvements in ARMA will prevent such problematic issuances.

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.

   To prevent the recurrence, we will make improvements into the system to reject the CSRs that includes OpenSSL default values. That system will be completed by June 2019. Also RA personnel has been notified about the issue.

   We will provide further details in a subsequent update.

Comment 2

[Ryan Sleevi]

Note: I'm largely approaching these similar to the questions on Bug 1551364. That is, statements such as "is a single human error, not a systemic one" are, on the basis of this incident report, wholly unsubstantiated.

1. Can you please provide specific and descriptive details about the (overall) set of requirements for how Kamu SM validates such information?
   • What were they before mid-2018?
   • What are they after mid-2018?
   • What about these changes would address this?
2. Can you please provide specific and descriptive details about how ARMA is implemented, and how these changes will be sufficient?
   • Will it focus on only this issue?
   • Will it focus on other issues?
   • How will it be developed and reviewed?
3. What technical controls exist or may exist in the future?
   • For example, it would seem like stateOrLocality is something that can be preprogrammed to only accept a certain set of acceptable values. I'm given to understand Turkey has has 81 provinces, which would seem reasonable?
   • Similarly, Kamu SM could examine the countries it issues for / does business in, and similarly configure appropriate lists, for which the compliance team shall oversee and maintain according to any changes.
   • Exceptions might require an executive override, ensuring multi-party review.
4. What caused the human error, and how might that be systemically addressed?
   • For example, does the RA interface visually distinguish information provided by the customer (e.g. via CSR) from information provided by the RA? One can imagine that the workflow the validation agent engaged in contributed to the issue.
   • Alternatively, avoiding the inclusion of such information might also reduce the risk of future human error, by focusing on automation.

Such a critical failure on a basic validation, such as stateOrLocality, calls into serious question about how the system is designed and how the human and technical controls are implemented. The incident report provides an opportunity for the CA to reassure the community, by describing the holistic set of controls it had, how these controls failed, and how they're being addressed, systemically and comprehensively. When there is a 'human failure', it should be a deep cause for concern, because an ideal CA is going to be continuously striving to remove any such opportunities.

The approach to reject OpenSSL default values should not be seen as a meaningful addressing of this issue. It's a good defense in depth, but if that is the only change, then the problem is not really resolved, since human failure can just as easily lead to a less-obvious mistake.

Hopefully more comprehensive detail can be provided.

Comment 3

[Melis Şimşek]

Dear Ryan,

(In reply to Ryan Sleevi from comment #2)

Note: I'm largely approaching these similar to the questions on Bug 1551364. That is, statements such as "is a single human error, not a systemic one" are, on the basis of this incident report, wholly unsubstantiated.

1. Can you please provide specific and descriptive details about the (overall) set of requirements for how Kamu SM validates such information?
   • What were they before mid-2018?
   • What are they after mid-2018?
   • What about these changes would address this?

Kamu SM verifies the identity and address of the government agencies as follows (CPS Section 3.2.2):

• The identity and head office address of the government agency requesting a certificate is checked whether it is the same as the information in the certificate signing request based on the legal documents as follows.

  • RA personnel uploads the CSR to ARMA.
  • ARMA processes the CSR in order to check the conformance of Subject fields with the Baseline Requirements and shows parsed CSR to RA personnel. ARMA Subject field control mechanism includes:
    • Subject CN-SAN matching,
    • Proper combinations of OV Subject DN fields,
    • The inclusion of “TR” in the Country field,
    • DNS name encoding rules.
  • RA personnel checks the result of the automated control and also compare all Subject fields in the ARMA graphical interface with the legal documents manually.

• Applicant representative executing application procedures is verified by the legal documents that if he has the right to apply on behalf of the agency. Through the phone numbers verified according to this, it is requested to confirm the application by calling the applicant representative.

• Continuity of operation should be verified with a current official document to be submitted by applicant representative or the people authorized to issue an official document on behalf of government agencies.

In 2018, no changes were made in the identity and address validation methods. By the end of 2018, the ARMA application was commissioned. Before releasing ARMA, the identity and address validation steps were the same as described above except the automated conformance validation of CSR fields with BR and other essential standards.

2. Can you please provide specific and descriptive details about how ARMA is implemented, and how these changes will be sufficient?
   • Will it focus on only this issue?
   • Will it focus on other issues?
   • How will it be developed and reviewed?

As Kamu SM, we follow the mozilla.dev.security group and Bugzilla on a daily basis. A list of the CA issues detected on these platforms is kept in order to prevent the occurrence of the same situations in our system. So as to fulfill this aim programmatically, we have decided to implement, if possible, this situation and developed ARMA application. ARMA deals both with certificate signing requests and their associated certificates and its validation mechanism are based on CA/B BR, Mozilla Root Store Policy, the mentioned list, and other essential standards. ARMA has been progressively developing since the end of 2018 as its sources are expanding/updating. ARMA did not have stateOrProvince and Locality control since the awareness of this situation and will be added as a new feature. We have already created a task to the software development team and they have started analyzing for the development of related controls. So the scope of this program is not confined just to this issue but it includes many others. Besides, we have a csr test package which includes many positive and negative scenarios so as to test ARMA and this suite is expanding as the scenarios increase.

3. What technical controls exist or may exist in the future?
   • For example, it would seem like stateOrLocality is something that can be preprogrammed to only accept a certain set of acceptable values. I'm given to understand Turkey has has 81 provinces, which would seem reasonable?
   • Similarly, Kamu SM could examine the countries it issues for / does business in, and similarly configure appropriate lists, for which the compliance team shall oversee and maintain according to any changes.
   • Exceptions might require an executive override, ensuring multi-party review.

As we stated previous, the situation is in the analysis phase but as you mentioned in your comments since our SSL production is confined to Turkey, probably we would create lists for all StateOrProvince and Locality values and consider the matching of that information. In addition, the customer would be informed on how to fill in the relevant fields during the application process in order to evade non-matching situations.

4. What caused the human error, and how might that be systemically addressed?
   • For example, does the RA interface visually distinguish information provided by the customer (e.g. via CSR) from information provided by the RA? One can imagine that the workflow the validation agent engaged in contributed to the issue.
   • Alternatively, avoiding the inclusion of such information might also reduce the risk of future human error, by focusing on automation.

Such a critical failure on a basic validation, such as stateOrLocality, calls into serious question about how the system is designed and how the human and technical controls are implemented. The incident report provides an opportunity for the CA to reassure the community, by describing the holistic set of controls it had, how these controls failed, and how they're being addressed, systemically and comprehensively. When there is a 'human failure', it should be a deep cause for concern, because an ideal CA is going to be continuously striving to remove any such opportunities.

The approach to reject OpenSSL default values should not be seen as a meaningful addressing of this issue. It's a good defense in depth, but if that is the only change, then the problem is not really resolved, since human failure can just as easily lead to a less-obvious mistake.

Hopefully more comprehensive detail can be provided.

The mentioned improvements would mitigate the risk of recurrence and we will also apply training for RA personnel and this incident would be an epitome of careful inspection necessity. Avoiding the inclusion of both information is prohibited according to BR but excluding locality may be an additional mitigation step since its scope is broader and prone to mistake.

Comment 4

[Ryan Sleevi]

Thanks for the added detail.

The described system does sound somewhat error prone still. In particular, the extraction of the Subject from a CSR gives "attackers" considerable control and influence on information - for example, the potential introduction of additional subject fields that the CA may not have verified, or potential encoding issues.

Other CAs take an approach in which the CA/RA enters information from validated documents directly, attaching the relevant supporting evidence during this process, so that CA/RA is directly controlling all information that appears within a certificate subject. Have you considered such a system?

Another approach to reduce risk is, rather than extracting the Subject from a CSR, having the customer select from a list of validated subjects. That is, the customer makes a request for the information they'd like to include (e.g. DV, OV, IV, EV), and fills out a form with their preferred values. However, it is the RA/CA that enters this information into the system, marking each piece as validated and with the supporting information. If the customer wants to use that same subject later (but, say, for a different domain), they can just select that information. If the information has expired or changed, the customer would request a 'new' subject (which might be the same previous values, if expired, or something new, if it changed), and the same validation process ensues.

Of course, I may have misunderstood your flow, but experience has shown that CAs directly ingesting CSRs tends to be extremely error-prone, such as this situation has shown. CAs that use such an approach need to take considerable care in normalizing the CSR throughout, effectively re-encoding it. For example, ensuring the SPKI has the correct AlgorithmIdentifier encoding, ensuring that the subjectAltNames are normalized correctly (particularly for IDNs), etc.

From your expanded description, it's still unclear what is changing, other than to add a few specific values to a restrict list. While I understand this was a 'limited' human failure, it's still worth evaluating how the current implementation may allow or encourage human failures. The above description highlights a bit more about making sure the interface is 'usable' and likely to mitigate error (e.g. an RA is hopefully unlikely to enter in a value of "Some-State").

Similarly, from a process and compliance standpoint, there seems to be a number of opportunities to add additional regular review steps by your compliance teams or by other parties - I'd like to imagine that if anyone on your compliance team saw "Some-State, TR", they'd immediately flag it as an issue.

Comment 5

[Melis Şimşek]

Thanks for your answer. Let us explain in more detail. In our previous reply, the situation was not clear since we were only talking about the steps related to the Subject control.

Let us consider attack scenarios. The attacker you mentioned in your comment can be from outside or inside the organization.

If the attacker is outside the organization, the attacker will not be able to upload the file to the web page since we use the agreed-upon changed website CSR hash method, which is described in the CA/B BR Section 3.2.2.4.6, to validate the domain name as follows:

Kamu SM requests change on a page submitted in the domain name to test the agency’s control over the domain name. The requested change is the publication of the request token which will be generated from the information used in certificate signing request by the government agency, in the file which is served at .well-known/pki-validation/ directory and named as “kamusmdv.txt” on the domain. The request token which is requested to publish by Kamu SM is indicated as the SHA-256 hash value of the certificate signing request used by the government agency to certify the domain name. After the request token value is published, Kamu SM makes the necessary checks and verifies the domain name ownership.

If the attacker is inside the organization, the CSR that has already been processed, filtered according to the rules of OV Subject field in CA/B BR Section 7.1.6.1 and validated by ARMA. ARMA accepts only proper combinations of OV Subject fields and prevents additional subject fields and misuse. Also, since 2018 we have assigned extra RA personnel for multi-check. CSR controls have been carried out by two RA personnel and the lead RA personnel. In the certificate production phase, CSR is not used directly. Parsed data that is filtered and controlled by ARMA, verified by RA in comparison with legal documents is also controlled by the production team.

ARMA will be able to control the values of the stateOrProvince and locality fields by development. The analysis team is considering fetch and maintain all StateOrProvince and Locality values in Turkey.

As we observed in your comments you have stated some best practices and suggestions for our consideration. We sincerely thank you for your suggestions. As Kamu SM, we will consider these suggestions through our continuous improvement activities.

Comment 6

[Ryan Sleevi]

I believe that analysis of the attack may fundamentally misunderstand the concern.

Consider, for example, a CSR for sleevi.com asserting it is "Apple, Inc". This would pass your described agreed-upon change, with respect to validating domain, but may lead to confusion or the same human-factor errors that lead to "Some-State" appearing in an issued certificate.

Consider, for example, a further CSR, which introduces an additional extension with added semantics that are not known to Kamu SM. This, too, could potentially bypass the checks, based on your description of the system.

Consider the use of "unusual" (but defined) encoding, such as encoding multiple CNs within the same SET value for the RDN. Care must be taken to ensure that each CN is independently verified, but this is an easy mistake to overlook if all values in the SET are not enumerated.

Finally, consider the encoding of a subjectPublicKeyInfo that incorrectly omits the NULL parameters (or incorrectly includes them). A system that extracts values from the CSR, but does not re-encode, runs a similar risk.

Holistically, any input that is supplied by an external party should be treated as 'hostile', even if they're a customer. A robust system for dealing with this generally involves a system that only allowlists certain fields or values, and re-encodes them explicitly to ensure conformance with the appropriate certificate profile. With respect to fields within the Subject, it is generally highly error prone to have the information supplied by the Applicant, even when convenient, and thus when considering OV/IV/EV, a robust design is to require that an RA agent enter in the information themselves or perform some other, explicit step, which ensures a guaranteed review of each and every individual field within the certificate.

There are many other ways to achieve this, but it highlights some of the principle concerns involved with CSR ingestion. It sounds like the CSR is not directly signed, which is encouraging, but it's worth revisiting the system of controls to ensure that adequate technical controls are in place (to ensure a compliant and properly encoded profile), as well as to ensure a /usable/ interface for RAs to perform the appropriate validation steps. That it's possible for "Some-State" to be encoded highlights a system design flaw, and ways to mitigate that (such as manual entry, or an allow-list of Turkish entities where appropriate, validation of postal codes, etc) are all essential and useful parts.

In light of all of this, it may be worthwhile to revisit the answers to Questions 6 and 7 of the incident report. While restricting the use of OpenSSL defaults is a specific mitigation for this issue, it's not a systemic mitigation for human error while validating, so understanding how those processes are being improved specifically is useful and valuable, as is understanding deeper about how or why the human error was made.

Even human error such as "The RA operator was exhausted, because they'd been working all night" can lead to systemic improvements such as "We're hiring additional RA operators so they can reduce their workload or "increasing pay so they don't have to work two jobs" are valuable to understand (as a hypothetical). Hopefully this approach helps analyze the root cause more thoroughly :)

Comment 7

[Erhan TURAN]

We have fully understood the attack scenario. To make it enough clear for you, let us briefly summarize the process from the receipt of the certificate application to the beginning of the certificate production process:

The customer generates the CSR file according to the restrictions specified in the SSL application form. The fields that should be included in the Subject field are explained as follows:

• CN (Common Name) field:
  i. Name of server registered on behalf of the subscriber government agency in DNS is written in “CN” field.
  ii. “*.<domain name>” is written in this field in OV SSL wildcard certificates. This field does not contain non-distinctive names such as “.com” or “.com.tr".
  iii. The IP address or internal server name is not written in this field.
• “O (Organization)” field contains the open title or understandably abbreviated form of a subscriber government agency as laid down in organizational law or other legislation.
• In cases where “OU (Organizational Unit)” field contains an organizational unit or brand name, the brand name registered in Turkish Standards Institute shall be written.
• “ST (State or Province)” field contains province information where a subscriber government agency is located.
• “L (Locality)” field contains locality information where a subscriber government agency is located.
• Usage of “ST” and “L” fields together is optional.
• “C (Country)” field includes country code (TR) contained in ISO 3166-1 Alpha-2 standard of the country where a subscriber government agency is located.
• The CSR and the signed/sealed application form must be sent Kamu SM e-mail address. Also, the original signed/sealed document must be sent to Kamu SM. If there is an inconsistency between the data in the CSR and the applicant form, the application will be rejected.

RA personnel uploads the CSR to ARMA. ARMA displays the data in the CSR to the RA personnel in the graphical interface by performing the necessary checks (the verification of the CSR signature, field controls, Debian weak key control, public key size and algorithm control, etc.). RA personnel compares the data shown with the data on the application form. RA personnel validates the information on the application form according to the CA/B BR Section 3.2. RA personnel control process has a workflow. The RA personnel performs each of the checks in the checklist (for example each field in Subject) and sends it to other RA personnel if there is no error. In total, 3 RA personnel control all fields individually.

Assume that, the applicant is the XYZ Agency. XYZ Agency sends the CSR with legal documents. RA personnel uploads the CSR to ARMA. ARMA validates and shows the processed values to RA personnel. Assume that, the organization field is Apple Inc. as in your example. In this case, one of the RA personnel detects it and rejects it. The application form and ARMA program outputs are checked by extra RA personnel and lead RA personnel to prevent any human error that may occur since 2018. After the comparison with legal documents, the applicant is contacted by the phone obtained from the website of the applicant and the accuracy of the application is confirmed.

ARMA warns RA personnel via its graphical interface, if there is a field other than defined above in the CSR and if it encounters the misuse of the CA/B BR OV Subject field constraints or the ARMA's CSR template (such as incorrect encoding, extra field, lack of field, etc.). RA personnel rejects the application taking this warning into account and requests the organization to re-create the CSR. Furthermore, other validations are made by RA in the workflow indicated above. If there is an error about the Subject Information, RA (at least 3 of 1 of them) detects the error.

By development, ARMA will have the allow-list of provinces and their localities in Turkey. In the CSR, if there is value is not included in the allow-list, such as ‘Some-State ’, it will warn the RA personnel from the graphical interface. The mentioned issue occurred in 2017. In 2018, it is aimed to prevent other mistakes that you mentioned with multi-check.

It was decided to add a new feature to ARMA in order to prevent “Some-State” error. Our development is not only for OpenSSL default values but also province-locality matching control adding to other controls which we mention above. This will be an additional control and it is most likely that such a situation has already been prevented by increasing the number of RA controls and awareness of RA after 2018.

Erhan Turan - Kamu SM

Comment 8

[Melis Şimşek]

We’d like to report that the revocation of the two problematic certificates has been completed.
The details are as follows:
2019/05/17 https://crt.sh/?id=199509319&opt=cablint,ocsp
2019/05/17 https://crt.sh/?id=225526045&opt=cablint,ocsp

Comment 9

[Ryan Sleevi]

Based on the level of detail provided, I still remain concerned about the flow of information to the CSR, through to ARMA, and in to the certificate.

This incident demonstrates that it is wholly reasonable to be concerned that an RA personnel may fail to detect the existence of an O=Apple, Inc. field, just as they clearly failed to detect the existence of a ST=Some-State field. It does not describe how, for example, a CSR with CN=sleevi.com+CN=sleevi.net will be handled (note, that syntax is the LDAP stringified form of an RDN SET with two values)

In the spirit of wanting to ensure robust mitigations and controls are in place, a possible next step in the incident response is to request CSRs demonstrating some of the sample test cases ARMA currently handles, as well as sample CSRs described in Comment #6 and how the existing system addresses them. The goal here is to provide assurance that things are robustly handled. Taking fields from CSRs is, while convenient, incredibly dangerous, and the reliance on human controls is, as noted above, challenging to say the least.

Similarly, a description of what fields from the CSR are extracted, how they are mapped into the final certificate, and illustrations of the checks being provided (e.g. sample test cases) also go to help demonstrate that the ARMA system is truly robust for this, and that these examples were truly exceptional.

With respect to training and awareness, please also see https://bugzilla.mozilla.org/show_bug.cgi?id=1551363#c3 for additional thoughts and perspectives with respect to the appropriateness of RA training, and how to move from reactive to systemic approaches. This will, in turn, lead to a more holistic set of next steps for this incident.

Comment 10

[Melis Şimşek]

(In reply to Ryan Sleevi from comment #9)

Based on the level of detail provided, I still remain concerned about the flow of information to the CSR, through to ARMA, and in to the certificate.

This incident demonstrates that it is wholly reasonable to be concerned that an RA personnel may fail to detect the existence of an O=Apple, Inc. field, just as they clearly failed to detect the existence of a ST=Some-State field. It does not describe how, for example, a CSR with CN=sleevi.com+CN=sleevi.net will be handled (note, that syntax is the LDAP stringified form of an RDN SET with two values)

This incident occurred in 2017. Since 2018, it has been aimed to prevent a similar situation by assigning 3 RA personnel in the identification and address verification phase.

In the spirit of wanting to ensure robust mitigations and controls are in place, a possible next step in the incident response is to request CSRs demonstrating some of the sample test cases ARMA currently handles, as well as sample CSRs described in Comment #6 and how the existing system addresses them. The goal here is to provide assurance that things are robustly handled. Taking fields from CSRs is, while convenient, incredibly dangerous, and the reliance on human controls is, as noted above, challenging to say the least.

Let us share sample test cases that ARMA can overcome.

• Sample Test Case 1: CSR file successfully passed all checks

• Sample Test Case 2: CSR file that includes givenName in the Subject field (example of additional field check)

  According to CA/B BR Section 7.1.4.2.2, a Certificate containing a subject:givenName field or subject:surname field MUST contain EV Policy OID. Since we issue OV, the givenName field is prohibited.

• Sample Test Case 3: CSR file that does not include organizationName in the Subject field (example of improper combinations of OV Subject DN fields check)

  According to CA/B BR Section 7.1.6.1, if the certificate asserts the policy identifier of OV Policy OID, then it MUST include organizationName field.

• Sample Test Case 4: CSR file that includes comma separated domainNames in the commonName

  According to, CA/B BR Section 7.1.4.2.2, commonName field MUST contain a single IP address or Fully-Qualified Domain Name.

• Sample Test Case 5: CSR file that includes multiple commonNames in the Subject field

• Sample Test Case 6: CSR file that includes 1024 bit RSA public key

  According to CA/B BR Section 6.1.5, minimum RSA modulus size MUST be 2048 bit.

• Sample Test Case 7: CSR file that includes Debian Weak Key

  According to CA/B BR Section 6.1.1.3, The CA SHALL reject a certificate request if the requested (such as a Debian weak key).

The corresponding screenshots of the ARMA’s validation interface and the CSRs are attached as a file named ARMATestCases.rar. The names of screenshots and CSRs has the the same with test cases.

Similarly, a description of what fields from the CSR are extracted, how they are mapped into the final certificate, and illustrations of the checks being provided (e.g. sample test cases) also go to help demonstrate that the ARMA system is truly robust for this, and that these examples were truly exceptional.

ARMA performs the necessary checks by taking the subject fields and public key information from the CSR. ARMA controls the subject field and allows only CN, O, OU, C, L, ST values to be included if these values are compliant and properly encoded. GivenName, surName, postalCode, and streetAddress are not allowed. If one of these fields are included in the CSR, they are parsed by ARMA and marked with red to indicate an error. ARMA also controls the public key size/algorithm and allows only RSA 2048 or higher, ECC NIST P-256, P-384, and P-521 key sizes. In addition, ARMA shows an error if the CSR has Debian weak public key.

With respect to training and awareness, please also see https://bugzilla.mozilla.org/show_bug.cgi?id=1551363#c3 for additional thoughts and perspectives with respect to the appropriateness of RA training, and how to move from reactive to systemic approaches. This will, in turn, lead to a more holistic set of next steps for this incident.

Comment 11

[Melis Şimşek]

Attachment: ARMATestCases.rar

Comment 12

[Melis Şimşek]

The following controls on the CSR subject field have been added to the ARMA program.

• “ST (State or Province)” field must be present and must contain province information.
• “L (Locality)” field is optional. If present, it must contain locality information belongs to the province which is stated in the ST field.

The remediation has been completed.

Comment 13

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.