Add Asseco DS / Certum root certificates
Categories
(CA Program :: CA Certificate Root Program, task, P1)
Tracking
(Not tracked)
People
(Reporter: wtrapczynski, Assigned: bwilson)
References
Details
(Whiteboard: [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 90)
Attachments
(1 file)
|
553.74 KB,
application/pdf
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Expected results:
This bug requests inclusion in the NSS root store two certificates owned by Asseco Data Systems (Certum):
Common Name: Certum EC-384 CA
SHA256 Fingerpint: 6b328085625318aa50d173c98d8bda09d57e27413d114cf787a0f5d06c030cf6
Common Name: Certum Trusted Root CA
SHA256 Fingerpint: fe7696573855773e37a95e7ad4d9cc96c30157c15d31765ba9b15704e1ae78fd
|
||
Comment 1•5 years ago
|
||
|
||
Comment 2•5 years ago
|
||
The information for this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000519
Please add another comment to this bug when you have completed steps 5 through 8 of
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case
|
Reporter | |
Comment 3•5 years ago
|
||
We became aware that in our audit statements SHA256 Fingerprint of Certum Trusted Root CA certificate is incorrect. We are working with our auditors to resolve this problem. Then, we will finish step 8.
|
|
Reporter | |
Comment 4•4 years ago
|
||
I would like to inform you that we are almost finished our work with auditors to resolve this issue. I will update this bug soon.
|
|
Reporter | |
Comment 5•4 years ago
|
||
The updated audit reports have been published. Then I have completed steps 5 through 8.
|
|
Reporter | |
Updated•4 years ago
|
|
|
||
Comment 6•4 years ago
|
||
Clearing my needinfo, so I stop receiving daily email about this. I do not currently have much bandwidth for looking at root inclusion requests. When I do get the time to do so, I will proceed with reviewing updates to root inclusion request bugs as they came in from CAs. Currently I am 4 months behind.
|
|
Reporter | |
Comment 7•4 years ago
|
||
Kathleen, thank you for that information.
|
|
||
Comment 8•4 years ago
|
||
The information for this root inclusion request is available at the following URL.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000519
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review
It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 9•4 years ago
|
||
Here is a review of the Certum CPS:
Certum CPS - Version 6.8, Dated: 10 November 2020
CCP-DK02-ZK02-Certification-Practice-Statement-of-Certum-Certification-Services_v6.8.pdf
Note that in several places when the PDF was generated it could not find the cross-reference and left the message, "Błąd! Nie można odnaleźć źródła odwołania."
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2) - Good
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3) -Meh
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions) ...”
However, the copyright language in the Certum CPS appears to be overly restrictive. It states:
Hereby Asseco Data Systems S.A. reserves all rights to this publication, products and to any of its parts, in accordance with civil and trade law, particularly in accordance with intellectual property, trademarks and corresponding rights.
Without limiting the rights reserved above, no part of this publication may be reproduced, introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise) or used commercially without prior written permission of Asseco Data Systems S.A.
Notwithstanding the above, permission is granted to reproduce and distribute this document on a nonexclusive, royalty-free basis, provided that the foregoing copyright notice are prominently displayed at the beginning of each copy, and the document is accurately reproduced in full, complete with attribution of the document to Asseco Data Systems S.A.
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) - Good
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
Section 1.4 provides, “In the event of any inconsistency between this document and the CA/B Forum requirements, the requirements take precedence over this document.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Meh
Certum should be aware that Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) - Meh
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
Presumably this can now occur when Certum updates its records in the CCADB.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3) - Meh
“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.
The Certum CPS has a document modification history. Section 9.12 says, “This Certification Practice Statement is reviewed at least annually. Modification to Certification Practice Statement may be a result of observed errors, CPS update and suggestions from the affected parties. However, Certum updates the Certification Practice Statement whenever when the following documents change and changes affect Certum's activities:”
This language doesn’t say that the CPS is updated and re-versioned annually even if there are no changes.
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Bad
“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”
Section 1.3.2 of the CPS does not say that third party RAs may not conduct domain validation.
Section 3.2.2.1 does not make it clear that domain validation is not delegated to third parties.
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Meh
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
In Section 1.5.2, Certum has replaced “For Certificate Problem Reports contact Certum by sending an e-mail to revoke@certum.pl” with “For Certificate Problem Reports contact with Certum by filling the form available on the website: https://www.support.certum.eu/en/cert-process-of-revoking-form-en/ or https://www.certum.pl/pl/cert_wiedza_unizewaznienie_ev/”
Maybe both mechanisms should be offered? However, a lot depends on how an email reporting process is implemented (as well as how well the form-fill process works).
Naming compliant with X.500, RFC5280 and BRs - Meh
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
Section 3.1.1 of the CPS references X.500 standards and RFCs. Certum could add language to make it more clear that it complies with section 9.2 of the EV Guidelines and OV naming requirements found in section 7.1.4.2.2 (Subject Distinguished Name Fields) of the Baseline Requirements.
No internal names or reserved IP addresses (BR § 7.1.4.2.1) - Bad
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
I did not find language prohibiting the issuance of certificates to reserved IP addresses or internal names.
ALL certificates must meet Mozilla/BR validation requirements - Bad
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Section 3.2.2 says, “In the case of certificates issued for devices, authentication may be accomplished by verifying access to the domain placed in the certificate request. Certum may verify the subscriber’s right to use the domain name by the procedure during which some verification element indicated by Certum is placed on destination server or when the Subscriber is required to be able to answer an e-mail sent by Certum to his/her/its address.” This is an insufficient explanation.
Section 3.2.2.1 (Authentication of Domain Name) does not explain how Certum complies with sections 3.2.2.4 and 3.2.2.5 of the Baseline Requirements. They appear to be methods intending to implement BR sections 3.2.2.4.4, 3.2.2.4.6, and 3.2.2.4.7.
Section 3.2.2.1 also says, “For all SSL certificates containing IP address Certum uses one of the above listed verification methods.” However, allowed methods for verifying IP addresses in certificates are listed only in section 3.2.2.5. A separate explanation for those procedures is needed.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2) - Bad
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Section 3.2.2 says, “In the case of email certificates, the registration authority verifies an email address. The aim of this action is to receive by the subscriber an authentication data sent to the address which has previous placed in the certification request.” This is an inadequate explanation. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5) - Meh
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.”
Section 3.2.2 of the Certum CPS states, “The verification is performed based on the Qualified Independent/Government Information Sources e.g. publicly available records of companies/organizations registries. The list of information sources is available in the repository on certum.eu.” It is unclear where the list is located in the repository. It is also unclear how Certum determines that a validation source is a “Reliable Data Source” or a qualified QIIS.
All information in a certificate must be verified (MRSP § 2.2.1) - Good
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
Section 3.2.4 states, “Certum validates all information to be included within the subject DN of a certificate.”
Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1) - Good
CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”.
Section 4.2.2.1 of the CPS states, for websites authentication certificates (except for Premium EV SSL certificates) issued on or after March 1, 2018, Certum MAY use the documents and data provided in Chapter 3.2 to verify certificate information provided that Certum obtained these data or documents no more than 825 days prior to issuing the certificate,”
CAA record checking and recognized domain names in section 4.2 (BR § 2.2)- Good
“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”
Section 4.2.4 of the CPS outlines Certum’s “Certificate Authority Authorization Records Processing”.
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Good
CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.
Section 4.3.1 states, “only persons performing trusted roles have access to operational accounts of the Primary Registration Point. Using the accounts is protected by multi-level authentication and enables the processing of certificate application including the ability to submit an appropriately formatted certificate request to the issuing CA,”
Also, section 6.5.1 is explicit, “Certum enforces multi factor authentication on any account capable of directly causing Certificate issuance.”
Pre-issuance linting (Recommended Practices) - Meh
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Discussion of pre-issuance linting not found in the CPS.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) - Bad
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Section 4.9.1 only contains 4 of the 5 BR-provided reasons for 24-hour revocation. Missing is “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based -on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.
Only 3 reasons are given for revoking the certificate belonging to a CA (not the nine reasons mentioned in section 4.9.1.2 of the Baseline Requirements).
SMIME Reasons for Revocation (MRSP § 6.2) - Bad
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”
Please review MRSP § 6.2 and determine how those revocation reasons can be worked into your CPS.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) - Good
Section 4.9.7 provides, “Every Certificate Revocation List is updated at least once a week.”
Footnote 20 says – “Publication of the succeeding CRL can be also made before this date. In the case of CAs isuuing end-entity certificates, value of this field is set to 10 days.”
CA must not allow certificate suspension (BR § 4.9.13) - Good
According to section 4.9.13, “Certum does not support suspension.”
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6) - Good
Section 4.9.9 states, “Certum provides real-time certificate status verification service. “ and “OCSP response is valid for 7 days.” (However, to reduce OCSP response times, Certum should consider pre-generation of OCSP responses and distribution via CDN.)
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - Meh
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Section 5.7.3 states that Certum carries out its key compromise operations “in accordance with the plan developed by the security incident response team”. That plan should provide that Mozilla is notified immediately whenever a CA key compromise is suspected.
CA must not generate Subscriber key pairs (MRSP § 5.2) - Bad
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Section 4.1.2.1 says “[the] subscriber generates his/her/its key pair by himself/herself/itself. The generation may also be delegated to Certum;”
Section 4.3.1 says, “if the application contains the request for generating of a key pair, the server charges hardware key generator complying with the requirements of at least FIPS 140 Level 3 with this task”
Section 6.1.2 discusses key generation and delivery to subscribers but is silent as to private keys for SSL.
Must meet RSA key requirements (MRSP § 5.1) - Bad
In section 6.1.6, Certum states, “Certum recognizes subscriber's "weak keys" and rejects them before certificate request submission. It is not allowed to accept keys which are not compliant with the Baseline Requirements Section 6.1.6. Person who generate a key is responsible for checking parameter quality of the generated key He/she/it is required to verify:”
This is insufficiently detailed. Certum has responsibilities to check for various key parameters (beyond just weak keys). See sections 6.1.5 and 6.1.6 of the Baseline Requirements.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) - Bad
The Certum CPS does not contain any guidance or practice statement about issuing elliptic-curve certificates. There is, however, mention of P-256 in Table 7.1.
Certificate lifetimes limited to 398 days (BR § 6.3.2) – Bad
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Section 6.3.2 of the CPS still says that the validity period for SSL/TLS server certificates is 825 days.
Network Security (MRSP § 2.1.2) - Meh
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
It is unclear from the network security description in section 6.7 of the CPS whether Certum is following industry best practice for securing its networks.
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2) - Good
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
Section 7.1 states, “(Certum generates non‐sequential certificate serial numbers (positive numbers greater than zero) that contain at least 64 bits of output from a CSPRNG);”
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f) - Meh
Certum should be aware that for SSL/TLS end entity server certificates, they must contain “[e]ither the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values ….”
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1) - Good
CPS does not list SHA1 as an allowed signature Algorithm, except for CRLs (which should probably be eliminated).
Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Good
In Table 7.1 it says, “commonName (in the case of server certificates: contain a single IP address or a domain name that is one of the values contained in the certificate’s subjectAltName extension),”
|
|
Assignee | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 10•4 years ago
|
||
Thank you for your review. We are starting work on it.
|
|
Reporter | |
Comment 11•3 years ago
|
||
Thank you once again for the detailed CPS review. We have published a new version of our CPS 6.9 which fixed all things you marked as “bad” or “meh”. You can download a CPS v6.9 from the URL. Inlined you may find notes for all “bad” or “meh” notes.
(In reply to Ben Wilson from comment #9)
Here is a review of the Certum CPS:
Certum CPS - Version 6.8, Dated: 10 November 2020
CCP-DK02-ZK02-Certification-Practice-Statement-of-Certum-Certification-Services_v6.8.pdf
Note that in several places when the PDF was generated it could not find the cross-reference and left the message, "Błąd! Nie można odnaleźć źródła odwołania."
We fixed it in all places.
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2) - Good
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3) -Meh
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions) ...”
However, the copyright language in the Certum CPS appears to be overly restrictive. It states:
Hereby Asseco Data Systems S.A. reserves all rights to this publication, products and to any of its parts, in accordance with civil and trade law, particularly in accordance with intellectual property, trademarks and corresponding rights.
Without limiting the rights reserved above, no part of this publication may be reproduced, introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise) or used commercially without prior written permission of Asseco Data Systems S.A.
Notwithstanding the above, permission is granted to reproduce and distribute this document on a nonexclusive, royalty-free basis, provided that the foregoing copyright notice are prominently displayed at the beginning of each copy, and the document is accurately reproduced in full, complete with attribution of the document to Asseco Data Systems S.A.
These clauses are a standard for Asseco Data Systems documents. If you wish we can provide equally permissive licensing terms in writing for Mozilla.
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) - Good
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
Section 1.4 provides, “In the event of any inconsistency between this document and the CA/B Forum requirements, the requirements take precedence over this document.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Meh
Certum should be aware that Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
We added to section 7.1.2 information about EKU requirements.
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) - Meh
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
Presumably this can now occur when Certum updates its records in the CCADB.
Correct, this information is in the CCADB.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3) - Meh
“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.
The Certum CPS has a document modification history. Section 9.12 says, “This Certification Practice Statement is reviewed at least annually. Modification to Certification Practice Statement may be a result of observed errors, CPS update and suggestions from the affected parties. However, Certum updates the Certification Practice Statement whenever when the following documents change and changes affect Certum's activities:”
This language doesn’t say that the CPS is updated and re-versioned annually even if there are no changes.
We added to section 9.12 information about needed to update the CPS annually, even if it does not contain any changes,.
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Bad
“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”
Section 1.3.2 of the CPS does not say that third party RAs may not conduct domain validation.
Section 3.2.2.1 does not make it clear that domain validation is not delegated to third parties.
We added to section 3.2.2.1 information that domain validation is not delegated to third parties.
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Meh
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
In Section 1.5.2, Certum has replaced “For Certificate Problem Reports contact Certum by sending an e-mail to revoke@certum.pl” with “For Certificate Problem Reports contact with Certum by filling the form available on the website: https://www.support.certum.eu/en/cert-process-of-revoking-form-en/ or https://www.certum.pl/pl/cert_wiedza_unizewaznienie_ev/”
Maybe both mechanisms should be offered? However, a lot depends on how an email reporting process is implemented (as well as how well the form-fill process works).
We decided to offer the form for Certificate Problem Reports some time ago because we are not able to handle email reporting in the required way. The form should be also a better option in the future when (for example) requests for a certificate key compromise would have to be handled automatically.
Naming compliant with X.500, RFC5280 and BRs - Meh
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
Section 3.1.1 of the CPS references X.500 standards and RFCs. Certum could add language to make it more clear that it complies with section 9.2 of the EV Guidelines and OV naming requirements found in section 7.1.4.2.2 (Subject Distinguished Name Fields) of the Baseline Requirements.
We added to section 3.1.1 information that Certum is compliant with both pointed sections of Baseline Requirements.
No internal names or reserved IP addresses (BR § 7.1.4.2.1) - Bad
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
I did not find language prohibiting the issuance of certificates to reserved IP addresses or internal names.
We added to section 3.2.2.1 information that we do not issue certificates for reserved IP addresses or internal names
ALL certificates must meet Mozilla/BR validation requirements - Bad
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Section 3.2.2 says, “In the case of certificates issued for devices, authentication may be accomplished by verifying access to the domain placed in the certificate request. Certum may verify the subscriber’s right to use the domain name by the procedure during which some verification element indicated by Certum is placed on destination server or when the Subscriber is required to be able to answer an e-mail sent by Certum to his/her/its address.” This is an insufficient explanation.
Section 3.2.2.1 (Authentication of Domain Name) does not explain how Certum complies with sections 3.2.2.4 and 3.2.2.5 of the Baseline Requirements. They appear to be methods intending to implement BR sections 3.2.2.4.4, 3.2.2.4.6, and 3.2.2.4.7.
Section 3.2.2.1 also says, “For all SSL certificates containing IP address Certum uses one of the above listed verification methods.” However, allowed methods for verifying IP addresses in certificates are listed only in section 3.2.2.5. A separate explanation for those procedures is needed.
We added to section 3.2.2.1 extended information about methods of domain validation and separately about validation methods of IP addresses.
We removed from section 3.2.2 information about validation rules for certificates issued for devices. We no longer issue such certificates.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2) - Bad
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Section 3.2.2 says, “In the case of email certificates, the registration authority verifies an email address. The aim of this action is to receive by the subscriber an authentication data sent to the address which has previous placed in the certification request.” This is an inadequate explanation. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response
We added to section 3.2.2 a better explanation of e-mail address validation process.
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5) - Meh
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.”
Section 3.2.2 of the Certum CPS states, “The verification is performed based on the Qualified Independent/Government Information Sources e.g. publicly available records of companies/organizations registries. The list of information sources is available in the repository on certum.eu.” It is unclear where the list is located in the repository. It is also unclear how Certum determines that a validation source is a “Reliable Data Source” or a qualified QIIS.
We added to section 3.2.2 information about how Certum determines the reliability of sources. Additionally, we added a direct link to validation sources in our repository.
All information in a certificate must be verified (MRSP § 2.2.1) - Good
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
Section 3.2.4 states, “Certum validates all information to be included within the subject DN of a certificate.”
Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1) - Good
CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”.
Section 4.2.2.1 of the CPS states, for websites authentication certificates (except for Premium EV SSL certificates) issued on or after March 1, 2018, Certum MAY use the documents and data provided in Chapter 3.2 to verify certificate information provided that Certum obtained these data or documents no more than 825 days prior to issuing the certificate,”
CAA record checking and recognized domain names in section 4.2 (BR § 2.2)- Good
“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”
Section 4.2.4 of the CPS outlines Certum’s “Certificate Authority Authorization Records Processing”.
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Good
CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.
Section 4.3.1 states, “only persons performing trusted roles have access to operational accounts of the Primary Registration Point. Using the accounts is protected by multi-level authentication and enables the processing of certificate application including the ability to submit an appropriately formatted certificate request to the issuing CA,”
Also, section 6.5.1 is explicit, “Certum enforces multi factor authentication on any account capable of directly causing Certificate issuance.”
Pre-issuance linting (Recommended Practices) - Meh
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Discussion of pre-issuance linting not found in the CPS.
We added to section 4.3.1 information about pre-issuance linting.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) - Bad
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Section 4.9.1 only contains 4 of the 5 BR-provided reasons for 24-hour revocation. Missing is “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based -on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.
Only 3 reasons are given for revoking the certificate belonging to a CA (not the nine reasons mentioned in section 4.9.1.2 of the Baseline Requirements).
We added to section 4.9.1 all remaining reasons for revocation.
SMIME Reasons for Revocation (MRSP § 6.2) - Bad
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”
Please review MRSP § 6.2 and determine how those revocation reasons can be worked into your CPS.
We added to section 4.9.1 revocation reasons for S/MIME certificates also.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) - Good
Section 4.9.7 provides, “Every Certificate Revocation List is updated at least once a week.”
Footnote 20 says – “Publication of the succeeding CRL can be also made before this date. In the case of CAs isuuing end-entity certificates, value of this field is set to 10 days.”
CA must not allow certificate suspension (BR § 4.9.13) - Good
According to section 4.9.13, “Certum does not support suspension.”
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6) - Good
Section 4.9.9 states, “Certum provides real-time certificate status verification service. “ and “OCSP response is valid for 7 days.” (However, to reduce OCSP response times, Certum should consider pre-generation of OCSP responses and distribution via CDN.)
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - Meh
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Section 5.7.3 states that Certum carries out its key compromise operations “in accordance with the plan developed by the security incident response team”. That plan should provide that Mozilla is notified immediately whenever a CA key compromise is suspected.
We added to section 5.7.3 information about the obligation to inform certificate consumers immediately after detection of a security incident.
CA must not generate Subscriber key pairs (MRSP § 5.2) - Bad
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Section 4.1.2.1 says “[the] subscriber generates his/her/its key pair by himself/herself/itself. The generation may also be delegated to Certum;”
Section 4.3.1 says, “if the application contains the request for generating of a key pair, the server charges hardware key generator complying with the requirements of at least FIPS 140 Level 3 with this task”
Section 6.1.2 discusses key generation and delivery to subscribers but is silent as to private keys for SSL.
We added to sections 4.1.2.1, 4.3.1 and 6.1.2 information that Certum do not generate key pair for SSL certificates.
Must meet RSA key requirements (MRSP § 5.1) - Bad
In section 6.1.6, Certum states, “Certum recognizes subscriber's "weak keys" and rejects them before certificate request submission. It is not allowed to accept keys which are not compliant with the Baseline Requirements Section 6.1.6. Person who generate a key is responsible for checking parameter quality of the generated key He/she/it is required to verify:”
This is insufficiently detailed. Certum has responsibilities to check for various key parameters (beyond just weak keys). See sections 6.1.5 and 6.1.6 of the Baseline Requirements.
We added to section 6.1.6 detailed requirements for accepted keys parameters.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) - Bad
The Certum CPS does not contain any guidance or practice statement about issuing elliptic-curve certificates. There is, however, mention of P-256 in Table 7.1.
We added to section 6.1.6 detailed requirements for accepted keys parameters for elliptic-curve certificates also.
Certificate lifetimes limited to 398 days (BR § 6.3.2) – Bad
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Section 6.3.2 of the CPS still says that the validity period for SSL/TLS server certificates is 825 days.
In section 6.3.2 we corrected the validity period for SSL/TLS certificates.
Network Security (MRSP § 2.1.2) - Meh
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
It is unclear from the network security description in section 6.7 of the CPS whether Certum is following industry best practice for securing its networks.
We added to section 6.7 information that Certum follows CABR Network and Certificate System Security Requirements.
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2) - Good
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
Section 7.1 states, “(Certum generates non‐sequential certificate serial numbers (positive numbers greater than zero) that contain at least 64 bits of output from a CSPRNG);”
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f) - Meh
Certum should be aware that for SSL/TLS end entity server certificates, they must contain “[e]ither the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values ….”
This is described in section 7.1.2.
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1) - Good
CPS does not list SHA1 as an allowed signature Algorithm, except for CRLs (which should probably be eliminated).
Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Good
In Table 7.1 it says, “commonName (in the case of server certificates: contain a single IP address or a domain name that is one of the values contained in the certificate’s subjectAltName extension),”
|
|
Reporter | |
Comment 12•3 years ago
|
||
|
|
Reporter | |
Comment 13•3 years ago
|
||
Hi Ben,
I would like to ask if anything else related to CPS needs clarification?
|
|
Assignee | |
Comment 14•3 years ago
|
||
(In reply to Wojciech Trapczyński from comment #11)
Certum CPS - Version 6.8, Dated: 10 November 2020
CCP-DK02-ZK02-Certification-Practice-Statement-of-Certum-Certification-Services_v6.8.pdf
https://www.certum.eu/en/wp-content/uploads/2020/11/CCP-DK02-ZK02-Certification-Practice-Statement-of-Certum-Certification-Services_v6.8.pdf
Review of:
Certum CPS - Version 6.9, Dated: 21 December 2020
CCP-DK02-ZK02-Certification-Practice-Statement-of-Certum-Certification-Services_v6.9.pdf
Note that in several places when the PDF was generated it could not find the cross-reference and left the message, "Błąd! Nie można odnaleźć źródła odwołania."
We fixed it in all places.
I still found several. Just check the PDF next time you generate it and before you post it to your repository.
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Fixed
“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”
Section 1.3.2 of the CPS does not say that third party RAs may not conduct domain validation.
Section 3.2.2.1 does not make it clear that domain validation is not delegated to third parties.
We added to section 3.2.2.1 information that domain validation is not delegated to third parties.
CPS section 3.2.2.1 now states “Domain verification takes place only in the Certum system and cannot be delegated to third parties.”
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Fixed
We decided to offer the form for Certificate Problem Reports some time ago because we are not able to handle email reporting in the required way. The form should be also a better option in the future when (for example) requests for a certificate key compromise would have to be handled automatically.
Thanks.
No internal names or reserved IP addresses (BR § 7.1.4.2.1) - Fixed
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
I did not find language prohibiting the issuance of certificates to reserved IP addresses or internal names.
We added to section 3.2.2.1 information that we do not issue certificates for reserved IP addresses or internal names
OK
ALL certificates must meet Mozilla/BR validation requirements - OK - but could still be improved
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Section 3.2.2 says, “In the case of certificates issued for devices, authentication may be accomplished by verifying access to the domain placed in the certificate request. Certum may verify the subscriber’s right to use the domain name by the procedure during which some verification element indicated by Certum is placed on destination server or when the Subscriber is required to be able to answer an e-mail sent by Certum to his/her/its address.” This is an insufficient explanation.
Section 3.2.2.1 (Authentication of Domain Name) does not explain how Certum complies with sections 3.2.2.4 and 3.2.2.5 of the Baseline Requirements. They appear to be methods intending to implement BR sections 3.2.2.4.4, 3.2.2.4.6, and 3.2.2.4.7.
Section 3.2.2.1 also says, “For all SSL certificates containing IP address Certum uses one of the above listed verification methods.” However, allowed methods for verifying IP addresses in certificates are listed only in section 3.2.2.5. A separate explanation for those procedures is needed.
We added to section 3.2.2.1 extended information about methods of domain validation and separately about validation methods of IP addresses.
We removed from section 3.2.2 information about validation rules for certificates issued for devices. We no longer issue such certificates.
OK
CA validates domain part of all e-mail addresses (MRSP § 2.2.2) - OK
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Section 3.2.2 says, “In the case of email certificates, the registration authority verifies an email address. The aim of this action is to receive by the subscriber an authentication data sent to the address which has previous placed in the certification request.” This is an inadequate explanation. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response
We added to section 3.2.2 a better explanation of e-mail address validation process.
OK
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5) - OK
Section 3.2.2 of the Certum CPS states, “The verification is performed based on the Qualified Independent/Government Information Sources e.g. publicly available records of companies/organizations registries. The list of information sources is available in the repository on certum.eu.” It is unclear where the list is located in the repository. It is also unclear how Certum determines that a validation source is a “Reliable Data Source” or a qualified QIIS.
We added to section 3.2.2 information about how Certum determines the reliability of sources. Additionally, we added a direct link to validation sources in our repository.
The list of information sources is available in the repository on certum.eu:
https://www.certum.eu/en/ev-verification-sources/
Pre-issuance linting (Recommended Practices) - Fixed - Good
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Discussion of pre-issuance linting not found in the CPS.
We added to section 4.3.1 information about pre-issuance linting.
Good. Thanks!
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) - Fixed
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Section 4.9.1 only contains 4 of the 5 BR-provided reasons for 24-hour revocation. Missing is “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based -on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.
Only 3 reasons are given for revoking the certificate belonging to a CA (not the nine reasons mentioned in section 4.9.1.2 of the Baseline Requirements).
We added to section 4.9.1 all remaining reasons for revocation.
Fixed
SMIME Reasons for Revocation (MRSP § 6.2) - Fixed
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”
Please review MRSP § 6.2 and determine how those revocation reasons can be worked into your CPS.
We added to section 4.9.1 revocation reasons for S/MIME certificates also.
Section added. Good.
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - OK
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Section 5.7.3 states that Certum carries out its key compromise operations “in accordance with the plan developed by the security incident response team”. That plan should provide that Mozilla is notified immediately whenever a CA key compromise is suspected.
We added to section 5.7.3 information about the obligation to inform certificate consumers immediately after detection of a security incident.
Thanks
CA must not generate Subscriber key pairs (MRSP § 5.2) - Fixed
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Section 4.1.2.1 says “[the] subscriber generates his/her/its key pair by himself/herself/itself. The generation may also be delegated to Certum;”
Section 4.3.1 says, “if the application contains the request for generating of a key pair, the server charges hardware key generator complying with the requirements of at least FIPS 140 Level 3 with this task”
Section 6.1.2 discusses key generation and delivery to subscribers but is silent as to private keys for SSL.
We added to sections 4.1.2.1, 4.3.1 and 6.1.2 information that Certum do not generate key pair for SSL certificates.
Section 4.1.2.1 now states, “subscriber generates his/her/its key pair by himself/herself/itself. The generation may also be delegated to Certum for S / MIME and CodeSigning certificates;”
Must meet RSA key requirements (MRSP § 5.1) - Fixed
In section 6.1.6, Certum states, “Certum recognizes subscriber's "weak keys" and rejects them before certificate request submission. It is not allowed to accept keys which are not compliant with the Baseline Requirements Section 6.1.6. Person who generate a key is responsible for checking parameter quality of the generated key He/she/it is required to verify:”
This is insufficiently detailed. Certum has responsibilities to check for various key parameters (beyond just weak keys). See sections 6.1.5 and 6.1.6 of the Baseline Requirements.
We added to section 6.1.6 detailed requirements for accepted keys parameters.
Section 6.1.6 of the CPS now states “It is not allowed to accept keys which are not compliant with the Baseline Requirements Section 6.1.6.”
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) - Fixed
The Certum CPS does not contain any guidance or practice statement about issuing elliptic-curve certificates. There is, however, mention of P-256 in Table 7.1.
We added to section 6.1.6 detailed requirements for accepted keys parameters for elliptic-curve certificates also.
Section 6.1.7 of the CPS now states that “For ECDSA keys: The keys shall pass the validation process as specified in the ECC key validation procedure described in section 5.6.2.3.2 or 5.6.2.3.3 of NIST SP 800-56A: Revision 2.Key Usage Purposes.”
Certificate lifetimes limited to 398 days (BR § 6.3.2) – Fixed
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Section 6.3.2 of the CPS still says that the validity period for SSL/TLS server certificates is 825 days.
In section 6.3.2 we corrected the validity period for SSL/TLS certificates.
Section 6.3.2 of the CPS states that “The maximum validity period for website authentication certificates is 398 days.”
Network Security (MRSP § 2.1.2) - Fixed
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
It is unclear from the network security description in section 6.7 of the CPS whether Certum is following industry best practice for securing its networks.
We added to section 6.7 information that Certum follows CABR Network and Certificate System Security Requirements.
Section 6.7 of the CPS now states that “Certum complies with the best business practices, including the current CA / B Forum guidelines - Network and Certificate System Security Requirements.”
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 15•3 years ago
|
||
I have moved this matter into the "for-discussion" queue. When will your next audit letter be available?
|
|
Reporter | |
Comment 16•3 years ago
|
||
Thank you.
We should get a new audit letter on April 8.
|
|
Assignee | |
Comment 17•3 years ago
|
||
Public discussion on this inclusion request began on 22-March-2021 and is scheduled to close on 14-April-2021.
https://groups.google.com/g/mozilla.dev.security.policy/c/_A7OX4Tz65k/m/S0CWpqMPAwAJ
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 18•3 years ago
|
||
The 3-week public discussion period has now passed and there were no objections to this inclusion request. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/1VjzYhp_ykc/m/lPVl_y_KAQAJ in which I indicated that it is Mozilla’s intent to approve Asseco’s request for inclusion and started the 7-day “last call” period (through April 22, 2021) for any final objections.
|
|
Assignee | |
Updated•3 years ago
|
|
|
||
Comment 19•3 years ago
|
||
As per Comment #18, and on behalf of Mozilla I approve this request from Asseco Data Systems to include the following root certificates:
** Certum EC-384 CA; (Email, Websites); EV
** Certum Trusted Root CA; (Email, Websites); EV
I will file the NSS and PSM bugs for the approved changes.
|
|
||
Comment 20•3 years ago
|
||
I have filed bug #1707097 against NSS and bug #1707099 against PSM for the actual changes.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
Description
•