Dear Mozilla CA Root Team, After reviewing Mr. Gervase's reply, referring to the exclusion of the PSC PROCERT from the Mozilla trust repository and having seen the antecedents existing in multiple previous cases, it is evident that in all cases it was offered through the bug of a mechanism of remediation and the ACs were adequately informed about the open observations and even in some cases are closed with simple statements about how the case is remedied. The technical aspects indicated in the bug and its answers are included below: 1. Serial Number does not meet the standard. RFC 5280, in section 4.1.2.2 states the following: “4.1.2.2. Serial Number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conforming CAs MUST NOT use serialNumber values longer than 20 octets. Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates” In addition, section 7.1 of the BR indicates the following: “Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.” PSC PROCERT works with the Microsoft cryptography service, which has a CSPRNG inside the CryptoAPI library suite, which includes a CryptGenRandom function, which is a cryptographically secure pseudo-random number generator, this function was found by default in the generation of the short serial numbers, therefore we proceeded to modify the registry of the CA and activate the option of high serial, which comes by default deactivated (0), we proceeded to activate this registry, so that serials are generated under the parameters of the standard. In the following link you can see an example of a certificate with the appropriate serial number https://crt.sh/?id=204446748 After this action was taken, we proceeded to recognize the certificates with these problems and were notified to our clients that they should be revoked and reissued, the certificates denounced in the bug are revoked. PSC PROCERT is not the only one to present this case, QuoVadis and SwissSign, presented the same situation and the remediation was accepted. https://bugzilla.mozilla.org/show_bug.cgi?id=1391063 https://bugzilla.mozilla.org/show_bug.cgi?id=1391066 Note that the answers offered by QuoVadis and SwissSign were simple and not detailed; such as those offered by PROCERT, the response and follow-up on compliance was further expanded. We do not understand then why for other cases apply and for PROCERT not ?. 2.- Issues with SSL Certificates Issue D: URI in CN and dnsName SAN (December 2016) Issue G: Internal IP Address in SAN (March 2015 - March 2017) Issue I: CN Not Also In SAN (March 2016 - June 2017) Issue K: Internal DNS Names in Certificates (May - June 2017) Issue L: helloburgershack.com (June - July 2017) 2.1. Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 2015 - August 2017) Taking into account what was stated in the bug, the BR was reviewed and it indicates the following in section 7.1.4.2.2 “j. Other Subject Attributes All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.e.” In addition, section 7.4.2.1 states the following “7.1.4.2.1. Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully‐Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.” In order to remedy this situation, the affected customers were notified that the certificates had to be revoked and issued again, modifying the data with problems, then notified and with the window of time for customers to take these changes into account. level of their systems, the certificates were revoked and issued correctly. To avoid these errors in the future, PSC PROCERT proceeded to modify the CPS and PC, adding a section to inform our customers that any request for SSL certificate must comply with the standard of the CA Browser Forum, also within our system a filter was applied to avoid accepting the following parameters 1. Characters "-", ",", ".", ":", "/", And " " (Issue D) 2. Private IP addresses (Issue G) 3. Domains ending in * .local (Issue K) 4. Character accentuation (eg or) (Issue R) 5. Validator that both the CN and the SAN are the same values (Issue I) In addition to establishing internal review and validation mechanisms with the personnel that analyze the CSR and support our clients. A tool will also be incorporated to automate the analysis of CSRs. Such software is currently being tested in our quality environment to enter production. 2.2. Issue N: Other Names in Certificate SAN (2011 - August 2017 Referring to Issue N, the BR was reviewed and it was found that section 7.1.4.2.2 section i indicates the following “i. Other Subject Attributes All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA.” This indicates that another field can be included as long as it is information verified by the CA, in this case PSC PROCERT verifies the number of RIF that is the tax identification number of company in Venezuela of each company, which by definition is a registry destined to the legal control of taxes and in which natural or juridical persons, communities and entities or groups without legal personality, susceptible by reason of the goods or activities, of being subject or responsible for the Income Tax, the tax retention agents, and residents abroad without permanent establishment or fixed base, provided that the cause of the enrichment is or occurs in Venezuela. In conclusion, it is a requirement of Law in Venezuela and the company that omits to place it is sanctioned. Even PSC PROCERT can be sanctioned by the government in case of failure to include such information in the certificates. Each company that signs a contract with PSC PROCERT must present a copy of the RIF and the same is proceeded to validate against the national tax office, which in the case of Venezuela is SENIAT; The SUSCERTE that is the governing entity that regulates in Venezuela requires that in the structure of the certificate this information is placed in a field of the certificate identified with an OID for this purpose, which is 2.16.862.2. Therefore, it can be concluded that the standard is fulfilled and there is no default as such in Issue N. There are similar cases with accepted remediation CertSign https://bugzilla.mozilla.org/show_bug.cgi?id=1390979 GoDaddy https://bugzilla.mozilla.org/show_bug.cgi?id=1391429 Entrust https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 The responses provided by PSC PROCERT are in line with those provided for similar cases by the CA’s above. 3. Issue T: Inappropriate Key Usage Value of "Key Agreement" (October 2016 - August 2017) Certificates with this Issue were revoked and notified to customers. In order to prevent this situation from being repeated, we proceeded to review the template with which the certificates were issued and the key Agreement was eliminated among the uses, in addition it was enabled so that this option can NOT be used later 4. Issue V: Failure to Respond Quickly To Problem Reports (August 2017) At this point and about the rapid response, we point out that at all times we have demonstrated since we were notified, willingness to solve this problem. Certificates that did not generate impact were automatically revoked. Please find attached our CPS and the evidence of SSL revocation. Please consider this evidence in order to reopen the PSC PROCERT case.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
