1390991 - Disig: Non-BR-Compliant Certificate Issuance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) 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.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Comment 1

[Peter Miskovic]

Hi Kathleen,
sorry for delay, but we were waiting for our client with issuing a new correct SSL certificate to not discontinue using its webmail server.

Here are answers on your questions:

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.

Answer: First time was CA informed about this via bug 1390991 e-mail notification obtained yesterday August 16, 2017 at 20:10 CET.

 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.

Answer: Our CA issued only one certificate with the listed problem and we can confirm you that this will not happened again. 

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.

Answer: There is no more issued certificates by our system with the listed problem.

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
Answer: 1 certificate, 22.11.2016

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.

Answer: The mistake was made by our internal staff during the issuing of certificate. The internal RA worker overlooked that in the SAN of issued certificate is the prohibited .local address. Our system  at that time was not able automatically caught such problem.

6) 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.

Answer: At first we immediately instruct our internal staff who are only able to issue SSL certificates from our system about non-compliant certificate issuance and we requested them to strictly follow our CP and CPS to be aware of such not conforming certificate issuing.

Then after issuing a new(correct) certificate for our client we revoked non conforming certificate - see our current CRL list at http://cdn.disig.sk/subcar2i2/crl/subcar2i2.crl; serialNumber of certificate is ‎0c698a1c0ab7689c69000000000000017f and revocation date August 17,2017, 12:21:31 GMT

Next step for ensure that such issuance will not be repeated in the future:
a) On the RA system we will add the automatic control which ensure to not accept request with the ".local" in the CN or SAN. We are not issuing SSL certificate for an IP address. This will be done today August, 17 to the end of the working day.
b) On the CA system we will add an another notification about issued SSL certificates which will contain all necessary information for the its correctness - nor later then to the next regular audit which is planned on October 2017.

Peter Miskovic
CA Chief  Operating Officer

Comment 2

[Jonathan Rudenberg]

(In reply to Peter Miskovic from comment #1)
> 1) How your CA first became aware of the problems listed below (e.g. via a
> Problem Report, via the discussion in mozilla.dev.security.policy, or via
> this Bugzilla Bug), and the date.
> 
> Answer: First time was CA informed about this via bug 1390991 e-mail
> notification obtained yesterday August 16, 2017 at 20:10 CET.

I emailed a problem report about this certificate, can you please investigate and explain why it was not received?

Here are the relevant message headers:

  From: Jonathan Rudenberg <[e-mail]>
  Subject: Misissuance - invalid dnsNames 
  Message-Id: <[e-mail]>
  Date: Sun, 13 Aug 2017 00:41:48 -0400
  To: [e-mail]

Comment 3

[Peter Miskovic]

(In reply to Jonathan Rudenberg from comment #2)

Hi Jonathan,
we did an investigation with our administrators today morning and we found that the problem was on our site. My computer was moving to the new domain a week ago and there was problem with the mailing distribution group ([e-mail]) which was not properly migrated, so the e-mail you sent was trapped at the old domain. We find your e-mail only today during the investigation. Our administrator immediately resolved the problem with this distribution group e-mail, so now you can rich me also during this [e-mail] e-mail address.

Comment 4

[Peter Miskovic]

We did an RA system upgrade which I mentioned on point 6 a) of my answer. There is automatic control at our RA system, now, which refuse all certificate request which will contain a string ".local" in the DN or SAN field.

Comment 5

[Ryan Sleevi]

Thanks for responding. I think it's still necessary to provide additional detail.

That is, we can look at the problem from two dimensions: The problem itself, and the systemic issues that allowed the problem to manifest. Your description focuses on the resolution of the problem, but doesn't indicate any systemic changes have been made. As a consequence, it does not help the community feel that your CA has taken steps to reduce the risk of future violations (of any requirement) in the future. That is, one dimension is "Did you fix the bug", but another dimension is "How was the bug introduced, why was it not detected, and what steps are you taking to prevent future bugs"

To understand how you might approach this problem, consider https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were already in place (and with substantial detail), where there were controls missing or mistakes made, details about the steps being taken (e.g. "We fixed the bug" is not sufficient detail to understand), and a holistic, systemic awareness of how the CA is managed and the opportunities for errors.

Specific to this issue:
- Comment #3 indicates that there were systemic issues with your migration that disrupted the availability of your error reporting system. Can you clarify:
  - Were any other reports missed?
  - In the event of future system configurations, have you put into place any monitoring systems to ensure that your CAs problem reporting mechanism remains functional and correctly configured (e.g. in the event of a more serious revocation)
  - Have you updated CCADB to ensure a robust set of methods for contact?
- Based on your replies to Comments #5 and #6, it sounds like a significant amount of your system is reliant on RA workers to properly adhere to your CP/CPS. A quick glance at your CP indicates that it's 63 pages, while your CPS is 52 pages. That sounds like a substantial amount of information for your workers to internalized, and may present future challenges as you update your CP/CPS to comply with changes in the ecosystem, such as the Baseline Requirements and Mozilla Policy.
  - Do you have automated systems in place to ensure conformance to RFC 5280?
  - Do you have automated systems in place to ensure compliance with the Baseline Requirements?
  - Do you have automated systems in place to prevent issuance that violates your CP/CPS?
    - Notably, you indicated at the RA system to reject this, rather than the CA system. If the controls fail at the RA, is there any system to ensure robustness in the issuing pipeline?
  - If you lack automated controls, do you plan to deploy them? What type of controls, and when?
  - If you have automated controls, as comment 6 implies, why did these automated controls not consider?
- Your reply indicates '.local' was specially handled, but that's insufficient to mitigate this issue. The Baseline Requirements require the CA ensure that the domain itself is appropriately delegated via IANA or ICANN, and that the requestor is authorized. .local is but one permutation of millions of possible invalid gTLDs, so a better mitigation is to ensure that the domain is within the root zone database and appropriately delegated (for example)
- I'm uncertain the changes you're making at your CA end. Could you explain them in greater detail?
- Notably, it's not possible for you to have validated "gnoma.local" in a way that complies with the Baseline Requirements. This incident calls into question how Disig validates domain names within the certificates it issues, and what technical controls exist to ensure that all domains are appropriately vetted.
  - Can you please describe how you validate domains, and how your system(s) ensure they are appropriately validated? How much control does the RA have with respect to the final certificate's SANs? How was it possible for a request to .local make it through - that is, did your RA manually enter this domain, or was it copied over, such as from the certificate request?

Thank you for your time and responsiveness to this issue.

Comment 6

[Peter Miskovic]

(In reply to Ryan Sleevi from comment #5)
Hi Ryan,
thank you for response. I'll try to answer your comments, questions directly in your text.
If I'm missing something, please let me know.
Peter


> Thanks for responding. I think it's still necessary to provide additional
> detail.
> 
> That is, we can look at the problem from two dimensions: The problem itself,
> and the systemic issues that allowed the problem to manifest. Your
> description focuses on the resolution of the problem, but doesn't indicate
> any systemic changes have been made. As a consequence, it does not help the
> community feel that your CA has taken steps to reduce the risk of future
> violations (of any requirement) in the future. That is, one dimension is
> "Did you fix the bug", but another dimension is "How was the bug introduced,
> why was it not detected, and what steps are you taking to prevent future
> bugs"
> 
> To understand how you might approach this problem, consider
> https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/
> W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were
> already in place (and with substantial detail), where there were controls
> missing or mistakes made, details about the steps being taken (e.g. "We
> fixed the bug" is not sufficient detail to understand), and a holistic,
> systemic awareness of how the CA is managed and the opportunities for errors.
> 
Timeline of events we did after notification about issuing non-conforming SSL certificate
(All time are Central European Time (CET) which is +2 hour of UTC now):

August 16, 2017 20:10 
I received post to my Disig personal account 
([e-mail]) from [e-mail] about Disig: 
Non-BR-Compliant Certificate Issuance. 

START INCIDENT 
August 16, 2017 20:15 
I double-checked if we really issued Non-BR-Compliant 
Certificate - confirmed. 

August 17, 2017 07:30 
As a member of CA Disig Policy management Authority 
(PMA) I started to investigate the issue. 

August 17, 2017 07:35 
Checking all issued SSL certificate in CA DB if 
there is another SSL Non-BR Compliant certificate - negative result. 

August 17, 2017 08:00 
Investigate with the person responsible for the issuing Non-BR Compliant 
certificate that such certificate was issued and ask detail about 
issuing process - confirming failure in following our internal procedure 
concerning issuing SSL certificates. 

August 17, 2017 08:10 
Instruction to all person who can initiate issuing SSL certificate 
to strictly follow our CPS and consult with me all request concerning 
issuing SSL certificates, mainly SSL with multiply FQDN in SAN. 

August 17, 2017 08:10 
Decision to immediately contact certificate 
Subscriber to inform him about situation and ask him to generate a new 
key pair and certificate request for issuing a new correct certificate 
that we have to revoked Non-BR-Compliant one. 

August 17, 2017 09:00 - 09:30 
Investigate with our administrators the problem with 
not receiving e-mail sent to [e-mail] - finding problem 
that e-mail was come to the old domain but in meanwhile my computer 
and e-mail account was moved to the new domain without migration of this 
[e-mail] group e-mail account settings; 

August 17, 2017 09:30 - 10:00 
Consulting with our development team why implemented correction measure 
on the RA/CA site (black list) not prevent issuing such Non-BR-Compliant 
certificate - finding that in the black list string ".local" is missing -
correction action - not accepting certificate request containing string 
".local" - correction action suggestion: adding this string to "black list".

August 17, 2017 10:16
Asking to change setting of tspnotify@disig gropu e-mail such way that 
I will be able to receive e-mail sent to this group.
Ask for addition three more person to this group e-mail account 
to be sure, that in the future will be more receiver for 
notification about potential problem with our SSL certificates.

August 17, 2017 12:16
Checking ability to receive e-mail sent from outside to the [e-mail] - 
test e-mail received.

August 17, 2017 14:21
Continue consultancy with the developers team why implemented correction measure 
on the RA/CA site (black list) not prevent issuing such Non-BR-Compliant 
certificate - finding that 


August 17, 2017 14:21
Revocation of Non-BR-Compliant certificate issued to webmail.gnoma.sk.

August 17, 2017 15:30
First correction action implemented to our production system - 
not accepting certificate request containing string ".local"


> Specific to this issue:
> - Comment #3 indicates that there were systemic issues with your migration
> that disrupted the availability of your error reporting system. Can you
> clarify:
>   - Were any other reports missed?

Disig: We checked our web server logs and we didn't find any other post sent 
to the [e-mail]

>   - In the event of future system configurations, have you put into place
> any monitoring systems to ensure that your CAs problem reporting mechanism
> remains functional and correctly configured (e.g. in the event of a more
> serious revocation)

Disig: According your suggestion in this comment we set up today a monitoring process 
through which we can monitor if the [e-mail] is available for receiving
possible reports.

>   - Have you updated CCADB to ensure a robust set of methods for contact?

Disig: Our management decided to add to the CCADB also our corporate e-mail address
[e-mail] as a notification address.

> - Based on your replies to Comments #5 and #6, it sounds like a significant
> amount of your system is reliant on RA workers to properly adhere to your
> CP/CPS. A quick glance at your CP indicates that it's 63 pages, while your
> CPS is 52 pages. That sounds like a substantial amount of information for
> your workers to internalized, and may present future challenges as you
> update your CP/CPS to comply with changes in the ecosystem, such as the
> Baseline Requirements and Mozilla Policy.
>   - Do you have automated systems in place to ensure conformance to RFC 5280?

Disig: Our procedure at RA is really based on RA workers because we issued SSL certificates 
only after personal identification and authentication of subscriber representative 
at our office. As concerning conformance to RFC5280 RA workers are responsible only 
for adding personal data of subscriber representative to our system and for manually adding
(copy/paste) FQDN to be part of SAN of the issuing certificate. The subject data 
are taken from signed certificate request (#PKCS10) which can't be edited. 
Also they are not able to change any other part of certificate 
which is configured and constructed according the profile configuration of our 
CA server side. 
So my answer is "YES" except FQDN in the SAN.

>   - Do you have automated systems in place to ensure compliance with the
> Baseline Requirements?

Disig: see previous answer

>   - Do you have automated systems in place to prevent issuance that violates
> your CP/CPS?

Disig: We do our best and I think that setting of our system in most cases prevent 
issuance that violates CP/CPS, but we see that there is exception.

>     - Notably, you indicated at the RA system to reject this, rather than
> the CA system. If the controls fail at the RA, is there any system to ensure
> robustness in the issuing pipeline?

Disig: As concerning this BR non compliance there is no controls on CA site now.
The  control (black list) is on the RA servers side (there is client - server 
architecture for RA). We think that adding the ".local" to that black list will 
prevent issuing Non-BR-Compliant certificate of this type.
On the CA side we decided to implement one new notification system about 
issued SSL certificates, through which we will be able to check all issued SSL 
certificate before they delivery to the Subscriber. Implementation of this 
control need more time but we hope we will be able to have it to next regular 
audit in October 2017.

>   - If you lack automated controls, do you plan to deploy them? What type of
> controls, and when?

Disig: see previous answer

>   - If you have automated controls, as comment 6 implies, why did these
> automated controls not consider?

Disig: Because of lack ".local" in black list.

> - Your reply indicates '.local' was specially handled, but that's
> insufficient to mitigate this issue. The Baseline Requirements require the
> CA ensure that the domain itself is appropriately delegated via IANA or
> ICANN, and that the requestor is authorized. .local is but one permutation
> of millions of possible invalid gTLDs, so a better mitigation is to ensure
> that the domain is within the root zone database and appropriately delegated
> (for example)

Disig: You are right. We had a discussion to have white list instead of black list,
but the decision was not taken till now.

> - I'm uncertain the changes you're making at your CA end. Could you explain
> them in greater detail?
> - Notably, it's not possible for you to have validated "gnoma.local" in a
> way that complies with the Baseline Requirements. This incident calls into
> question how Disig validates domain names within the certificates it issues,
> and what technical controls exist to ensure that all domains are
> appropriately vetted.
>   - Can you please describe how you validate domains, and how your system(s)
> ensure they are appropriately validated? How much control does the RA have
> with respect to the final certificate's SANs? How was it possible for a
> request to .local make it through - that is, did your RA manually enter this
> domain, or was it copied over, such as from the certificate request?
> 
Disig:
The vetting procedure is as follows:
1) The Subscriber shall send a certificate request via e-mail to our RA before 
visiting RA for certificate issuing.
2) RA worker is required to open the request and check if the format and content 
of request is in conformance with our CP and check the FQDN in CN field
of request.
3) Then RA worker shall check the registrar of the requested domain and look 
who is representative of the domain owner or is listed as a contact person 
for that domain. Also if there is application from subscriber to put more FQDN to  
the SAN extension the process of checking of representative is the same for such FQDN.
4) Then there is replay to the e-mail from which the request was send with the complete 
instruction about procedure of SSL certificate issuing - we expect that at issuing 
will be as a attender one person from registrar record(s) or person who has a power of 
attorney to act behalf of such person(s).
5) Subscriber also shall provide the RA workers with the written declaration about 
control over all FQDN introduces in certificate request or requested FQDN to be in 
the SAN extensions. Signature on the declaration shall be legalized by the notary.
5) SSL certificate is issuing during the presence of authorized person (see point 4) at 
the RA office where RA check personal documents of authorized person and also 
check submitted power off attorney. 
6) If all control are finished and there is no finding for refusing issuing, request 
is send from RA client via RA server to the CA server where certificate is automatically 
issued and accessible for RA worker.

You are right that for this Non-BR-Compliant certificate issuing there was omitting 
from RA worker to check "gnoma.local" because of overlooking, careless ... difficult 
to say today.

> Thank you for your time and responsiveness to this issue.

Comment 7

[Ryan Sleevi]

(In reply to Peter Miskovic from comment #6)

Thanks for continuing to provide detailed answers that help understand the systems and mitigations Disig has in place, and the opportunity to consider improvements to those, in light of this issue.

> > - Based on your replies to Comments #5 and #6, it sounds like a significant
> > amount of your system is reliant on RA workers to properly adhere to your
> > CP/CPS. A quick glance at your CP indicates that it's 63 pages, while your
> > CPS is 52 pages. That sounds like a substantial amount of information for
> > your workers to internalized, and may present future challenges as you
> > update your CP/CPS to comply with changes in the ecosystem, such as the
> > Baseline Requirements and Mozilla Policy.
> >   - Do you have automated systems in place to ensure conformance to RFC 5280?
> 
> Disig: Our procedure at RA is really based on RA workers because we issued
> SSL certificates 
> only after personal identification and authentication of subscriber
> representative 
> at our office. As concerning conformance to RFC5280 RA workers are
> responsible only 
> for adding personal data of subscriber representative to our system and for
> manually adding
> (copy/paste) FQDN to be part of SAN of the issuing certificate. The subject
> data 
> are taken from signed certificate request (#PKCS10) which can't be edited. 
> Also they are not able to change any other part of certificate 
> which is configured and constructed according the profile configuration of
> our 
> CA server side. 
> So my answer is "YES" except FQDN in the SAN.

You mentioned that subject data is taken from the PKCS#10 CSR. One mistake seen in other CAs is a direct copy of this data, in a way that may represent a non-compliance issue. 

For example, https://tools.ietf.org/html/rfc5280#section-4.1.2.6 outlines that for DirectoryString subject types, conforming CAs MUST use PrintableString or UTF8String encoding. Does your system ensure that the CSR data that is copied complies with this requirements, and/or that any exceptions are reviewed by the policy team to ensure that one of the noted exceptions apply?

> >   - Do you have automated systems in place to ensure compliance with the
> > Baseline Requirements?
> 
> Disig: see previous answer

In this context, given that your policy authority configures the certificate profile, an example may be that your profile is examined with appropriate tools (such as certlint/cablint) prior to enabling that profile.

Similarly, given your description of the copy/paste for FQDNs, that you have systems in place to ensure the well-formedness of these FQDNs.

Given the Baseline Requirements upcoming requirement to check CAA next month, having automated checks around the FQDN seem like an easily implemented mitigation in the process of implementing CAA support. Such support would include ensuring compliance with RFC 5280 Section 4.2.1.6's requirements on the contents of dNSName subjectAltNames, the Baseline Requirements' requirements around wildcards (and reserved and local IP addresses), and, of course, CAA checking.

> >     - Notably, you indicated at the RA system to reject this, rather than
> > the CA system. If the controls fail at the RA, is there any system to ensure
> > robustness in the issuing pipeline?
> 
> Disig: As concerning this BR non compliance there is no controls on CA site
> now.
> The  control (black list) is on the RA servers side (there is client -
> server 
> architecture for RA). We think that adding the ".local" to that black list
> will 
> prevent issuing Non-BR-Compliant certificate of this type.
> On the CA side we decided to implement one new notification system about 
> issued SSL certificates, through which we will be able to check all issued
> SSL 
> certificate before they delivery to the Subscriber. Implementation of this 
> control need more time but we hope we will be able to have it to next
> regular 
> audit in October 2017.

This sounds like a positive improvement, but note that, regardless of delivery to the subscriber, the act of signing an improper certificate is still considered misissuance. You may wish to consider implementing pre-issuance checks, as several CAs have begun doing (PKIoverheid, Comodo, and Symantec all come to mind of recent), and you can see more details at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4

> > - I'm uncertain the changes you're making at your CA end. Could you explain
> > them in greater detail?
> > - Notably, it's not possible for you to have validated "gnoma.local" in a
> > way that complies with the Baseline Requirements. This incident calls into
> > question how Disig validates domain names within the certificates it issues,
> > and what technical controls exist to ensure that all domains are
> > appropriately vetted.
> >   - Can you please describe how you validate domains, and how your system(s)
> > ensure they are appropriately validated? How much control does the RA have
> > with respect to the final certificate's SANs? How was it possible for a
> > request to .local make it through - that is, did your RA manually enter this
> > domain, or was it copied over, such as from the certificate request?
> > 
> Disig:
> The vetting procedure is as follows:
> 1) The Subscriber shall send a certificate request via e-mail to our RA
> before 
> visiting RA for certificate issuing.
> 2) RA worker is required to open the request and check if the format and
> content 
> of request is in conformance with our CP and check the FQDN in CN field
> of request.
> 3) Then RA worker shall check the registrar of the requested domain and look 
> who is representative of the domain owner or is listed as a contact person 
> for that domain. Also if there is application from subscriber to put more
> FQDN to  
> the SAN extension the process of checking of representative is the same for
> such FQDN.

Given that this represents a potentially error prone step, have you considered using one of the automated methods permitted and described by Section 3.2.2.4 of the Baseline Requirements, which allow technical validation without the need for copy/paste or other form of human transcription? This would help minimize any errors.

> 4) Then there is replay to the e-mail from which the request was send with
> the complete 
> instruction about procedure of SSL certificate issuing - we expect that at
> issuing 
> will be as a attender one person from registrar record(s) or person who has
> a power of 
> attorney to act behalf of such person(s).
> 5) Subscriber also shall provide the RA workers with the written declaration
> about 
> control over all FQDN introduces in certificate request or requested FQDN to
> be in 
> the SAN extensions. Signature on the declaration shall be legalized by the
> notary.

This sounds like you primarily rely on Domain Authorization Documents (3.2.2.4.5 of the Baseline Requirements). Given the substantial risk these may pose, both with respect to human error and misrepresentation, it's strongly preferred to use other forms of name validation.

This is an opportunity to consider future (automated) investment. That's not to say that the Baseline Requirements presently prevent this, and it may be that this is an important requirement of your CP/CPS to serve your user population. However, it would be wise to _also_ consider a technical demonstration of proof of control (which can be technically validated, and thus, automated), which can provide more robust assurance of authorization and prevention of such human error.



Overall, it sounds like there's no further information on this specific issue, but there are further action items:
- Implement a blacklist of TLDs. ETA - today.
- Implement a whitelist of TLDs in a manner consistent with the Baseline Requirements. ETA - ?
- (Implement controls to validate conformance to RFC5280 for the FQDNs)
- Implement post-issuance checks into your system for compliance. ETA October, 2017.
- (Implement pre-issuance checks into your system for compliance)

With () being suggested improvements to your overall plan.

Comment 8

[Peter Miskovic]

Comment # 7 on Bug 1390991 from Ryan Sleevi at 2017-08-18 13:02:32 PDT 
(In reply to Peter Miskovic from comment #6)

Thanks for continuing to provide detailed answers that help understand the
systems and mitigations Disig has in place, and the opportunity to consider
improvements to those, in light of this issue.

Disig: Ryan, thanks for additional comments and ideas for improvement. It's very 
helpful. My other comments are in text next to yours comments.
Peter

> > - Based on your replies to Comments #5 and #6, it sounds like a significant
> > amount of your system is reliant on RA workers to properly adhere to your
> > CP/CPS. A quick glance at your CP indicates that it's 63 pages, while your
> > CPS is 52 pages. That sounds like a substantial amount of information for
> > your workers to internalized, and may present future challenges as you
> > update your CP/CPS to comply with changes in the ecosystem, such as the
> > Baseline Requirements and Mozilla Policy.
> >   - Do you have automated systems in place to ensure conformance to RFC 5280?
> 
> Disig: Our procedure at RA is really based on RA workers because we issued
> SSL certificates 
> only after personal identification and authentication of subscriber
> representative 
> at our office. As concerning conformance to RFC5280 RA workers are
> responsible only 
> for adding personal data of subscriber representative to our system and for
> manually adding
> (copy/paste) FQDN to be part of SAN of the issuing certificate. The subject
> data 
> are taken from signed certificate request (#PKCS10) which can't be edited. 
> Also they are not able to change any other part of certificate 
> which is configured and constructed according the profile configuration of
> our 
> CA server side. 
> So my answer is "YES" except FQDN in the SAN.

You mentioned that subject data is taken from the PKCS#10 CSR. One mistake seen
in other CAs is a direct copy of this data, in a way that may represent a
non-compliance issue. 

For example, https://tools.ietf.org/html/rfc5280#section-4.1.2.6 outlines that
for DirectoryString subject types, conforming CAs MUST use PrintableString or
UTF8String encoding. Does your system ensure that the CSR data that is copied
complies with this requirements, and/or that any exceptions are reviewed by the
policy team to ensure that one of the noted exceptions apply?

	Disig: My previous answer was simplified (probably too much). We are not directly 
	copying subject from certification request, but rebuilding it while closely 
	following encoding rules from RFC5280.

> >   - Do you have automated systems in place to ensure compliance with the
> > Baseline Requirements?
> 
> Disig: see previous answer

In this context, given that your policy authority configures the certificate
profile, an example may be that your profile is examined with appropriate tools
(such as certlint/cablint) prior to enabling that profile.

	Disig: Thank you to pointing on this. We installed and tested both today afternoon.

Similarly, given your description of the copy/paste for FQDNs, that you have
systems in place to ensure the well-formedness of these FQDNs.

	Disig: The manual copy/paste is only solution for us now due to system design.
	On base of your suggestion we started discussion how to change design of our 
	system to remove manual copy/paste for FQDNs in SAN.
	 

Given the Baseline Requirements upcoming requirement to check CAA next month,
having automated checks around the FQDN seem like an easily implemented
mitigation in the process of implementing CAA support. Such support would
include ensuring compliance with RFC 5280 Section 4.2.1.6's requirements on the
contents of dNSName subjectAltNames, the Baseline Requirements' requirements
around wildcards (and reserved and local IP addresses), and, of course, CAA
checking.
	
> >     - Notably, you indicated at the RA system to reject this, rather than
> > the CA system. If the controls fail at the RA, is there any system to ensure
> > robustness in the issuing pipeline?
> 
> Disig: As concerning this BR non compliance there is no controls on CA site
> now.
> The  control (black list) is on the RA servers side (there is client -
> server 
> architecture for RA). We think that adding the ".local" to that black list
> will 
> prevent issuing Non-BR-Compliant certificate of this type.
> On the CA side we decided to implement one new notification system about 
> issued SSL certificates, through which we will be able to check all issued
> SSL 
> certificate before they delivery to the Subscriber. Implementation of this 
> control need more time but we hope we will be able to have it to next
> regular 
> audit in October 2017.

This sounds like a positive improvement, but note that, regardless of delivery
to the subscriber, the act of signing an improper certificate is still
considered misissuance. You may wish to consider implementing pre-issuance
checks, as several CAs have begun doing (PKIoverheid, Comodo, and Symantec all
come to mind of recent), and you can see more details at
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4

	Disig: Thank you for the link. We will definitely look at their solution. 

> > - I'm uncertain the changes you're making at your CA end. Could you explain
> > them in greater detail?
> > - Notably, it's not possible for you to have validated "gnoma.local" in a
> > way that complies with the Baseline Requirements. This incident calls into
> > question how Disig validates domain names within the certificates it issues,
> > and what technical controls exist to ensure that all domains are
> > appropriately vetted.
> >   - Can you please describe how you validate domains, and how your system(s)
> > ensure they are appropriately validated? How much control does the RA have
> > with respect to the final certificate's SANs? How was it possible for a
> > request to .local make it through - that is, did your RA manually enter this
> > domain, or was it copied over, such as from the certificate request?
> > 
> Disig:
> The vetting procedure is as follows:
> 1) The Subscriber shall send a certificate request via e-mail to our RA
> before 
> visiting RA for certificate issuing.
> 2) RA worker is required to open the request and check if the format and
> content 
> of request is in conformance with our CP and check the FQDN in CN field
> of request.
> 3) Then RA worker shall check the registrar of the requested domain and look 
> who is representative of the domain owner or is listed as a contact person 
> for that domain. Also if there is application from subscriber to put more
> FQDN to  
> the SAN extension the process of checking of representative is the same for
> such FQDN.

Given that this represents a potentially error prone step, have you considered
using one of the automated methods permitted and described by Section 3.2.2.4
of the Baseline Requirements, which allow technical validation without the need
for copy/paste or other form of human transcription? This would help minimize
any errors.

	Disig: We are talking about implementing such an automatic control for longer, 
	but at first we need to change our internal procedures for receiving requests 
	from our clients. Our goal is to replace current e-mail communication to the 
	communication via a client portal, where implementing an automated methods will 
	be much easier.

> 4) Then there is replay to the e-mail from which the request was send with
> the complete 
> instruction about procedure of SSL certificate issuing - we expect that at
> issuing 
> will be as a attender one person from registrar record(s) or person who has
> a power of 
> attorney to act behalf of such person(s).
> 5) Subscriber also shall provide the RA workers with the written declaration
> about 
> control over all FQDN introduces in certificate request or requested FQDN to
> be in 
> the SAN extensions. Signature on the declaration shall be legalized by the
> notary.

This sounds like you primarily rely on Domain Authorization Documents
(3.2.2.4.5 of the Baseline Requirements). Given the substantial risk these may
pose, both with respect to human error and misrepresentation, it's strongly
preferred to use other forms of name validation.

This is an opportunity to consider future (automated) investment. That's not to
say that the Baseline Requirements presently prevent this, and it may be that
this is an important requirement of your CP/CPS to serve your user population.
However, it would be wise to _also_ consider a technical demonstration of proof
of control (which can be technically validated, and thus, automated), which can
provide more robust assurance of authorization and prevention of such human
error.

	Disig: See my answer about implementing an automatic control methods.

Overall, it sounds like there's no further information on this specific issue,
but there are further action items:
- Implement a blacklist of TLDs. ETA - today.
	
- Implement a whitelist of TLDs in a manner consistent with the Baseline
Requirements. ETA - September, 2017.
 

- (Implement controls to validate conformance to RFC5280 for the FQDNs)

- Implement post-issuance checks into your system for compliance. 
ETA October, 2017.

- (Implement pre-issuance checks into your system for compliance)

With () being suggested improvements to your overall plan.

________________________________________
Product/Component: NSS :: CA Certificate Mis-Issuance
________________________________________
You are receiving this mail because: 
•	You are the assignee for the bug.

Comment 9

[Ryan Sleevi]

I'm going to mark this as "Needs Info" so that the system will remind you periodically to provide status updates on the progress of the remaining action items - expected in both September and October.

With that said, I think that otherwise completes the discussion.

Comment 10

[Ryan Sleevi]

Can you please provide an update whether you met your stated objectives for September?

- Implementing a Blacklist of TLDs
- Implementing a Whitelist of TLDs in a manner consistent with the Baseline Requirements

Further, are you on track to implement your post-issuance controls for next month?

Comment 11

[Peter Miskovic]

(In reply to Ryan Sleevi from comment #10)
> Can you please provide an update whether you met your stated objectives for
> September?
> 
> - Implementing a Blacklist of TLDs
> - Implementing a Whitelist of TLDs in a manner consistent with the Baseline
> Requirements
> 
> Further, are you on track to implement your post-issuance controls for next
> month?

Implementing a Blacklist of TLDs:

We prepare a new upgrade for our CA software which enables adding a blacklist which will automatically check all certificate request before issuing SSL certificates.  If the content of request is positive to blacklist content issuing of the certificate is refused. As a base of blacklist we used Public Suffix List https://publicsuffix.org/list/public_suffix_list.dat
This upgrade was successfully tested at our developer DB and now we are stage of preparing testing it at our pre-prod DB. If all test scenarios will be done without any serious problem then this upgrade will be deployed to the production.


Implementing a Whitelist of TLDs in a manner consistent with the Baseline Requirements:

As a whitelist we are using regular expression which enables us to check all content of the subject filed in the certificate before sending data to the CA.  
We have whitelist implemented from DigiNotar problem era with, but there was no regular expression for “.local” at the time of issuance of Non-BR-Compliant certificate
This regular expression was now updated (adding “.local”) and moved to DB so we are able to use different white list for different CA’s and check all certificate data before certificate issuing.
The implementation of a new updated whitelist is via upgrade mentioned above.

Comment 12

[Ryan Sleevi]

Please continue to provide regular progress reports. For example, have these changes been deployed into production?

It is important to provide these updates proactively, as it helps the community objectively measure how well the CA responds to incidents and meets stated timelines.

For example, the following remediations were accepted:
- Blacklist, deployed 2017-09
- Post-issuance controls, deployed 2017-10

It's unclear whether these objectives have been met and the remediation is continuing as expected.

Comment 13

[Gervase Markham [:gerv]]

Peter: in comment 12, Ryan requested regular progress reports but nothing has been said for 2 months. Please can you tell us the status of this situation?

Thanks,

Gerv

Comment 14

[Peter Miskovic]

Hi Gerv
sorry for the delay with reporting progress concerning this Non-BR-Compliant issuing.

- Blacklist, deployed 2017-09:
There is a little progress in implementing blacklist due to that together with the blacklist issue we prepared more changes in our CA system and the implementing all to the production system needs more time. I hope that the update of our CA system will be done to the end of this year 2017. 

There is in vetting process manual double control for all SSL certificate request now and we not issuing SSL certificates for a new TLDs.

- Post-issuance controls, deployed 2017-10

There is online notification about all issuance of SSL certificate to myself, so I'm able to recognize if there be some Non-BR-Compliant Certificate Issuance from our CA system. 
After implementing the blacklist, there be impossible to issue SSL certificate from our system, if the Public Suffix will be positively indicated on https://publicsuffix.org/list/public_suffix_list.dat.

To be honest I thing that all the process improvements and implemented measures provides sufficient certainty that such mis- issuance will not happened again.

Regards.
Peter

Comment 15

[Wayne Thayer]

It appears that all actions have been completed and questions answered, so I am marking this resolved.