SSC has applied to include three root certificates as follows: enable
the email trust bit for the “SSC GDL CA VS Root” certificate; enable the
code signing and email trust bits for the “SSC GDL CA Root A”
certificate; and enable all three trust bits for the “SSC GDL CA Root B”
certificate. EV treatment is also requested for the “SSC GDL CA Root B”
certificate.
Skaitmeninio Sertifkavimo Centras (SSC) is a Qualified CA (QCA) and a
Trusted Service Provider (TSP) that issues certificates to public
institutions, private organizations and natural persons in Lithuania.
The request is documented in the following bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=379152
And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8623799
Noteworthy points:
* Documents are provided in Lithuanian and English.
Document Repository: https://gdl.repository.ssc.lt/en/repository/documents/
CP:
https://gdl.repository.ssc.lt/en/repository/documents/certificate-policy-ssc-gdl-ca-v4.4.pdf
CPS:
https://gdl.repository.ssc.lt/en/repository/documents/certificate-practice-statement-ssc-gdl-ca-v4.7.pdf
DRAFT CPS v4.10: https://bugzilla.mozilla.org/attachment.cgi?id=8613560
* CA Hierarchy
** “SSC GDL CA Root A” has two internally-operated Intermediate/Issuing
CAs:
1. SSC GDL Class 1 CA -- Issues technically functional certificates with
no identity assurances.
2. SSC GDL Class 2-4 QCA -- Issues QCs, SSL/TLS client
(authentication/signing/encryption) and CS certificates only to Public.
** “SSC GDL CA Root B” has two internally-operated Intermediate/Issuing CAs:
1. SSC GDL NH CA -- Issues device/e-service certificates including
SSL/TLS and CS certificates.
2. SSC GDL EV CA -- Issues exclusively EV SSL and Qualified web site
certificates (see section 8 of REGULATION (EU) No 910/2014 OF THE
EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014).
** “SSC GDL CA VS Root” has one internally-operated Intermediate/Issuing CA:
SSC GDL VS Class 2-4 QCA -- Issues QCs, SSL/TLS client
(authentication/signing/encryption) certificates to Government and
Public institutions only.
* This request is to enable the email trust bit for the “SSC GDL CA VS
Root” certificate; enable the code signing and email trust bits for the
“SSC GDL CA Root A” certificate; and enable all three trust bits for the
“SSC GDL CA Root B” certificate. EV treatment is also requested for the
“SSC GDL CA Root B” certificate.
** CPS section 3.2.2: For an organizational Subject evidence is provided
of full name of the organizational entity and reference to a nationally
recognized registration.
For a device or service operated by or on behalf of an organization,
evidence is provided of identifier of the deice/service by which they
may be referenced, full name for the organizational entity and a
nationally recognized identifier.
For certificate issued under EVCP and EVCP+ certificate verification of
Applicant’s Identity, including its assumed name, legal, physical and
operational existence and Doman Name ownership is performed according to
then requirement indicated in [CABF-EV].
** DRAFT CPS v4.10 section 3.2.5: If the Subject of certificate is a
service offered via a network, the Applicant must provide identifying
information and an acceptable proof of ownership which shall include
unique software or service name (e.g. DNS name), service attributes to
be included in the certificate, if any, and owner's contact information.
The CA shall validate that the Applicant is:
(a) authorized to request a certificate for the service;
(b) the real owner owner of the service (through an appropriate reliable
3rd party database);
(c) able to demonstrate control of the domain (by manipulating DNS
records and server configuration).
** CPS section 3.2.6: Information about the Subject, including email
address, is included in certificates only after it is reliably verified.
** DRAFT CPS v4.10 section 4: For digital assets whose identifiers are
maintained by third parties (e.g. email addresses, domain names etc.)
the RA verifies operational existence by directly accessing/using the
resource (e.g. a server) or communicating through the resource (e.g.
email address) and legal existence - by obtaining independent ownership
conformation from the associated registrar.
** CPS section 4.1: For EVCP and EVCP+ certificates extra verification
measures are taken as defined in [CABF-EV] to ensure the Subscriber's
legal, physical and operational existence. Proof of representation and
authority to act on behalf of the Applicant has to be demonstrated in
order to authenticate the signatures on EVCP and EVCP+ certificate
application forms.
… The RA checks that the organization is the legal holder of its name by
mapping the information provided in the Extended Validation certificate
application with information of official Government Registers (Legal
entity DB, TAX payers DB, Social Security DB) that confirms the existence
of the organization.
The RA checks the official postal address of the applicant along with
Applicant's main business phone number.
In case a technical contact is also the certificate requester with no
approval rights, the certificate application form has to be signed by an
authorized certificate approver, whose signature has to be verified. The
RA communicates with the Certificate signer by phone to ensure validity
of authorization. The RA may also communicate with the Certificate
signer by postal mail sent to the applicant's place of business.
* EV Policy OID: 2.23.140.1.1
* Root Cert URLs
https://gdl.repository.ssc.lt/certs/roota.crt
https://gdl.repository.ssc.lt/certs/rootb.crt
https://gdl.repository.ssc.lt/certs/rootvs.crt
* Test Website: https://evssl.gdl.ssc.lt/
* Example Certs
https://gdl.repository.ssc.lt/certs/test-v-class2-4qca.cer
https://gdl.repository.ssc.lt/certs/test-v-vsclass2-4qca.cer
* CRL
https://gdl.repository.ssc.lt/crls/nhca.crl
https://gdl.repository.ssc.lt/crls/evca.crl
http://gdl.repository.ssc.lt/crls/rootb.crl
https://gdl.repository.ssc.lt/crls/class2-4qca.crl
https://gdl.repository.ssc.lt/crls/vsclass2-4qca.crl
* OCSP
http://nhca.ocsp.gdl.ssc.lt/
http://evca.ocsp.gdl.ssc.lt/
http://rootb.ocsp.gdl.ssc.lt/
http://class2-4qca.ocsp.gdl.ssc.lt/
http://vsclass2-4qca.ocsp.gdl.ssc.lt/
* Audit: SSC is audited annually by TÜV Informationstechnik GmbH
according to the ETSI TS 101 456 criteria and ETSI TS 102 042 criteria.
QCP public + SSCD:
https://www.tuvit.de/data/content_data/tuevit_en/6730UE_s.pdf
EVCP, EVCP+: https://www.tuvit.de/data/content_data/tuevit_en/6729UE_s.pdf
* Potentially Problematic Practices -- None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Currently SSC doesn't have third-party RAs, however may have
registration partners in the future.
*** According to ETSI TS 102 042 Registration service only verifies
identity and, if applicable, any specific attributes of a subject. The
results of this service are passed to the certificate generation
service. So, based on this ETSI definition, RAs are not allowed to issue
certificates. Activities of registration service personnel, including
those employed by SSC, are constrained/controlled by SSC's RA management
software which has no certificate generation/issuing capabilities.
This begins the discussion of the request from SSC to include three root
certificates as follows: enable the email trust bit for the “SSC GDL CA
VS Root” certificate; enable the code signing and email trust bits for
the “SSC GDL CA Root A” certificate; and enable all three trust bits for
the “SSC GDL CA Root B” certificate. EV treatment is also requested for
the “SSC GDL CA Root B” certificate.
At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
