Closed Bug 379152 Opened 18 years ago Closed 6 years ago

Add Lithuanian National Root Certificates

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: md, Assigned: kathleen.a.wilson)

Details

(Whiteboard: [ca-verifying] - Need BR Self Assessment, full audit history, updated CP/CPS)

Attachments

(9 files, 5 obsolete files)

Initial Information Gathering Document
111.00 KB, application/msword
Details
Completed Information Gathering Document
30.77 KB, application/pdf
Details
SSC CA Information.odt
28.15 KB, application/vnd.oasis.opendocument.text
Details
CONTENT OF IDENTITY REGISTRATION FOR CERTIFICATE ISSUING AND SUBSCRIBER SUPPORT.txt
6.44 KB, text/plain
Details
Response to 379152-CAInformation.pdf .odt
27.38 KB, application/vnd.oasis.opendocument.text
Details
CPS EN FIN 4.10.pdf
537.97 KB, application/pdf
Details
379152-CAInformation.pdf
273.55 KB, application/pdf
Details
SSC GDL CA Root B QWAC issuing TSP assessment record 2018 - 2019.pdf
2.12 MB, application/pdf
Details
SSC_ETSI_CARs 2018 - 2019 .pdf
101.00 KB, application/pdf
Details
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: +370-699-26662 office: +370-700-22722 fax: +370-700-22715 email: md@ssc.lt Address: Jogailos 8-16, 01116 Vilnius, LITHUANIA Reproducible: Always Steps to Reproduce: 1. 2. 3.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Lithuaninan National Root Certificates be added to the Mozilla default set → Add Lithuanian National Root Certificates
Priority: -- → P2
Moudrick: If you are not able to respond to the request for more information soon, this bug will be closed. Gerv
(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.
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: +370-699-26662
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-----
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-----
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-----
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
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: +370-699-26662
These certificates seem fine. Feel free to post the rest of the required information. :-) Gerv
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: +370-699-26662
Moudrick: You missed out the section giving details of the certificates. I need three copies of that, one for each certificate. Thanks, Gerv
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=aaa@bbb.cc, 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:aaa@bbb.cc 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=aaa@bbb.cc, 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:aaa@bbb.cc 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=aaa@bbb.cc, 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:aaa@bbb.cc 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-----
Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program. Gerv
Assignee: gerv → hecker
Hi Frank, can you please update us on the status of this request?-Thank you for your time. M.D.
Hello, is anybody checking this?
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.
Status: NEW → ASSIGNED
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.
Assignee: hecker → kathleen95014
Status: ASSIGNED → NEW
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
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: +370-699-26662 https://bugzilla.mozilla.org/attachment.cgi?id=331830
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
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: +370-699-26662
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.
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?
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: +370-699-26662
The information gathering phase of this request is complete. Assigning to Frank, so he can proceed with the public discussion phase. Kathleen
Assignee: kathleen95014 → hecker
Whiteboard: Information confirmed complete
Hi Frank, can you please update us on the status of this request? Thank you for your time. M.D. cell: +370-699-26662
Attached file Updated Information Gathering Document (obsolete) —
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.
Attachment #332480 - Attachment is obsolete: true
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: +370-699-26662
Attachment #364550 - Attachment is obsolete: true
Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
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 dev-security-policy@lists.mozilla.org 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.
Whiteboard: Information confirmed complete → In public discussion
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.
Whiteboard: In public discussion → Public Discussion Action Items - OCSP, Root Roles, CPS, Audit
Closing this bug, because CA hasn't responded since 2009.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
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.
Attached file SSC CA Information.odt —
The CA information in new template.
Attachment #331830 - Attachment is obsolete: true
Dear Cathleen I've just added the CA information. Please let me know if anything missing. Thank you.
Sorry for misspelled name..
Attached file 379152-CAInformation.pdf (obsolete) —
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.
The translated CONTENT of the Identity verification procedures
Clarification to 379152-CAInformation.pdf
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!
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
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.
(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."
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.
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.
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.
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.
Attached file CPS EN FIN 4.10.pdf —
This is the new draft version of the CPS.
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.
Attached file 379152-CAInformation.pdf (obsolete) —
Please confirm (by commenting in this bug) if all of the information in the attached document is correct.
Attachment #8533406 - Attachment is obsolete: true
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.
(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.
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.
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?
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.
Attachment #8615379 - Attachment is obsolete: true
I will try to start the discussion soon. https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: Public Discussion Action Items - OCSP, Root Roles, CPS, Audit → EV - Ready for Public Discussion
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.
Yes, here is the link: https://gdl.repository.ssc.lt/en/audit/2016/ Thanks.
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.
Whiteboard: EV - Ready for Public Discussion → EV - In public discussion
Whiteboard: EV - In public discussion → EV - Discussion on hold pending updated CP/CPS
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.
Whiteboard: EV - Discussion on hold pending updated CP/CPS → [ca-discussion-hold] -- EV - pending updated CP/CPS
Product: mozilla.org → NSS

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); "

Flags: needinfo?(md)
QA Contact: kwilson

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

Flags: needinfo?(md)

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.

Flags: needinfo?(md)

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.

Flags: needinfo?(md)

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

Whiteboard: [ca-discussion-hold] -- EV - pending updated CP/CPS → [ca-verifying] - Need BR Self Assessment, full audit history, updated CP/CPS

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

Status: REOPENED → RESOLVED
Closed: 12 years ago → 6 years ago
Resolution: --- → WONTFIX
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: