379152 - Add Lithuanian National Root Certificates

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task, P2)

Description

[Moudrick]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

Hello,

I represent a Qualified Certificate Authority in Lithuania.

Since Firefox is one of the most dinamically growing popular web brosers in Lithuania we kindly ask Mozilla Foundation to consider adding our 3 (three)  Root Certificates into the default set.

According the Law on Electronic signatures, Information Sociate Development Comitte of Lithuania is the official Government institution responsible for supervision of certification service providers. The Comitte has developed official requirements to CAs issuing qualified certificates based on ETSI TS 101 456.

The company I represent, Skaitmeninio sertifikavimo centras (SSC), has passed Government audit procedures. Official letter of conformance is available upon request. The status of the company as the qualiified CA can also be checked through the Comitte's web site:

http://epp.ivpk.lt/en/providers/

The three Root Certificates for inclusion are:

SSC Root CA A

-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQBFU7GF5UXhPPMV8jk1Q+mDANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEEwHhcNMDcwMTI2MTEzMDQ4WhcNMDgwMTI2MTIw
NjEyWjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAovZwUb9JtuyobaNVr0sB/bFtZKSDaJ5lXF8So0hf7Q6j
3/dOIOGFJSb0/rdb5T1SiB++qDx/jXinVtVQIpOJ2eFe8CPGzMly4iHzzs9LuE1+
SeOYnRAJybjT0cY29ExGxtoVJKMKZlxdn8M3pjOglfNU8eKt8vyCVq1W0Zr+zykC
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFMy/3qeQd2JqHXhp
Lgo4m3dRUwPwMBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFJUzOVgd
wLi/Fc44T7AIljvTGd9lMA0GCSqGSIb3DQEBBQUAA4ICAQByQUJGWN0ITfa84Trn
jtARy2Vlo/JaOHUb5iu6SsftOcCNR3XmH2hvdjyHtXpw7KAaAPyK+JdzPfUHcVY+
y8KHfWjnoCm1medAPXsCuHvQlnpZZqsLIRFpzF2AiIgoSzse4WNY9iDee/2mzUyg
G5dG5iGUjaxeN12lPR0inned4EEXWsQnQLnpf18QlwwQKgDQNbMWV416rMnZuLQF
UJBVg2Perenk2xlqzyDQgI54rwGqaokMz0AuuQy6/fogmWdZZA9lxv67rOAIICH0
sAD1tp6FcBOydcmn3ZqUbprvozH47VZxTxp2B2LLd+8A+h7ZxjFSQeX8bAIAQVoE
K3FngQ5j+sksrvKpIhBDhvNWWvnb+YYY2tSCJdLdq/ylYgAVk1mezEAYQ22U93cw
31xQtNQSdAQNq/hyiETtD2ABlm30a/9Mqq6Cz+96U+Rie4hqRhfyvyT7DkVk/zQj
r61J7C2v/afq8918FSqGnwRFahjovU3EmsD4NNhAX1rw5JVDdMaatXM6ucN/d4O1
nkzUjZ04gB5jQkULRyIuf5Xtw71h6R6jI9P9tCNoZn/icsaNX1JPF0NoiamVUBqu
EIxNf4U6jG1i6zebteyrnuCjmaBFowf+XUpXjyUTbEingbdO4q6rhteVGLK/zE1f
DolRMoYoZYtGKhGgdt9uMiARzA==
-----END CERTIFICATE-----

SC Root CA B:

-----BEGIN CERTIFICATE-----
MIIEkDCCAnigAwIBAgIRAPf7ZfnLl4sxjRvm4mB3b+IwDQYJKoZIhvcNAQEFBQAw
dDELMAkGA1UEBhMCTFQxKzApBgNVBAoTIlNrYWl0bWVuaW5pbyBzZXJ0aWZpa2F2
aW1vIGNlbnRyYXMxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MRYw
FAYDVQQDEw1TU0MgUm9vdCBDQSBCMB4XDTA3MDEyNjExMzIxMloXDTA4MDEyNjEy
MDg0OFowgasxGTAXBgkqhkiG9w0BCQEWCmFhYUBiYmIuY2MxCzAJBgNVBAYTAkxU
MS8wLQYDVQQKEyZVQUIgU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZpbW8gY2VudHJh
czEzMDEGA1UECxMqT25seSBmb3IgQ0hBSU4gVkFMSURBVElPTiBURVNUSU5HIHB1
cnBvc2VzMRswGQYDVQQDExJOb25hbWUgY2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMyRbRUXbyRUJWKKfiqVLvWGApMsyf9/6/dlCL/UvGK2
vRu6FFYDHz6Rlj74buGCLxvvG2h6z3fRAOQtv+y62wf48HRYXy61EEgATNOHnkFb
ylpFPv+pF3T+5HWvtOSB4Dgxnf3wdaHEyhmZUwng8p/6fgiZAorNEuXvdcStnNzN
AgMBAAGjaTBnMA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBScA/Co0phyaK7y
7eBP4oUOsiVOzzAVBgNVHREEDjAMgQphYWFAYmJiLmNjMB0GA1UdDgQWBBTjyMHH
DdRFZ/QEB1xRg40XdniksTANBgkqhkiG9w0BAQUFAAOCAgEADbzWJsfFhaeCYdUv
NA5kz2ikZTunCiXVy1VD/kqyTYSeyQHVykYFhnNmjEIASRZFJglEIArVOhalsxyl
rQtTBnpG8XUcdL6NeKLs7ArwSFvNM+g0dV+X/YF09eV38jjHvu5cnNV3O9DiglNP
JM+vWHF91UC2jGZoDVjNtCG3cDTu64MHLYJucxKD8oZQMyCodsS7XXSZZdQOLl9k
1Lj81UGI3rB0VN1viE7aairMJES8VlUq8i958K6BhWtD0YYwKssK1J0cJAnV092I
dGtq1pVsmmRMpGx6PBWbmiNP5gV6uQ30iublJuE7YM1vPPbb7QmSQDdTwd/QCTZc
mXns0JSonczxr3eefg6pzhtmlC1PPEQx2/9E8CweCLzoFE8wzxFGLKtXzcHMSMQZ
+UmfRwi59E7G87VK51ey5bskW6T7ul1L0gB/chlmOmEkWTDE10K8AyJ9vJZ5XL9m
QlD72AvQv/ZhYpXBTQfedpkYUGqwhJu0x9TNbY1d9RwAyF6iDhlTiBZqCn+oNcRA
fffv98YfxZaixOcKNa9Vj7sKS2Jh5FP8utV/sziQ0thjVb1r1kWdkVhyMSNUcc+5
ZE21ONdOnpu9A/4JjMaSO/He742vUtcsRbEs3ik0QjWcIroorXRvXwks1ier3Kxd
iBkRo7aGoYn5eMUz0hmGlbhSnSA=
-----END CERTIFICATE-----

SSC Root CA C:

-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQTdfDAE7x9Ugv+l/HwE+vOzANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEMwHhcNMDcwMTI2MTEzMjU3WhcNMDgwMTI2MTIx
MTU3WjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAqZLPYzdICYocwKLivoIKQcBSIIwZyFOgrFx1YQc7jPrm
BzvHF+wQfoAbUj3KKxwiCxZHo2m5c69wzVq2YuNdtokwFnzrLaXav9batAlXVmEx
udYclG09VuUUbRaTXgdRTDzY6XIBSgsV+vABmPi5Tozp6XDBvrUEn+ZeEjvGfX0C
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFIgHc/bxvFIaWh09
kWLtXaydC+W3MBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFFwjEsCI
YxcLSZT9piSgIMRD6jGRMA0GCSqGSIb3DQEBBQUAA4ICAQAmI/ME/qVgVcPcCFAb
z4vid7F4Iqfz1w3waC2LDvR/PNrRNRkq9D9ID7IcjAGYF1xcqt1B2QECI3j4O/ey
QkgxB5mKfrXyXTAYQ4r2H8PrnoJo6D6SHeY6kBlDfNp3ZhLEBfVBwy7HwlEUqdSH
Y3VQNQefYngBYEDLAsRqrk+gn0B4/tiXuOttFeXMUhxxvwaDBzHv5gnl0G87dFFY
JxuOV1rEpGzoSS8Ub+Kv36ILqV0TBYk13slheLxTybWOBsI2OxFrzCRhLOK+eql1
Vx7xAEmqHiZYSgI6lj/mRF/dL/iZ5ivSS3jVFD3+BqLvCJgAYH56FB5BnLOeitXL
4AT3Q6AHW38X79n1dxUsWS/lS09iAQFJyrqn5AVUFwawvoRdSRPYantrbxfo2P87
rwCatO19DkZ84N4B0dOOhchKJ5iKuaUlnY1lgcFmlqqWIMGykwYflI9nRARztLJ7
rXiun2ewkBdsxZlE+VuUV2pS4eAreE/g9D2183Nd/FOl8XzGYTQnj6DoeR37KGPm
joH8X729qXULMuPu1kXw3EFgLweSQgD80dXISV/CyUNY1pAQiUbfVyFY8xTOMlk3
3hScSmP0ujQBupjWQOntCoaIkapoKgdtMRqwc4/Rp+Wex6fBamS7bH0j/WR51PD4
WnObS//pPzkYCu92zNp+e8BLCQ==
-----END CERTIFICATE-----

The CA certificates are used to sign end entity certificates with the following purposes: 

SSL-enabled servers; 
digitally-signed;
encrypted email; 
digitally-signed executable code objects.

Copies of the CP and CPS (in Lithuanian language) can be obtained here :

https://repository.ssc.lt/?name=rep_doc_groups&act=list&L=lt&ssc_m=6,15

Please let us know if you have any questions or need more information.

Thank you for your time.

Best Regards,

Moudrick Dadashov

CEO
Skaitmeninio sertifikavimo centras

www.ssc.lt
phone: [phone]
office: [phone]
fax: [phone]
email: [e-mail]

Address: Jogailos 8-16, 01116 Vilnius, LITHUANIA

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Gervase Markham [:gerv]]

Hi,

Sorry for the delay.

Please could you provide data about your CA and certificates in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again.

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, 
                   academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy, 
   i.e. what you plan to do with the root
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity/organisationally-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):
URL of website using certificate chained to this root (if applying for SSL):

Thanks for your help in this matter. :-)

Gerv

Comment 2

[Gervase Markham [:gerv]]

Moudrick: If you are not able to respond to the request for more information soon, this bug will be closed.

Gerv

Comment 3

[Moudrick]

(In reply to comment #2)
> Moudrick: If you are not able to respond to the request for more information
> soon, this bug will be closed.
> Gerv

We are finishing an important project early next week, and immediately after that I'll provide you with the requested info. Sorry for inconveniences this may have caused and thank you for your understanding. 

M.D.

Comment 4

[Moudrick]

Hello, finally we have finished the project and now we are giving this thread top priority. Shortly I will provide here all requested information.

Thank you for your patience.


Best Regards,
M.D.
cell: [phone]

Comment 5

[Moudrick]

This is the first of four messages I'm going to send you: the first three will contain each of three CA certificate. In the last message I will answer your questions.

  SSC Root CA A

-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQBFU7GF5UXhPPMV8jk1Q+mDANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEEwHhcNMDcwMTI2MTEzMDQ4WhcNMDgwMTI2MTIw
NjEyWjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAovZwUb9JtuyobaNVr0sB/bFtZKSDaJ5lXF8So0hf7Q6j
3/dOIOGFJSb0/rdb5T1SiB++qDx/jXinVtVQIpOJ2eFe8CPGzMly4iHzzs9LuE1+
SeOYnRAJybjT0cY29ExGxtoVJKMKZlxdn8M3pjOglfNU8eKt8vyCVq1W0Zr+zykC
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFMy/3qeQd2JqHXhp
Lgo4m3dRUwPwMBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFJUzOVgd
wLi/Fc44T7AIljvTGd9lMA0GCSqGSIb3DQEBBQUAA4ICAQByQUJGWN0ITfa84Trn
jtARy2Vlo/JaOHUb5iu6SsftOcCNR3XmH2hvdjyHtXpw7KAaAPyK+JdzPfUHcVY+
y8KHfWjnoCm1medAPXsCuHvQlnpZZqsLIRFpzF2AiIgoSzse4WNY9iDee/2mzUyg
G5dG5iGUjaxeN12lPR0inned4EEXWsQnQLnpf18QlwwQKgDQNbMWV416rMnZuLQF
UJBVg2Perenk2xlqzyDQgI54rwGqaokMz0AuuQy6/fogmWdZZA9lxv67rOAIICH0
sAD1tp6FcBOydcmn3ZqUbprvozH47VZxTxp2B2LLd+8A+h7ZxjFSQeX8bAIAQVoE
K3FngQ5j+sksrvKpIhBDhvNWWvnb+YYY2tSCJdLdq/ylYgAVk1mezEAYQ22U93cw
31xQtNQSdAQNq/hyiETtD2ABlm30a/9Mqq6Cz+96U+Rie4hqRhfyvyT7DkVk/zQj
r61J7C2v/afq8918FSqGnwRFahjovU3EmsD4NNhAX1rw5JVDdMaatXM6ucN/d4O1
nkzUjZ04gB5jQkULRyIuf5Xtw71h6R6jI9P9tCNoZn/icsaNX1JPF0NoiamVUBqu
EIxNf4U6jG1i6zebteyrnuCjmaBFowf+XUpXjyUTbEingbdO4q6rhteVGLK/zE1f
DolRMoYoZYtGKhGgdt9uMiARzA==
-----END CERTIFICATE-----

Comment 6

[Moudrick]

SSC Root CA B:

-----BEGIN CERTIFICATE-----
MIIEkDCCAnigAwIBAgIRAPf7ZfnLl4sxjRvm4mB3b+IwDQYJKoZIhvcNAQEFBQAw
dDELMAkGA1UEBhMCTFQxKzApBgNVBAoTIlNrYWl0bWVuaW5pbyBzZXJ0aWZpa2F2
aW1vIGNlbnRyYXMxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MRYw
FAYDVQQDEw1TU0MgUm9vdCBDQSBCMB4XDTA3MDEyNjExMzIxMloXDTA4MDEyNjEy
MDg0OFowgasxGTAXBgkqhkiG9w0BCQEWCmFhYUBiYmIuY2MxCzAJBgNVBAYTAkxU
MS8wLQYDVQQKEyZVQUIgU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZpbW8gY2VudHJh
czEzMDEGA1UECxMqT25seSBmb3IgQ0hBSU4gVkFMSURBVElPTiBURVNUSU5HIHB1
cnBvc2VzMRswGQYDVQQDExJOb25hbWUgY2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMyRbRUXbyRUJWKKfiqVLvWGApMsyf9/6/dlCL/UvGK2
vRu6FFYDHz6Rlj74buGCLxvvG2h6z3fRAOQtv+y62wf48HRYXy61EEgATNOHnkFb
ylpFPv+pF3T+5HWvtOSB4Dgxnf3wdaHEyhmZUwng8p/6fgiZAorNEuXvdcStnNzN
AgMBAAGjaTBnMA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBScA/Co0phyaK7y
7eBP4oUOsiVOzzAVBgNVHREEDjAMgQphYWFAYmJiLmNjMB0GA1UdDgQWBBTjyMHH
DdRFZ/QEB1xRg40XdniksTANBgkqhkiG9w0BAQUFAAOCAgEADbzWJsfFhaeCYdUv
NA5kz2ikZTunCiXVy1VD/kqyTYSeyQHVykYFhnNmjEIASRZFJglEIArVOhalsxyl
rQtTBnpG8XUcdL6NeKLs7ArwSFvNM+g0dV+X/YF09eV38jjHvu5cnNV3O9DiglNP
JM+vWHF91UC2jGZoDVjNtCG3cDTu64MHLYJucxKD8oZQMyCodsS7XXSZZdQOLl9k
1Lj81UGI3rB0VN1viE7aairMJES8VlUq8i958K6BhWtD0YYwKssK1J0cJAnV092I
dGtq1pVsmmRMpGx6PBWbmiNP5gV6uQ30iublJuE7YM1vPPbb7QmSQDdTwd/QCTZc
mXns0JSonczxr3eefg6pzhtmlC1PPEQx2/9E8CweCLzoFE8wzxFGLKtXzcHMSMQZ
+UmfRwi59E7G87VK51ey5bskW6T7ul1L0gB/chlmOmEkWTDE10K8AyJ9vJZ5XL9m
QlD72AvQv/ZhYpXBTQfedpkYUGqwhJu0x9TNbY1d9RwAyF6iDhlTiBZqCn+oNcRA
fffv98YfxZaixOcKNa9Vj7sKS2Jh5FP8utV/sziQ0thjVb1r1kWdkVhyMSNUcc+5
ZE21ONdOnpu9A/4JjMaSO/He742vUtcsRbEs3ik0QjWcIroorXRvXwks1ier3Kxd
iBkRo7aGoYn5eMUz0hmGlbhSnSA=
-----END CERTIFICATE-----

Comment 7

[Moudrick]

This is the last of three CA certificates. In the followin message I'll answer your questions and provide copies of documents requested.

SSC Root CA C:

-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQTdfDAE7x9Ugv+l/HwE+vOzANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEMwHhcNMDcwMTI2MTEzMjU3WhcNMDgwMTI2MTIx
MTU3WjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAqZLPYzdICYocwKLivoIKQcBSIIwZyFOgrFx1YQc7jPrm
BzvHF+wQfoAbUj3KKxwiCxZHo2m5c69wzVq2YuNdtokwFnzrLaXav9batAlXVmEx
udYclG09VuUUbRaTXgdRTDzY6XIBSgsV+vABmPi5Tozp6XDBvrUEn+ZeEjvGfX0C
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFIgHc/bxvFIaWh09
kWLtXaydC+W3MBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFFwjEsCI
YxcLSZT9piSgIMRD6jGRMA0GCSqGSIb3DQEBBQUAA4ICAQAmI/ME/qVgVcPcCFAb
z4vid7F4Iqfz1w3waC2LDvR/PNrRNRkq9D9ID7IcjAGYF1xcqt1B2QECI3j4O/ey
QkgxB5mKfrXyXTAYQ4r2H8PrnoJo6D6SHeY6kBlDfNp3ZhLEBfVBwy7HwlEUqdSH
Y3VQNQefYngBYEDLAsRqrk+gn0B4/tiXuOttFeXMUhxxvwaDBzHv5gnl0G87dFFY
JxuOV1rEpGzoSS8Ub+Kv36ILqV0TBYk13slheLxTybWOBsI2OxFrzCRhLOK+eql1
Vx7xAEmqHiZYSgI6lj/mRF/dL/iZ5ivSS3jVFD3+BqLvCJgAYH56FB5BnLOeitXL
4AT3Q6AHW38X79n1dxUsWS/lS09iAQFJyrqn5AVUFwawvoRdSRPYantrbxfo2P87
rwCatO19DkZ84N4B0dOOhchKJ5iKuaUlnY1lgcFmlqqWIMGykwYflI9nRARztLJ7
rXiun2ewkBdsxZlE+VuUV2pS4eAreE/g9D2183Nd/FOl8XzGYTQnj6DoeR37KGPm
joH8X729qXULMuPu1kXw3EFgLweSQgD80dXISV/CyUNY1pAQiUbfVyFY8xTOMlk3
3hScSmP0ujQBupjWQOntCoaIkapoKgdtMRqwc4/Rp+Wex6fBamS7bH0j/WR51PD4
WnObS//pPzkYCu92zNp+e8BLCQ==
-----END CERTIFICATE-----

Comment 8

[Gervase Markham [:gerv]]

Moudrick: you said there would be a fourth message...?

Also, the certificates are not incredibly useful in the form you have given them. When you fill in the form I gave, it has a slot for "HTTP Download URL" for each certificate. If you provide one of those, that would be far more useful.

Gerv

Comment 9

[Moudrick]

Dear Gerv,

here are 'HTTP download URLs' of the certificates:

1. http://www.ssc.lt/cacert/ssc_root_a.crt
2. http://www.ssc.lt/cacert/ssc_root_b.crt
3. http://www.ssc.lt/cacert/ssc_root_c.crt

Also, these certificates are in the Windows' Trusted Root CA list.

If the certs are ok, I'm ready to move on with the 'fourth message'. Thank you.

M.D.
cell: [phone]

Comment 10

[Gervase Markham [:gerv]]

These certificates seem fine. Feel free to post the rest of the required information. :-)

Gerv

Comment 11

[Moudrick]

Thank you. Here is the rest as requested. Please let us know if you need more info:

CA Name: Skaitmeninio Sertifkavimo centras
Website: www.ssc.lt
One Paragraph Summary of CA, including the following:
 - This is the Government accredited commercial CA issuing certificates to Government institutions, public eservices, businesses and citizens.
 - Primary geographical area(s) served: Lithuania, European Union
 - Number and type of subordinate CAs: None
Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: Information Society Development Committee Under The Government Of The Republic Of Lithuania
Auditor Website: http://epp.ivpk.lt/en/providers/
Audit Document URL(s): http://www.ssc.lt/files/SSC%20CA%20Application%20to%20MS%20Trusted%20Root%20CA%20program.jpg
Original in Lithuanian Language: http--www.ssc.lt-1tiekejas.jpg

Thank you for your time.

Best Regards

M.D.
cell: [phone]

Comment 12

[Gervase Markham [:gerv]]

Moudrick: You missed out the section giving details of the certificates. I need three copies of that, one for each certificate.

Thanks,

Gerv

Comment 13

[Moudrick]

Dear Gerv

here is the information about  each of three Root  certificates as requested. At the end of  Root certificate info in three  appendixes we present test certificates for validation.  Please let me know if more is  needed.

Thank you for your time.

M.D. 

CN = SSC Root CA A
OU = Certification Authority, O = Skaitmeninio sertifikavimo centras, C = LT

Not Before: Dec 27 12:18:52 2006 GMT
Not After : Dec 28 12:05:04 2026 GMT

5a 5a 4d af 78 61 26 7c 4b 1f 1e 67 58 6b ae 6e d4 fe b9 3f

https://www.ssc.lt/cacerts/ssc_root_a.crt

SSC CA certificates will include Extended Key Usages in Certificate Policy Statement (CPS) and will define OID of according CPS in Certificate Policy extension. We are planning to use such EKU‘s: server authentication, client authentication, code signing, e-mail protection, time stamping, OCSP signing.

Base64 encoded, PEM formatted certificate is included in Appendix 2 within this document or can be reached via HTTPS using this URL:
https://www.ssc.lt/certs/noname_cert_b.pem


CN = SSC Root CA B
OU = Certification Authority, O = Skaitmeninio sertifikavimo centras, C = LT

Not Before: Dec 27 12:22:50 2006 GMT
Not After : Dec 25 12:08:26 2026 GMT

3e 84 d3 bc c5 44 c0 f6 fa 19 43 5c 85 1f 3f 2f cb a8 e8 14

https://www.ssc.lt/cacerts/ssc_root_b.crt

SSC CA certificates will include Extended Key Usages in Certificate Policy Statement (CPS) and will define OID of according CPS in Certificate Policy extension. We are planning to use such EKU‘s: server authentication, client authentication, code signing, e-mail protection, time stamping, OCSP signing.

Base64 encoded, PEM formatted certificate is included in Appendix 2 within this document or can be reached via HTTPS using this URL:
https://www.ssc.lt/certs/noname_cert_b.pem

CN = SSC Root CA C
OU = Certification Authority, O = Skaitmeninio sertifikavimo centras, C = LT

Not Before: Dec 27 12:26:30 2006 GMT
Not After : Dec 22 12:11:30 2026 GMT

23 e8 33 23 3e 7d 0c c9 2b 7c 42 79 ac 19 c2 f4 74 d6 04 ca

https://www.ssc.lt/cacerts/ssc_root_c.crt

SSC CA certificates will include Extended Key Usages in Certificate Policy Statement (CPS) and will define OID of according CPS in Certificate Policy extension. We are planning to use such EKU‘s: server authentication, client authentication, code signing, e-mail protection, time stamping, OCSP signing.

Base64 encoded, PEM formatted certificate is included in Appendix 3 within this document or can be reached via HTTPS using this URL:
https://www.ssc.lt/certs/noname_cert_c.pem



APPENDIX 1. Chain validation certificate for SSC Root CA A:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:55:3b:18:5e:54:5e:13:cf:31:5f:23:93:54:3e:98
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=LT, O=Skaitmeninio sertifikavimo centras, OU=Certification Authority, CN=SSC Root CA A
        Validity
            Not Before: Jan 26 11:30:48 2007 GMT
            Not After : Jan 26 12:06:12 2008 GMT
        Subject: emailAddress=[e-mail], C=LT, O=UAB Skaitmeninio sertifikavimo centras, OU=Only for CHAIN VALIDATION TESTING purposes, CN=Noname certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:a2:f6:70:51:bf:49:b6:ec:a8:6d:a3:55:af:4b:
                    01:fd:b1:6d:64:a4:83:68:9e:65:5c:5f:12:a3:48:
                    5f:ed:0e:a3:df:f7:4e:20:e1:85:25:26:f4:fe:b7:
                    5b:e5:3d:52:88:1f:be:a8:3c:7f:8d:78:a7:56:d5:
                    50:22:93:89:d9:e1:5e:f0:23:c6:cc:c9:72:e2:21:
                    f3:ce:cf:4b:b8:4d:7e:49:e3:98:9d:10:09:c9:b8:
                    d3:d1:c6:36:f4:4c:46:c6:da:15:24:a3:0a:66:5c:
                    5d:9f:c3:37:a6:33:a0:95:f3:54:f1:e2:ad:f2:fc:
                    82:56:ad:56:d1:9a:fe:cf:29
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Authority Key Identifier:
                keyid:CC:BF:DE:A7:90:77:62:6A:1D:78:69:2E:0A:38:9B:77:51:53:03:F0

            X509v3 Subject Alternative Name:
                email:[e-mail]
            X509v3 Subject Key Identifier:
                95:33:39:58:1D:C0:B8:BF:15:CE:38:4F:B0:08:96:3B:D3:19:DF:65

    Signature Algorithm: sha1WithRSAEncryption
        72:41:42:46:58:dd:08:4d:f6:bc:e1:3a:e7:8e:d0:11:cb:65:
        65:a3:f2:5a:38:75:1b:e6:2b:ba:4a:c7:ed:39:c0:8d:47:75:
        e6:1f:68:6f:76:3c:87:b5:7a:70:ec:a0:1a:00:fc:8a:f8:97:
        73:3d:f5:07:71:56:3e:cb:c2:87:7d:68:e7:a0:29:b5:99:e7:
        40:3d:7b:02:b8:7b:d0:96:7a:59:66:ab:0b:21:11:69:cc:5d:
        80:88:88:28:4b:3b:1e:e1:63:58:f6:20:de:7b:fd:a6:cd:4c:
        a0:1b:97:46:e6:21:94:8d:ac:5e:37:5d:a5:3d:1d:22:9e:77:
        9d:e0:41:17:5a:c4:27:40:b9:e9:7f:5f:10:97:0c:10:2a:00:
        d0:35:b3:16:57:8d:7a:ac:c9:d9:b8:b4:05:50:90:55:83:63:
        de:ad:e9:e4:db:19:6a:cf:20:d0:80:8e:78:af:01:aa:6a:89:
        0c:cf:40:2e:b9:0c:ba:fd:fa:20:99:67:59:64:0f:65:c6:fe:
        bb:ac:e0:08:20:21:f4:b0:00:f5:b6:9e:85:70:13:b2:75:c9:
        a7:dd:9a:94:6e:9a:ef:a3:31:f8:ed:56:71:4f:1a:76:07:62:
        cb:77:ef:00:fa:1e:d9:c6:31:52:41:e5:fc:6c:02:00:41:5a:
        04:2b:71:67:81:0e:63:fa:c9:2c:ae:f2:a9:22:10:43:86:f3:
        56:5a:f9:db:f9:86:18:da:d4:82:25:d2:dd:ab:fc:a5:62:00:
        15:93:59:9e:cc:40:18:43:6d:94:f7:77:30:df:5c:50:b4:d4:
        12:74:04:0d:ab:f8:72:88:44:ed:0f:60:01:96:6d:f4:6b:ff:
        4c:aa:ae:82:cf:ef:7a:53:e4:62:7b:88:6a:46:17:f2:bf:24:
        fb:0e:45:64:ff:34:23:af:ad:49:ec:2d:af:fd:a7:ea:f3:dd:
        7c:15:2a:86:9f:04:45:6a:18:e8:bd:4d:c4:9a:c0:f8:34:d8:
        40:5f:5a:f0:e4:95:43:74:c6:9a:b5:73:3a:b9:c3:7f:77:83:
        b5:9e:4c:d4:8d:9d:38:80:1e:63:42:45:0b:47:22:2e:7f:95:
        ed:c3:bd:61:e9:1e:a3:23:d3:fd:b4:23:68:66:7f:e2:72:c6:
        8d:5f:52:4f:17:43:68:89:a9:95:50:1a:ae:10:8c:4d:7f:85:
        3a:8c:6d:62:eb:37:9b:b5:ec:ab:9e:e0:a3:99:a0:45:a3:07:
        fe:5d:4a:57:8f:25:13:6c:48:a7:81:b7:4e:e2:ae:ab:86:d7:
        95:18:b2:bf:cc:4d:5f:0e:89:51:32:86:28:65:8b:46:2a:11:
        a0:76:df:6e:32:20:11:cc
-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQBFU7GF5UXhPPMV8jk1Q+mDANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEEwHhcNMDcwMTI2MTEzMDQ4WhcNMDgwMTI2MTIw
NjEyWjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAovZwUb9JtuyobaNVr0sB/bFtZKSDaJ5lXF8So0hf7Q6j
3/dOIOGFJSb0/rdb5T1SiB++qDx/jXinVtVQIpOJ2eFe8CPGzMly4iHzzs9LuE1+
SeOYnRAJybjT0cY29ExGxtoVJKMKZlxdn8M3pjOglfNU8eKt8vyCVq1W0Zr+zykC
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFMy/3qeQd2JqHXhp
Lgo4m3dRUwPwMBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFJUzOVgd
wLi/Fc44T7AIljvTGd9lMA0GCSqGSIb3DQEBBQUAA4ICAQByQUJGWN0ITfa84Trn
jtARy2Vlo/JaOHUb5iu6SsftOcCNR3XmH2hvdjyHtXpw7KAaAPyK+JdzPfUHcVY+
y8KHfWjnoCm1medAPXsCuHvQlnpZZqsLIRFpzF2AiIgoSzse4WNY9iDee/2mzUyg
G5dG5iGUjaxeN12lPR0inned4EEXWsQnQLnpf18QlwwQKgDQNbMWV416rMnZuLQF
UJBVg2Perenk2xlqzyDQgI54rwGqaokMz0AuuQy6/fogmWdZZA9lxv67rOAIICH0
sAD1tp6FcBOydcmn3ZqUbprvozH47VZxTxp2B2LLd+8A+h7ZxjFSQeX8bAIAQVoE
K3FngQ5j+sksrvKpIhBDhvNWWvnb+YYY2tSCJdLdq/ylYgAVk1mezEAYQ22U93cw
31xQtNQSdAQNq/hyiETtD2ABlm30a/9Mqq6Cz+96U+Rie4hqRhfyvyT7DkVk/zQj
r61J7C2v/afq8918FSqGnwRFahjovU3EmsD4NNhAX1rw5JVDdMaatXM6ucN/d4O1
nkzUjZ04gB5jQkULRyIuf5Xtw71h6R6jI9P9tCNoZn/icsaNX1JPF0NoiamVUBqu
EIxNf4U6jG1i6zebteyrnuCjmaBFowf+XUpXjyUTbEingbdO4q6rhteVGLK/zE1f
DolRMoYoZYtGKhGgdt9uMiARzA==
-----END CERTIFICATE-----
APPENDIX 2. Chain validation certificate for SSC Root CA B:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            f7:fb:65:f9:cb:97:8b:31:8d:1b:e6:e2:60:77:6f:e2
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=LT, O=Skaitmeninio sertifikavimo centras, OU=Certification Authority, CN=SSC Root CA B
        Validity
            Not Before: Jan 26 11:32:12 2007 GMT
            Not After : Jan 26 12:08:48 2008 GMT
        Subject: emailAddress=[e-mail], C=LT, O=UAB Skaitmeninio sertifikavimo centras, OU=Only for CHAIN VALIDATION TESTING purposes, CN=Noname certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:cc:91:6d:15:17:6f:24:54:25:62:8a:7e:2a:95:
                    2e:f5:86:02:93:2c:c9:ff:7f:eb:f7:65:08:bf:d4:
                    bc:62:b6:bd:1b:ba:14:56:03:1f:3e:91:96:3e:f8:
                    6e:e1:82:2f:1b:ef:1b:68:7a:cf:77:d1:00:e4:2d:
                    bf:ec:ba:db:07:f8:f0:74:58:5f:2e:b5:10:48:00:
                    4c:d3:87:9e:41:5b:ca:5a:45:3e:ff:a9:17:74:fe:
                    e4:75:af:b4:e4:81:e0:38:31:9d:fd:f0:75:a1:c4:
                    ca:19:99:53:09:e0:f2:9f:fa:7e:08:99:02:8a:cd:
                    12:e5:ef:75:c4:ad:9c:dc:cd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Authority Key Identifier:
                keyid:9C:03:F0:A8:D2:98:72:68:AE:F2:ED:E0:4F:E2:85:0E:B2:25:4E:CF

            X509v3 Subject Alternative Name:
                email:[e-mail]
            X509v3 Subject Key Identifier:
                E3:C8:C1:C7:0D:D4:45:67:F4:04:07:5C:51:83:8D:17:76:78:A4:B1

    Signature Algorithm: sha1WithRSAEncryption
        0d:bc:d6:26:c7:c5:85:a7:82:61:d5:2f:34:0e:64:cf:68:a4:
        65:3b:a7:0a:25:d5:cb:55:43:fe:4a:b2:4d:84:9e:c9:01:d5:
        ca:46:05:86:73:66:8c:42:00:49:16:45:26:09:44:20:0a:d5:
        3a:16:a5:b3:1c:a5:ad:0b:53:06:7a:46:f1:75:1c:74:be:8d:
        78:a2:ec:ec:0a:f0:48:5b:cd:33:e8:34:75:5f:97:fd:81:74:
        f5:e5:77:f2:38:c7:be:ee:5c:9c:d5:77:3b:d0:e2:82:53:4f:
        24:cf:af:58:71:7d:d5:40:b6:8c:66:68:0d:58:cd:b4:21:b7:
        70:34:ee:eb:83:07:2d:82:6e:73:12:83:f2:86:50:33:20:a8:
        76:c4:bb:5d:74:99:65:d4:0e:2e:5f:64:d4:b8:fc:d5:41:88:
        de:b0:74:54:dd:6f:88:4e:da:6a:2a:cc:24:44:bc:56:55:2a:
        f2:2f:79:f0:ae:81:85:6b:43:d1:86:30:2a:cb:0a:d4:9d:1c:
        24:09:d5:d3:dd:88:74:6b:6a:d6:95:6c:9a:64:4c:a4:6c:7a:
        3c:15:9b:9a:23:4f:e6:05:7a:b9:0d:f4:8a:e6:e5:26:e1:3b:
        60:cd:6f:3c:f6:db:ed:09:92:40:37:53:c1:df:d0:09:36:5c:
        99:79:ec:d0:94:a8:9d:cc:f1:af:77:9e:7e:0e:a9:ce:1b:66:
        94:2d:4f:3c:44:31:db:ff:44:f0:2c:1e:08:bc:e8:14:4f:30:
        cf:11:46:2c:ab:57:cd:c1:cc:48:c4:19:f9:49:9f:47:08:b9:
        f4:4e:c6:f3:b5:4a:e7:57:b2:e5:bb:24:5b:a4:fb:ba:5d:4b:
        d2:00:7f:72:19:66:3a:61:24:59:30:c4:d7:42:bc:03:22:7d:
        bc:96:79:5c:bf:66:42:50:fb:d8:0b:d0:bf:f6:61:62:95:c1:
        4d:07:de:76:99:18:50:6a:b0:84:9b:b4:c7:d4:cd:6d:8d:5d:
        f5:1c:00:c8:5e:a2:0e:19:53:88:16:6a:0a:7f:a8:35:c4:40:
        7d:f7:ef:f7:c6:1f:c5:96:a2:c4:e7:0a:35:af:55:8f:bb:0a:
        4b:62:61:e4:53:fc:ba:d5:7f:b3:38:90:d2:d8:63:55:bd:6b:
        d6:45:9d:91:58:72:31:23:54:71:cf:b9:64:4d:b5:38:d7:4e:
        9e:9b:bd:03:fe:09:8c:c6:92:3b:f1:de:ef:8d:af:52:d7:2c:
        45:b1:2c:de:29:34:42:35:9c:22:ba:28:ad:74:6f:5f:09:2c:
        d6:27:ab:dc:ac:5d:88:19:11:a3:b6:86:a1:89:f9:78:c5:33:
        d2:19:86:95:b8:52:9d:20

-----BEGIN CERTIFICATE-----
MIIEkDCCAnigAwIBAgIRAPf7ZfnLl4sxjRvm4mB3b+IwDQYJKoZIhvcNAQEFBQAw
dDELMAkGA1UEBhMCTFQxKzApBgNVBAoTIlNrYWl0bWVuaW5pbyBzZXJ0aWZpa2F2
aW1vIGNlbnRyYXMxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MRYw
FAYDVQQDEw1TU0MgUm9vdCBDQSBCMB4XDTA3MDEyNjExMzIxMloXDTA4MDEyNjEy
MDg0OFowgasxGTAXBgkqhkiG9w0BCQEWCmFhYUBiYmIuY2MxCzAJBgNVBAYTAkxU
MS8wLQYDVQQKEyZVQUIgU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZpbW8gY2VudHJh
czEzMDEGA1UECxMqT25seSBmb3IgQ0hBSU4gVkFMSURBVElPTiBURVNUSU5HIHB1
cnBvc2VzMRswGQYDVQQDExJOb25hbWUgY2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMyRbRUXbyRUJWKKfiqVLvWGApMsyf9/6/dlCL/UvGK2
vRu6FFYDHz6Rlj74buGCLxvvG2h6z3fRAOQtv+y62wf48HRYXy61EEgATNOHnkFb
ylpFPv+pF3T+5HWvtOSB4Dgxnf3wdaHEyhmZUwng8p/6fgiZAorNEuXvdcStnNzN
AgMBAAGjaTBnMA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBScA/Co0phyaK7y
7eBP4oUOsiVOzzAVBgNVHREEDjAMgQphYWFAYmJiLmNjMB0GA1UdDgQWBBTjyMHH
DdRFZ/QEB1xRg40XdniksTANBgkqhkiG9w0BAQUFAAOCAgEADbzWJsfFhaeCYdUv
NA5kz2ikZTunCiXVy1VD/kqyTYSeyQHVykYFhnNmjEIASRZFJglEIArVOhalsxyl
rQtTBnpG8XUcdL6NeKLs7ArwSFvNM+g0dV+X/YF09eV38jjHvu5cnNV3O9DiglNP
JM+vWHF91UC2jGZoDVjNtCG3cDTu64MHLYJucxKD8oZQMyCodsS7XXSZZdQOLl9k
1Lj81UGI3rB0VN1viE7aairMJES8VlUq8i958K6BhWtD0YYwKssK1J0cJAnV092I
dGtq1pVsmmRMpGx6PBWbmiNP5gV6uQ30iublJuE7YM1vPPbb7QmSQDdTwd/QCTZc
mXns0JSonczxr3eefg6pzhtmlC1PPEQx2/9E8CweCLzoFE8wzxFGLKtXzcHMSMQZ
+UmfRwi59E7G87VK51ey5bskW6T7ul1L0gB/chlmOmEkWTDE10K8AyJ9vJZ5XL9m
QlD72AvQv/ZhYpXBTQfedpkYUGqwhJu0x9TNbY1d9RwAyF6iDhlTiBZqCn+oNcRA
fffv98YfxZaixOcKNa9Vj7sKS2Jh5FP8utV/sziQ0thjVb1r1kWdkVhyMSNUcc+5
ZE21ONdOnpu9A/4JjMaSO/He742vUtcsRbEs3ik0QjWcIroorXRvXwks1ier3Kxd
iBkRo7aGoYn5eMUz0hmGlbhSnSA=
-----END CERTIFICATE-----

APPENDIX 3. Chain validation certificate for SSC Root CA C:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4d:d7:c3:00:4e:f1:f5:48:2f:fa:5f:c7:c0:4f:af:3b
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=LT, O=Skaitmeninio sertifikavimo centras, OU=Certification Authority, CN=SSC Root CA C
        Validity
            Not Before: Jan 26 11:32:57 2007 GMT
            Not After : Jan 26 12:11:57 2008 GMT
        Subject: emailAddress=[e-mail], C=LT, O=UAB Skaitmeninio sertifikavimo centras, OU=Only for CHAIN VALIDATION TESTING purposes, CN=Noname certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:a9:92:cf:63:37:48:09:8a:1c:c0:a2:e2:be:82:
                    0a:41:c0:52:20:8c:19:c8:53:a0:ac:5c:75:61:07:
                    3b:8c:fa:e6:07:3b:c7:17:ec:10:7e:80:1b:52:3d:
                    ca:2b:1c:22:0b:16:47:a3:69:b9:73:af:70:cd:5a:
                    b6:62:e3:5d:b6:89:30:16:7c:eb:2d:a5:da:bf:d6:
                    da:b4:09:57:56:61:31:b9:d6:1c:94:6d:3d:56:e5:
                    14:6d:16:93:5e:07:51:4c:3c:d8:e9:72:01:4a:0b:
                    15:fa:f0:01:98:f8:b9:4e:8c:e9:e9:70:c1:be:b5:
                    04:9f:e6:5e:12:3b:c6:7d:7d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Authority Key Identifier:
                keyid:88:07:73:F6:F1:BC:52:1A:5A:1D:3D:91:62:ED:5D:AC:9D:0B:E5:B7

            X509v3 Subject Alternative Name:
                email:[e-mail]
            X509v3 Subject Key Identifier:
                5C:23:12:C0:88:63:17:0B:49:94:FD:A6:24:A0:20:C4:43:EA:31:91
    Signature Algorithm: sha1WithRSAEncryption
        26:23:f3:04:fe:a5:60:55:c3:dc:08:50:1b:cf:8b:e2:77:b1:
        78:22:a7:f3:d7:0d:f0:68:2d:8b:0e:f4:7f:3c:da:d1:35:19:
        2a:f4:3f:48:0f:b2:1c:8c:01:98:17:5c:5c:aa:dd:41:d9:01:
        02:23:78:f8:3b:f7:b2:42:48:31:07:99:8a:7e:b5:f2:5d:30:
        18:43:8a:f6:1f:c3:eb:9e:82:68:e8:3e:92:1d:e6:3a:90:19:
        43:7c:da:77:66:12:c4:05:f5:41:c3:2e:c7:c2:51:14:a9:d4:
        87:63:75:50:35:07:9f:62:78:01:60:40:cb:02:c4:6a:ae:4f:
        a0:9f:40:78:fe:d8:97:b8:eb:6d:15:e5:cc:52:1c:71:bf:06:
        83:07:31:ef:e6:09:e5:d0:6f:3b:74:51:58:27:1b:8e:57:5a:
        c4:a4:6c:e8:49:2f:14:6f:e2:af:df:a2:0b:a9:5d:13:05:89:
        35:de:c9:61:78:bc:53:c9:b5:8e:06:c2:36:3b:11:6b:cc:24:
        61:2c:e2:be:7a:a9:75:57:1e:f1:00:49:aa:1e:26:58:4a:02:
        3a:96:3f:e6:44:5f:dd:2f:f8:99:e6:2b:d2:4b:78:d5:14:3d:
        fe:06:a2:ef:08:98:00:60:7e:7a:14:1e:41:9c:b3:9e:8a:d5:
        cb:e0:04:f7:43:a0:07:5b:7f:17:ef:d9:f5:77:15:2c:59:2f:
        e5:4b:4f:62:01:01:49:ca:ba:a7:e4:05:54:17:06:b0:be:84:
        5d:49:13:d8:6a:7b:6b:6f:17:e8:d8:ff:3b:af:00:9a:b4:ed:
        7d:0e:46:7c:e0:de:01:d1:d3:8e:85:c8:4a:27:98:8a:b9:a5:
        25:9d:8d:65:81:c1:66:96:aa:96:20:c1:b2:93:06:1f:94:8f:
        67:44:04:73:b4:b2:7b:ad:78:ae:9f:67:b0:90:17:6c:c5:99:
        44:f9:5b:94:57:6a:52:e1:e0:2b:78:4f:e0:f4:3d:b5:f3:73:
        5d:fc:53:a5:f1:7c:c6:61:34:27:8f:a0:e8:79:1d:fb:28:63:
        e6:8e:81:fc:5f:bd:bd:a9:75:0b:32:e3:ee:d6:45:f0:dc:41:
        60:2f:07:92:42:00:fc:d1:d5:c8:49:5f:c2:c9:43:58:d6:90:
        10:89:46:df:57:21:58:f3:14:ce:32:59:37:de:14:9c:4a:63:
        f4:ba:34:01:ba:98:d6:40:e9:ed:0a:86:88:91:aa:68:2a:07:
        6d:31:1a:b0:73:8f:d1:a7:e5:9e:c7:a7:c1:6a:64:bb:6c:7d:
        23:fd:64:79:d4:f0:f8:5a:73:9b:4b:ff:e9:3f:39:18:0a:ef:
        76:cc:da:7e:7b:c0:4b:09

-----BEGIN CERTIFICATE-----
MIIEjzCCAnegAwIBAgIQTdfDAE7x9Ugv+l/HwE+vOzANBgkqhkiG9w0BAQUFADB0
MQswCQYDVQQGEwJMVDErMCkGA1UEChMiU2thaXRtZW5pbmlvIHNlcnRpZmlrYXZp
bW8gY2VudHJhczEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAU
BgNVBAMTDVNTQyBSb290IENBIEMwHhcNMDcwMTI2MTEzMjU3WhcNMDgwMTI2MTIx
MTU3WjCBqzEZMBcGCSqGSIb3DQEJARYKYWFhQGJiYi5jYzELMAkGA1UEBhMCTFQx
LzAtBgNVBAoTJlVBQiBTa2FpdG1lbmluaW8gc2VydGlmaWthdmltbyBjZW50cmFz
MTMwMQYDVQQLEypPbmx5IGZvciBDSEFJTiBWQUxJREFUSU9OIFRFU1RJTkcgcHVy
cG9zZXMxGzAZBgNVBAMTEk5vbmFtZSBjZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAqZLPYzdICYocwKLivoIKQcBSIIwZyFOgrFx1YQc7jPrm
BzvHF+wQfoAbUj3KKxwiCxZHo2m5c69wzVq2YuNdtokwFnzrLaXav9batAlXVmEx
udYclG09VuUUbRaTXgdRTDzY6XIBSgsV+vABmPi5Tozp6XDBvrUEn+ZeEjvGfX0C
AwEAAaNpMGcwDgYDVR0PAQH/BAQDAgeAMB8GA1UdIwQYMBaAFIgHc/bxvFIaWh09
kWLtXaydC+W3MBUGA1UdEQQOMAyBCmFhYUBiYmIuY2MwHQYDVR0OBBYEFFwjEsCI
YxcLSZT9piSgIMRD6jGRMA0GCSqGSIb3DQEBBQUAA4ICAQAmI/ME/qVgVcPcCFAb
z4vid7F4Iqfz1w3waC2LDvR/PNrRNRkq9D9ID7IcjAGYF1xcqt1B2QECI3j4O/ey
QkgxB5mKfrXyXTAYQ4r2H8PrnoJo6D6SHeY6kBlDfNp3ZhLEBfVBwy7HwlEUqdSH
Y3VQNQefYngBYEDLAsRqrk+gn0B4/tiXuOttFeXMUhxxvwaDBzHv5gnl0G87dFFY
JxuOV1rEpGzoSS8Ub+Kv36ILqV0TBYk13slheLxTybWOBsI2OxFrzCRhLOK+eql1
Vx7xAEmqHiZYSgI6lj/mRF/dL/iZ5ivSS3jVFD3+BqLvCJgAYH56FB5BnLOeitXL
4AT3Q6AHW38X79n1dxUsWS/lS09iAQFJyrqn5AVUFwawvoRdSRPYantrbxfo2P87
rwCatO19DkZ84N4B0dOOhchKJ5iKuaUlnY1lgcFmlqqWIMGykwYflI9nRARztLJ7
rXiun2ewkBdsxZlE+VuUV2pS4eAreE/g9D2183Nd/FOl8XzGYTQnj6DoeR37KGPm
joH8X729qXULMuPu1kXw3EFgLweSQgD80dXISV/CyUNY1pAQiUbfVyFY8xTOMlk3
3hScSmP0ujQBupjWQOntCoaIkapoKgdtMRqwc4/Rp+Wex6fBamS7bH0j/WR51PD4
WnObS//pPzkYCu92zNp+e8BLCQ==
-----END CERTIFICATE-----

Comment 14

[Gervase Markham [:gerv]]

Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv

Comment 15

[Moudrick]

Hi Frank, can you please update us on the status of this request?-Thank you for your time.

M.D.

Comment 16

[Moudrick]

Hello, is anybody checking this?

Comment 17

[Moudrick]

Dear Frank,

We know you are busy. As we are involved in eGovernment project developments it's becoming critical for us to know the status of this request.

If you can please leave here a short note on how long it will take us to have our root cert be a FF built-in object.

Thank you for your time.

M.D.

Comment 18

[Frank Hecker]

Assigning to Kathleen Wilson to do information gathering for this request. This is the first step in considering this request and potentially approving it. The whole process might take 2-3 months.

Comment 19

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

As per Frank’s note, I have been asked to do the information gathering and verification for this request. Attached is the initial information-gathering document which summarizes the information that has been gathered thus far. Within the document I have highlighted in yellow the information that is still needed, and I will summarize below.

1) The URL for the Root C CRL (http://crl.ssc.lt/root-c/cacrl.crl) gives 404 error (not found).

2) Is there a statement in the CP/CPS that specifies the frequency of update for the CRLs for the end-entity certificates chaining up to these roots? Would you please translate the relevant text into English?

3) Please provide a description of subordinate CAs operated by the CA organization associated with the root CA. As you will see in the attached info-gathering document, I gathered some of this information from the CPS, but please verify and clarify. For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CP/CPS, and that any audit covers them as well as the root. 

4) For the subordinate CAs that are operated by third parties, please provide a general description and explain how the CP/CPS and audits ensure the third parties are in compliance.

5) Have any of these roots been involved in cross-signing?

6) I am supposed to review the CP/CPS to ensure that procedures are in place to do the following. Would you please translate the relevant text from the latest CP or CPS into English?
a) For SSL, verify that the domain referenced in the certificate is owned/controlled by the certificate subscriber. 
b) Verify the email account associated with the email address in the cert is owned by the subscriber, in addition to verification of subscriber’s legal identity.
c) Verify identity information in code signing certificates is that of subscriber
d) Make sure it’s clear which checks are done for which context (cert usage)
We are looking for text that describes exactly what information is verified, and how the information is verified.

7) Please specify DV (Domain Verified) and/or OV (Organization attribute Verified).

8) For each root, please provide a URL to a website whose cert chains up to the root. The site can be either a test site or a live site.

9) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not in English, would you please comment as to whether any of these are relevant.
If relevant, please provide further info:
•     Long-Lived Domain-Validated SSL certs 
•     Wildcard DV SSL certs
•     Issuing end entity certs directly from root rather than using an
offline root and issuing certs through a subordinate CA 
•     Allowing external entities to operate subordinate CAs – in this case
need to demonstrate that the external entities are required to follow the CPS
and are audited as such.

Thanks,
Kathleen

Comment 20

[Moudrick]

Attachment: This is updated version of your original file, questions answered.

Comment 21

[Moudrick]

Dear Kathleen, attached please find the information you requested. Please let me know if you need more info or have questions. Thank you for your time.

Best Regards,
M.D.
cell: [phone]

https://bugzilla.mozilla.org/attachment.cgi?id=331830

Comment 22

[Kathleen Wilson]

M.D.,

Thank you for your thorough response. 

Would you please provide a little more clarification on your procedures for email certificates as stated in the CPS to verify that the email account associated with the email address in the cert is owned by the subscriber?

Other than that clarification and my completing the process to independently verify the authenticity of the audit report, the information for Root A is complete.

The purpose of including Root B and Root C in Firefox is not clear to me, perhaps because I don’t understand their usage. Would you please provide more information about the purpose and use of roots B and C, especially in regards to inclusion in Firefox? 

If Root C is to be considered for inclusion in Firefox, when do you plan to launch that root and have the CRL operational? Would you want to move forward with Root A now, and input another request when Root C is ready?

The website certs for https://www.ssc.lt/certs/noname_cert_b.pem and https://www.ssc.lt/certs/noname_cert_c.pem both chain up to Root A. If Root B and C are to be considered for inclusion in Firefox, we’ll need URLs to websites whose certs chain up to them.

Thanks,
Kathleen

Comment 23

[Moudrick]

Dear Kathleen,

here are answers to your questions:

1. Email address verification for email certificates:

Note that email certificates are in their nature anonymous and for this type of certificates (Class 1), we don't check owner's identity.

However, the procedure of email address verification is still the same as for all other types of certificates. Applicant fills in the form on our web site, where he/she indicates the email address, selects the type of certificate and chooses a password. After that we offer the applicant to check his/her mailbox and click on the URL provided in the message. When he/she accesses his/her mailbox and clicks on the URL we prompt for the previuosely declared password. It's important to note, that for Class 2 and 3 certificates (Identity verified), we accept non-public domain name hosted email addresses only. And in case of legal entity we additionally check the ownership of the domain name according to DNS (whois). In latter case we might reqest the applicant to provide us with a proof of ownership other than whois (contract, order form, invoice etc.). 

2. Root B and C clarification.

Root B is used for single-root certificates (SSL, Code Signing, OCSP, time stamping) and Root C serves as a backup CA for Root A i B. Just in case any of these two roots become unusable and become revocated, then we switch to using C. That's why we haven't had CRLs for this Root.

According to the govenment project I mentioned in one of my messages above, Root C will have to be tested in a specific project where we should demonstrate availability of its CRL and OCSP services. Again, the project will accept Root C only if it is FireFox' buil-in object.
In the meantime for the convenience of your verification we have already published Root C, so you can check it now.

3. URLs to websites whose certs chain up to Root B and C.

I think in the context of my answers above your last question need to be slightly adjusted. If I understood you correctly you needed a sample certificate issued by each of these roots for appropriate chain validation. Keeping in mind that not all of them issue SSL certificates, the sample certificates issued by each of these roots are not necessarily SSL. However you can still verify the chain by referencing to the samples provided above.

Please let us know if you need more questions or need more info.

Thank you for your time.

Best regards,

M.D.
cell: [phone]

Comment 24

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Attached is the completed document summarizing the information that has been gathered and verified.

I already added root A to the pending list(http://www.mozilla.org/projects/security/certs/pending/#SSC). I will add roots B and C, but there will be a delay of a few days before the changes will be visible.

Comment 25

[Kathleen Wilson]

While I was updating the pending list I realized that you mentioned OCSP.  Are there OCSP responder URLs that you can provide for these three roots?

Comment 26

[Moudrick]

Yes, the OCSP address is:

http://ocsp.ssc.lt:2560

For validation you can also use this form:

http://www.ssc.lt/ocsp/

Thank you for your time.

Best regards,

M.D.
cell: [phone]

Comment 27

[Kathleen Wilson]

The information gathering phase of this request is complete.

Assigning to Frank, so he can proceed with the public discussion phase.

Kathleen

Comment 28

[Moudrick]

Hi Frank, can you please update us on the status of this request?

Thank you for your time.

M.D.
cell: [phone]

Comment 29

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

As per the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
This request is scheduled to enter public discussion in the next couple of weeks. As such, I need to update the information to make sure this request is ready.

I have attached an updated Information Gathering and Verification document. Please review the document for accuracy and completeness. There are a few items highlighted in yellow that I will need clarification on. I will summarize below.

1)I get an error when I force OCSP in Firefox to use either of these OCSP responders, and try to access https://www.dokumentai.lt/data/.
http://ocsp.ssc.lt:2560
http://www.ssc.lt/ocsp/
Would you please try it in Firefox (after importing the Root A cert)? Does it work for you?

2) I am unclear about SSC Root CA B
a) Which trust bits should be enabled for Root B?  It looks like it is used for SSL, Code Signing, OCSP, and time stamping. So I expect that the website and code signing trust bits should be enabled. What about the email trust bit?
b) Please identify which sections of the CPS are relevant for Root B in regards to verification procedures. In particular, please refer to section 7 of http://www.mozilla.org/projects/security/certs/policy/.

3) Please review the updated potentially problematic practices at 
http://wiki.mozilla.org/CA:Problematic_Practices
And provide further information about the ones that are relevant.
See the bottom section of the attached document for where more info is needed.

4) I see that SSC is still a qualified CA as per
http://epp.ivpk.lt/en/providers/
However, the auditor statement is from 2006. Please provide a more recent statement with info about your most recent annual audit of the operation of these roots.

Comment 30

[Moudrick]

Dear Kathleen,

here are answers to your questions:

1)I get an error when I force OCSP in Firefox to use either of these OCSP
responders, and try to access https://www.dokumentai.lt/data/.
http://ocsp.ssc.lt:2560
http://www.ssc.lt/ocsp/
Would you please try it in Firefox (after importing the Root A cert)? Does it
work for you?

Yes, it does. We suspect the errors might be the result of network outages caused by some networking equipment updgrade. If you try it now it should work fine.

2) I am unclear about SSC Root CA B
a) Which trust bits should be enabled for Root B?  It looks like it is used for
SSL, Code Signing, OCSP, and time stamping. So I expect that the website and
code signing trust bits should be enabled. What about the email trust bit?
b) Please identify which sections of the CPS are relevant for Root B in regards
to verification procedures. In particular, please refer to section 7 of
http://www.mozilla.org/projects/security/certs/policy/.

a) Following trust bits should be enabled for Root B:

- Server Authentication
- Client Authentication
- Code Signing
- Secure Email
- Time Stamping

Although in practice this Root CA is mainly used for SSL, Code Signing, OCSP and time stamping purposes, you are right, the secure email has to be also enabled.

b) As we have explained earlier the identity verification is the same for all roots wheather we deal with a phisycal entity or legal entity. This means that the same identity verification applies no matter which Root CA is involved. Appropriate verification procedures presented in Chapter 3 of the CPS (Page 29) more detailed procedures have been descrobed in instructions manuals for the operating personell.

3) Please review the updated potentially problematic practices at 
http://wiki.mozilla.org/CA:Problematic_Practices
And provide further information about the ones that are relevant.
See the bottom section of the attached document for where more info is needed.

Following aspects can be treated as "problematis practices":

- Issuing end entity certificates directly from roots.

Although still under consideration, but we are planning to issue single root SSL certs for various services.

- OCSP Responses signed by a certificate under a different root.

Based on the actual usage, we have a single OCSP server running for all CAs. However as the number of eservices exploring PKI technologies reaches a certain level, each CA or group of CAswill have a separate OCSP server. 

4) I see that SSC is still a qualified CA as per
http://epp.ivpk.lt/en/providers/
However, the auditor statement is from 2006. Please provide a more recent
statement with info about your most recent annual audit of the operation of
these roots.

The most recent statement can be found here:

http://www.ssc.lt/files/SSC%20CA%20Application%20to%20Trusted%20Root%20CA%20program.pdf

Please let me know if I missed something.

Tbhank youfor your time.

Best Regards,
M.D.
cell: [phone]

Comment 31

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 32

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.

Comment 33

[Kathleen Wilson]

I am now opening the first public discussion period for this request from SSC to add the SSC Root CA A, SSC Root CA B, and SSC Root CA C root certificates to Mozilla.

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “SSC Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

Comment 34

[Kathleen Wilson]

The first round of public discussion for the SSC Root Inclusion Request is now closed. 

The summary of action items that will need to be completed before entering the second round of public discussion is as follows:

1) SSC’s original plan was to have one OCSP service for all roots. After discussion, SSC has stated that they will provide a separate OCSP service for each root so that the OCSP responses will be signed by certificates chaining up to each root. SSC has prepared a technical separation solution and stated their intent to put it into operation.

2) Based on the discussion, SSC has proposed a modification to the roles of each root:
Root A - remains as is (only VS has to be relocated under Root C) 
Root B - SSL and Code Signing 
Root C - VS 
According to this assignment Root A will not change its existing role with the exception that it will not serve personal certificates for government/public sector representatives, this certificates will be served by Root C. The personal certificates for the government/public sector representatives (Root C) have not been issued yet, they are designed for the projected public services. 

SSC has confirmed that no roots will be issuing end entity certs directly.

3) SSC has stated that if there are no objections to this re-alignment of root roles, they will update their CPS to reflect the change.

4) SSC has been requested to provide an English translation of their CPS. 
SSC is encouraged to provide further information to clarify the concern that there may be contracts that bind the roots to certain performance characteristics.

5) SSC has been audited according the ETSI TS 101 456 criteria. The audit statement of ETSI compliance is dated  2008-10-30, but it does not state when the audit was performed. SSC has annual audits, so SSC will ask the auditor to provide a statement that includes the time-frame for which the audit was performed.

Comment 35

[Kathleen Wilson]

Closing this bug, because CA hasn't responded since 2009.

Comment 36

[Moudrick]

Hi Kathleen,

please don't close this bug as SSC has just finished auditing it's services against ETSI 102 042 and ETSI 102 456. Right now we are collecting updates to this bug so that we can finis the application process. Many thanks for understanding.

Best Regards,
M.D.

Comment 37

[Moudrick]

Hi Kathleen,

I'd like to proceed with the process but before that I need a some guidance. As time run SSC has updated its three Root certificates and associated Issuing CA certs. Of course we have updated our CP/CPS, so the older links have to be refreshed too.

So my question is how do I present these updates, do you have any template for that or should I just proceed with the one I started above? Thank you.

M.D.

Comment 38

[Kathleen Wilson]

Since the InfoGathering document for this bug is so old, we'll have to start again:
https://wiki.mozilla.org/CA:Information_checklist
https://wiki.mozilla.org/File:CAInformationTemplate.pdf

We can use this same bug, but will need to use the new template for the CA Information document.

Comment 39

[Moudrick]

Attachment: SSC CA Information.odt

The CA information in new template.

Comment 40

[Moudrick]

Dear Cathleen I've just added the CA information. Please let me know if anything missing. Thank you.

Comment 41

[Moudrick]

Sorry for misspelled name..

Comment 42

[Kathleen Wilson]

Attachment: 379152-CAInformation.pdf

The attached document summarizes the information that has been verified.

Please search the document for "Need Clarification" to find the parts where information/clarification is still needed.

Please review the full document for accuracy and completeness, and provide the necessary information in this bug.

Comment 43

[Moudrick]

Attachment: CONTENT OF IDENTITY REGISTRATION FOR CERTIFICATE ISSUING AND SUBSCRIBER SUPPORT.txt

The translated CONTENT of the Identity verification procedures

Comment 44

[Moudrick]

Attachment: Response to 379152-CAInformation.pdf .odt

Clarification to 379152-CAInformation.pdf

Comment 45

[Moudrick]

Thank you for reviewing the initial CA information. The two attached documents provide information requested. Please let me know if yo need more information.

As explained in the attached document, we maintain a separate Identity verification document which has been part of audit. The intention is to keep the cost of maintaining of a bilingual working document and associated delay in publication under control.

If requested, however, we will transfer the selected parts of this document to CPS. Thank you for understanding!

Comment 46

[Kathleen Wilson]

If I'm reading the information that you sent correctly, then I need translations into English of:
[5] "IDENTITY REGISTRATION FOR CERTIFICATE ISSUING AND SUBSCRIBER SUPPORT" - Please see attached file for the Content of this document in original and English translation.

I looked at the file attached in Comment #43, and it appears to only be translations of section headings.

However, it sounds like that is an internal document.

According to Mozilla policy, a sufficient description of the verification procedures for SSL, Email, and Code Signing certs has to be in a public-facing document, so can you provide the URL to that document? 
English Translation of the relevant sections of the document will also be greatly appreciate.

Please see:
https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs

Comment 47

[Moudrick]

Thank you for reviewing the two lately attached documents.

The main document where we disclose the "ways in which we confirm that the certificate subscriber owns/controls the domain name to be included in the certificate", as required by Mozilla policy you have kindly referenced above, is our CPS, where in section 3.2.4 we say "Information about the Subject, including email address, is included in certificates only after it is reliably verified".

Obviously not awfully explanatory, however not a prohibited Reference to BR section 11 either.

As you correctly noted what "reliably verified" means is explained in an internal working document. There are two reasons why we maintain this information in a separate internal document: 1) frequency of updates and 2) high cost of bilingual versions. Under ETSI 102 042 this is an acceptable approach as long as the identity verification document is subject to audit. SSC's Audit Report confirms this.

Under your request to disclose the domain ownership verification, we translated two relevant sections of the internal document (sections 4.5 and 5.6). We also translated TOC of this document for any potential interest. 

So to sum up, the information about domain ownership, email verification has been disclosed (please see translation of sections 4.5 and 4.6 in my response document) in an internal working document in accordance with ETSI TS 102 042 (The document has to be audited).

However if the way we disclose this information in your opinion doesn't comply with Mozilla policy, we'd move that information from the internal document to CPS. Please advise us if this resolves your concern, we'd update our CPS promptly. Thank you for your time.

Comment 48

[Kathleen Wilson]

(In reply to Moudrick from comment #47)
> However if the way we disclose this information in your opinion doesn't
> comply with Mozilla policy, we'd move that information from the internal
> document to CPS. Please advise us if this resolves your concern, we'd update
> our CPS promptly. Thank you for your time.

Mozilla's policy and practice is to only take public-facing documentation into account when considering root inclusion requests.

Throughout your response attached to Comment #44 you reference internal documentation. However,the questions need to be answered with public-facing documentation.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"6. We require that all CAs whose certificates are distributed with our software products:
... publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);
...prior to issuing certificates, verify certificate signing requests in a manner that we deem acceptable for the stated purpose(s) of the certificates;
... otherwise operate in accordance with published criteria that we deem acceptable; and
provide public attestation of their conformance to the stated verification requirements..."

https://wiki.mozilla.org/CA:How_to_apply
"IMPORTANT Items to Note: The information listed in CA Information Checklist is expected to be publicly available so that it can be reviewed and referenced during the Public Discussion Phase and for future reference."

Comment 49

[Moudrick]

Thank you for your clarification.

I'll try to be as much specific as possible. :)

Indeed, throughout the response attached to Comment #44, we've answered the same remark/question repeated under each of the three Root sections: how do we verify domain name ownership and email address control.

The domain name ownership and email address control verification information in our response has been disclosed explicitly by indicating Document name, section numbers and directly quoting the relevant text.

As the requested information has been disclosed explicitly in both the CPS and in the working internal document (which serves as an Instruction manual for CA's personnel) and both documents have been audited according to ETSI TS 102 042 which, as per section 11 of Mozilla policy, is an accepted operation policy, should we really treat this a ***reference***? In our opinion we shouldn't.

Just to make sure we understood your last comment correctly, do you require that we move the quoted domain name ownership and email address control verification instructions from the working document to CPS? Please advise, thank you.

Comment 50

[Kathleen Wilson]

It needs to be in a public-facing document. Whether it is a public-facing document that is referred to from the CPS, or in the CPS itself, is up to you (as long as the audit statement refers to both). So, if you want to make the currently-internal document publicly available, that is fine. Or, if you want to move the relevant sections into the CPS, that works too. Or, if you want to summarize (with sufficient information, so we can understand the verifications that take place) the steps that are involved in the CPS, that works too -- the idea with it being a summary of the steps involved, is that hopefully that doesn't change as frequently as the details in performing those verification steps.

Comment 51

[Moudrick]

Thanks, Kathleen, the third option looks more reasonable to us.

Should we update the CPS with the summary of steps involved right away or by the end of review process? Thanks.

Comment 52

[Kathleen Wilson]

If you can create a draft of the CPS with the proposed updates and attach it to this bug, then I will use that to move the inclusion process forward. It might also be good to have the public discussion using the draft version of the CPS, in case the discussion results in further updates to the CPS.

Comment 53

[Moudrick]

Attachment: CPS EN FIN 4.10.pdf

This is the new draft version of the CPS.

Comment 54

[Moudrick]

Hi Kathleen,

the new draft of the CPS now is ready for comments:

https://gdl.repository.ssc.lt/en/repository/working-documents/

I've also attached a copy to the bug as requested.

The new draft has two new sections 3.2.4 and 3.25 and also updated section 4 with the overview of the registration process.

Please let us know if you have any questions. Thanks.

Comment 55

[Kathleen Wilson]

Attachment: 379152-CAInformation.pdf

Please confirm (by commenting in this bug) if all of the information in the attached document is correct.

Comment 56

[Moudrick]

Thank you, Kathleen, the information in your attached document is correct.

I've a short comment about the EV Policy OID(s) on page 6 of the attached document. Due to our today's vision the possible policy OIDs in EV SSL certificates can be:

- only ETSI OID (as in the document now)
- only CAB Forum EV SSL OID (should we add this to the document?)
- both the ETSI and CAB Forum OIDs (should we add this to the document?).

Many thanks for your time.

Comment 57

[Kathleen Wilson]

(In reply to Moudrick from comment #56)
> Thank you, Kathleen, the information in your attached document is correct.
> 
> I've a short comment about the EV Policy OID(s) on page 6 of the attached
> document. Due to our today's vision the possible policy OIDs in EV SSL
> certificates can be:
> 
> - only ETSI OID (as in the document now)
> - only CAB Forum EV SSL OID (should we add this to the document?)
> - both the ETSI and CAB Forum OIDs (should we add this to the document?).
> 
> Many thanks for your time.

Which EV Policy OID will you be using to issue EV SSL certs?

I don't understand what you mean by only ETSI and only CAB Forum. To be recognized for EV treatment in Mozilla products, the certificate issuance must be in compliance with both.

Comment 58

[Moudrick]

Trying to answer your question, possible OID value in EV certs would be ***one*** of the following:

0.4.0.2042.1.4 (ETSI EVCP OID)
2.23.140.1.1 (CAB Forum OID)
0.4.0.2042.1.4 AND 2.23.140.1.1 (both ETSI EVCP and CAB Forum OIDs)

Sorry, as you know, its transitional period for all EU CAs and we need some flexibility in sense of upcoming EV SSL/ETSI EVCP use scenarios. Thanks.

Comment 59

[Kathleen Wilson]

I still do not understand why you need separate EV OIDs to indicate ETSI EV compliance and CAB Forum EV compliance. Are you really planning to issue some EV certs that are only compliant with the ETSI EV criteria, and others that are only compliant with the CAB Forum EV criteria?

Comment 60

[Moudrick]

Kathleen, the need comes from the market demand. Some government customers and public services do require formal "ETSI compliance", whereas majority of other customers would be happy with CAB Forum OID.

To makes things easier we realized that we should use both ETSI and CAB FORUM OIDs together so that you can ignore the ETSI OID. Does this make sense? Thanks.

Comment 61

[Kathleen Wilson]

Attachment: 379152-CAInformation.pdf

Comment 62

[Kathleen Wilson]

I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 63

[Kathleen Wilson]

I'm getting ready to start the public discussion for this request, and noted that the date I have for the statement of the last surveillance audit is July 4, 2014. Has the annual surveillance audit been completed for this year? If yes, please provide a statement from the auditor.

Comment 64

[Moudrick]

Yes, here is the link:

https://gdl.repository.ssc.lt/en/audit/2016/

Thanks.

Comment 65

[Kathleen Wilson]

I am now opening the first public discussion period for this 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. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “SSC Root Inclusion Request”.

Please actively review, respond, and contribute to the discussion.

A representative of SSC must promptly respond directly in the discussion thread to all questions that are posted.

Comment 66

[Moudrick]

Good day, Kathleen

first of all, I apologize for not being able to update the status of this bug earlier.

Unfortunately the process of eIDAS audit requirement clarification has taken much longer than expected. We are actively collaborating with the authorities, potential auditors so that we've a single audit for both the Root programs and eIDAS.

Currently we are negotiating the audit time frame and I'll update this status as soon as I know the final details. Thanks.

Comment 67

[Moudrick]

Attachment: SSC GDL CA Root B QWAC issuing TSP assessment record 2018 - 2019.pdf

Comment 68

[Moudrick]

Attachment: SSC_ETSI_CARs 2018 - 2019 .pdf

Comment 69

[Wayne Thayer]

Moudrick: the attestation letter in comment 67 does not meet Mozilla requirements because it is dated before the end of the audit period. Mozilla policy section 3.1.4(9) states "the date the report was issued (which will necessarily be after the end date or point-in-time date); "

Comment 70

[Moudrick]

Thanks, Wayne. Trying to fix this but still confused a bit. Here is how our dates looks like:

Standard Audit Statement Date : 6/9/2018
Standard Audit Period Start Date: 5/9/2018
Standard Audit Period End Date: 5/21/2018

The Audit Statement date is after the Audit time frame (5/9/2018 to 5/21/2018)..

Comment 71

[Ryan Sleevi]

Moudrick: Are you stating that only 12 days were audited? I can't seem to find reference to May 9 in Comment #67, nor June 9. Instead, the statement is dated 2019-02-08.

It sounds like there is confusion about what an audit period is. The CA/Browser Forum has extensively discussed this, in order to try and ensure there is no ambiguity. Ballot 196 introduced this definition into the Baseline Requirements, after gaining feedback from both WebTrust and ETSI, and states that:

Audit Period: In a period-of-time audit, the period between the first day (start) and the last day of
operations (end) covered by the auditors in their engagement. (This is not the same as the period of time
when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined
in section 8.1.

For example, WebTrust "forbids" (by virtue of the professional engagement standards such as AICPA's AT-C) audit periods of less than two months, without significantly raising concerns about the audit itself, so if it were possible to obtain an ETSI audit for 12 days, that would be concerning.

It sounds as if you're instead interpreting "audit period" to mean the time that the auditors were on-site - an interpretation the Baseline Requirements explicitly calls out as an incorrect understanding.

The Audit Attestation Letter in Comment #67 states:
"It took place from May 21st 2018 until May 22nd 2018 as well as on November 19th, 2018, and covered the period from May 21st 2018 until May 20th 2019."

Please re-review the letter attached in Comment #67. I'm concerned that these dates are not reflected in the paperwork presently provided.

Comment 72

[Moudrick]

Thanks, Ryan. You are right, I misunderstood the audit period.

The dates shown above (5/9/2018 - 5/21/2018) are the timeframe when the audit took place but not the assessment period (which in our case is 1 year).

Our Audit Attestation Letter was issued just a few days ago (because of contractual misunderstandings not related to the audit statement). I'll recheck the dates and then update the case info.

Comment 73

[Kathleen Wilson]

This request will need to go back through the "Information Verification" phase after the CA has provided the following:

1. BR Self Assessment: https://wiki.mozilla.org/CA/BR_Self-Assessment

2. Full audit history for the roots to be included

3. Current audit statements that meet Mozilla's policy requirements
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

4. Current CP/CPS documents

Comment 74

[Kathleen Wilson]

Closing this request per Comment #73, and because these roots have valid from 2013 so it is very likely that these CA hierarchies cannot meet all of our current requirements.
If the CA chooses to create a new root certificate, they may start a new root inclusion request as described here:
https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request