Closed Bug 406968 Opened 17 years ago Closed 14 years ago

ADD camerifirma EV root certificates

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

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

References

(
URL
)

Details

(Whiteboard: EV - In FF4Beta)

Attachments

(14 files)

Global Chambersign Root - 2008
2.56 KB, application/x-x509-ca-cert
Details
Chambers of Commerce Root - 2008
2.57 KB, application/x-x509-ca-cert
Details
Initial Information Gathering Document
110.00 KB, application/msword
Details
auditor letter
22.32 KB, image/tiff
Details
answers to previous doc 406968-InfoGathering
120.00 KB, application/msword
Details
SSL server certificate which chains to AC Camerfirma new roots
2.58 KB, application/x-x509-email-cert
Details
Intermediate CA's CRL
1015 bytes, application/pkix-crl
Details
Intermediate CA certificate
2.86 KB, application/x-x509-ca-cert
Details
Full Chambersign hierarchy from AC Camerfirma
7.71 KB, application/zip
Details
Updated Information Gathering Document
18.33 KB, application/pdf
Details
Intermediate CA for AC Camerfirma OCSP Responder
1.44 KB, application/octet-stream
Details
Completed Information Gathering Document
31.11 KB, application/pdf
Details
Translation of CPS section 3.1.8
9.20 KB, application/pdf
Details
EV Audit info Chambers of Commerce Root
2.04 MB, application/pdf
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 We are already included in the CA trusted list, and we whould like to incorporate a new root keys Could you please inform me about next steps ? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Assignee: nobody → hecker
Component: Security → CA Certificates
Product: Firefox → mozilla.org
QA Contact: firefox → ca-certificates
Summary: ADD new root certificate → ADD new root certificate for camerifirma
Version: unspecified → other
Severity: normal → enhancement
Please any information about this bug ? It is urgent for us to know it asap. from 2007 11 27 we have no get information. Thank you
Accepting this bug, and putting it into the queue with the other CA requests.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Ramiro, This request contains no information on which to make any decision. Please see the following page, http://wiki.mozilla.org/CA:Root_Certificate_Requests and then return to this bug page and submit the information requested.
Whiteboard: information incomplete
Reporter: ramirom@camerfirma.com Product: mozilla.org Version: Other Component: CA Certificates Severity: Enhancement Platform: ALL OS: ALL Summary: Add Chambers of Commerce ROOT, Chambersign Global ROOT Description: (see below) CA Details ---------- CA Name: [AC CAmewrfirma SA] Website URL: [http://www.camerfirma.com] CA Summary: [ Commercial CA issuing certificates for Companies and representatives] [ - Primary geographical area(s) served SPAIN ] [ - Sub CA : 5 ] Audit Type (WebTrust, ETSI etc.): [WEBTRUST ] Auditor: [Ernst & Young ] Auditor Website URL: [http://www.ey.es ] Audit Document URL(s): [http://www.camerfirma.com/mod_web/acreditaciones/auditorias.html] [http:// ] URL of certificate hierarchy diagram (if available): [http://www.camerfirma.com/mod_web/repositorio/otrascas.html ] Certificate Details ------------------- (To be completed once for each root certificate; note that we only include root certificates in the store, not intermediates.) Certificate Name: [Chambers of Commerce Root - 2008] Summary Paragraph: [This Ca issue certificate for Spanish Companies representatives ] [A copy of all end entities certificate policy can be obtained in] [http://www.camerfirma.com/mod_web/repositorio/otrascas.html ] [Chambers of Commerce are used as RAs for end users registration ] Root certificate download URL (on CA website): -----BEGIN CERTIFICATE----- MIIHSTCCBTGgAwIBAgIJAMnN0+nVfSPOMA0GCSqGSIb3DQEBBQUAMIGsMQswCQYD VQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3VycmVudCBhZGRyZXNzIGF0 IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAGA1UEBRMJQTgyNzQzMjg3 MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xJzAlBgNVBAMTHkdsb2JhbCBD aGFtYmVyc2lnbiBSb290IC0gMjAwODAeFw0wODA4MDExMjMxNDBaFw0zODA3MzEx MjMxNDBaMIGsMQswCQYDVQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3Vy cmVudCBhZGRyZXNzIGF0IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAG A1UEBRMJQTgyNzQzMjg3MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xJzAl BgNVBAMTHkdsb2JhbCBDaGFtYmVyc2lnbiBSb290IC0gMjAwODCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAMDfVtPkOpt2RbQT2//BthmLN0EYlVJH6xed KYiONWwGMi5HYvNJBL99RDaxccy9Wglz1dmFRP+RVyXfXjaOcNFccUMd2drvXNL7 G706tcuto8xEpw2uIRU/uXpbknXYpBI4iRmKt4DS4jJvVpyR1ogQC7N0ZJJ0YPP2 zxhPYLIj0Mc7zmFLmY/CDNBAspjcDahOo7kKrmCgrUVSY7pmvWjg+b4aqIG7HkF4 ddPB/gBVsIdU6CeQNR1MM62X/JcumIS/LMmjv9GYERTtY/jKmIhYF5ntRQOXfjyG HoiMvvKRhI9lNNgATH23MRdaKXoKGCQwoze1eqkBfSbW+Q6OWfH9GzO1KTsXO0G2 Id3UwD2ln58fQ1DJu7xsepeY7s2MH/ucUa6LcL0nn3HAa6x9kGbo1106DbDVwo3V yJ2dwW3Q0L9R5OP4wzg2rtandeavhENdk5IMagfeOx2YItaswTXbo6Al/3K1dh3e beksZixShNBFks4c5eUzHdwHU1SjqoI7mjcv3N2gZOnm3b2u/GSFHTynyQbehP9r 6GsaPMWis0L7iwk+XwhSx2LE1AVxv8Rk5Pihg+g+EpuoHtQ2TS9x9o0o9oOpE9Jh wZG7SMA0j0GMS0zbaRL/UJScIINZc+18ofLx/d33SdNDWKBWY8o9PeU1VlnpDsog zCtLkykPAgMBAAGjggFqMIIBZjASBgNVHRMBAf8ECDAGAQH/AgEMMB0GA1UdDgQW BBS5CcqcHtvTbDprru1U8VuTBjUuXjCB4QYDVR0jBIHZMIHWgBS5CcqcHtvTbDpr ru1U8VuTBjUuXqGBsqSBrzCBrDELMAkGA1UEBhMCRVUxQzBBBgNVBAcTOk1hZHJp ZCAoc2VlIGN1cnJlbnQgYWRkcmVzcyBhdCB3d3cuY2FtZXJmaXJtYS5jb20vYWRk cmVzcykxEjAQBgNVBAUTCUE4Mjc0MzI4NzEbMBkGA1UEChMSQUMgQ2FtZXJmaXJt YSBTLkEuMScwJQYDVQQDEx5HbG9iYWwgQ2hhbWJlcnNpZ24gUm9vdCAtIDIwMDiC CQDJzdPp1X0jzjAOBgNVHQ8BAf8EBAMCAQYwPQYDVR0gBDYwNDAyBgRVHSAAMCow KAYIKwYBBQUHAgEWHGh0dHA6Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20wDQYJKoZI hvcNAQEFBQADggIBAICIf3DekijZBZRG/5BXqfEv3xoNa/p8DhxJJHkn2EaqbylZ UohwEurdPfWbU1Rv4WCiqAm57OtZfMY18dwY6fFn5a+6ReAJ3spED8IXDneRRXoz X1+WLGiLwUePmJs9wOzL9dWCkoQ10b42OFZyMVtHLaoXpGNR6woBrX/sdZ7LoR/x fxKxueRkf2fWIyr0uDldmOghp+G9PUIadJpwr2hsUF1Jz//7Dl3mLEfXgTpZALVz a2Mg9jFFCDkO9HB+QHBaP9BrQql0PSgvAm11cpUJjUhjxsYjV5KTXjXBjfkK9yyd Yhz2rXzdpjEetrHHfoUm+qRqtdpjMNHvkzeyZi99Bffnt0uYlDXA2TopwZ2yUDMd SqlapskD7+3056huirRXhOukP9DuqqqHW2Pok+JrqNS4cnhrG+055F3Lm6qH1U9O AP7Zap88MQ8oAgF9mOinsKJknnn4SPIVqczmyETrP3iZ8ntxPjzxmKfFGBI/5rso M0LpRQp8bfKGeS/Fghl9CYl8slR2iK7ewfPM4W7bMdaTrpmg7yVqc5iJWzouE4ge v8CSlDQb4ye3ix5vQv/n6TebUB0tovkC7stYWDpxvGjjqsGvHCgfotwjZT+B6q6Z 09gwzxMNTxXJhLynSC34MCN32EZLeW32jO06f2ARePTpm67VVMB0gNELQp/B -----END CERTIFICATE----- Certificate SHA1 Fingerprint (in hexadecimal): [786a74ac76ab147f9c6a3050ba9ea87efe9ace3c] Key size (for RSA, modulus length) in bits: [ 4096 ] Valid From (YYYY-MM-DD): [ 2008-08-01 ] Valid To (YYYY-MM-DD): [ 2038-07-31 ] CRL HTTP URL (if any): [http:// ] CRL issuing frequency for subordinate CA certificates: [ 180 days ] CRL issuing frequency for subordinate EE certificates: [ 180 days ] OCSP responder URL (if any): [http://ocsp.camerfirma.com ] Class: [domain-validated, identity/organizationally-validated or EV] Certificate Policy URL: [http://policy.camerfirma.com ] CPS URL: [http://policy.camerfirma.com ] Requested Trust Indicators: [ email and/or SSL and/or code signing ] URL of a sample website using a certificate chained to this root (if applying for SSL): [https:// ------------------------------------------------------------------- Certificate Name: [Global Chambersign Root - 2008] Summary Paragraph: [This Ca issue certificate for general use in all over the world ] [A copy of all end entities certificate policy can be obtained in] [http://www.camerfirma.com/mod_web/repositorio/otrascas.html ] [All kind of RA are used by this CA for End User Registration ] Root certificate download URL (on CA website): -----BEGIN CERTIFICATE----- MIIHSTCCBTGgAwIBAgIJAMnN0+nVfSPOMA0GCSqGSIb3DQEBBQUAMIGsMQswCQYD VQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3VycmVudCBhZGRyZXNzIGF0 IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAGA1UEBRMJQTgyNzQzMjg3 MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xJzAlBgNVBAMTHkdsb2JhbCBD aGFtYmVyc2lnbiBSb290IC0gMjAwODAeFw0wODA4MDExMjMxNDBaFw0zODA3MzEx MjMxNDBaMIGsMQswCQYDVQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3Vy cmVudCBhZGRyZXNzIGF0IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAG A1UEBRMJQTgyNzQzMjg3MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xJzAl BgNVBAMTHkdsb2JhbCBDaGFtYmVyc2lnbiBSb290IC0gMjAwODCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAMDfVtPkOpt2RbQT2//BthmLN0EYlVJH6xed KYiONWwGMi5HYvNJBL99RDaxccy9Wglz1dmFRP+RVyXfXjaOcNFccUMd2drvXNL7 G706tcuto8xEpw2uIRU/uXpbknXYpBI4iRmKt4DS4jJvVpyR1ogQC7N0ZJJ0YPP2 zxhPYLIj0Mc7zmFLmY/CDNBAspjcDahOo7kKrmCgrUVSY7pmvWjg+b4aqIG7HkF4 ddPB/gBVsIdU6CeQNR1MM62X/JcumIS/LMmjv9GYERTtY/jKmIhYF5ntRQOXfjyG HoiMvvKRhI9lNNgATH23MRdaKXoKGCQwoze1eqkBfSbW+Q6OWfH9GzO1KTsXO0G2 Id3UwD2ln58fQ1DJu7xsepeY7s2MH/ucUa6LcL0nn3HAa6x9kGbo1106DbDVwo3V yJ2dwW3Q0L9R5OP4wzg2rtandeavhENdk5IMagfeOx2YItaswTXbo6Al/3K1dh3e beksZixShNBFks4c5eUzHdwHU1SjqoI7mjcv3N2gZOnm3b2u/GSFHTynyQbehP9r 6GsaPMWis0L7iwk+XwhSx2LE1AVxv8Rk5Pihg+g+EpuoHtQ2TS9x9o0o9oOpE9Jh wZG7SMA0j0GMS0zbaRL/UJScIINZc+18ofLx/d33SdNDWKBWY8o9PeU1VlnpDsog zCtLkykPAgMBAAGjggFqMIIBZjASBgNVHRMBAf8ECDAGAQH/AgEMMB0GA1UdDgQW BBS5CcqcHtvTbDprru1U8VuTBjUuXjCB4QYDVR0jBIHZMIHWgBS5CcqcHtvTbDpr ru1U8VuTBjUuXqGBsqSBrzCBrDELMAkGA1UEBhMCRVUxQzBBBgNVBAcTOk1hZHJp ZCAoc2VlIGN1cnJlbnQgYWRkcmVzcyBhdCB3d3cuY2FtZXJmaXJtYS5jb20vYWRk cmVzcykxEjAQBgNVBAUTCUE4Mjc0MzI4NzEbMBkGA1UEChMSQUMgQ2FtZXJmaXJt YSBTLkEuMScwJQYDVQQDEx5HbG9iYWwgQ2hhbWJlcnNpZ24gUm9vdCAtIDIwMDiC CQDJzdPp1X0jzjAOBgNVHQ8BAf8EBAMCAQYwPQYDVR0gBDYwNDAyBgRVHSAAMCow KAYIKwYBBQUHAgEWHGh0dHA6Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20wDQYJKoZI hvcNAQEFBQADggIBAICIf3DekijZBZRG/5BXqfEv3xoNa/p8DhxJJHkn2EaqbylZ UohwEurdPfWbU1Rv4WCiqAm57OtZfMY18dwY6fFn5a+6ReAJ3spED8IXDneRRXoz X1+WLGiLwUePmJs9wOzL9dWCkoQ10b42OFZyMVtHLaoXpGNR6woBrX/sdZ7LoR/x fxKxueRkf2fWIyr0uDldmOghp+G9PUIadJpwr2hsUF1Jz//7Dl3mLEfXgTpZALVz a2Mg9jFFCDkO9HB+QHBaP9BrQql0PSgvAm11cpUJjUhjxsYjV5KTXjXBjfkK9yyd Yhz2rXzdpjEetrHHfoUm+qRqtdpjMNHvkzeyZi99Bffnt0uYlDXA2TopwZ2yUDMd SqlapskD7+3056huirRXhOukP9DuqqqHW2Pok+JrqNS4cnhrG+055F3Lm6qH1U9O AP7Zap88MQ8oAgF9mOinsKJknnn4SPIVqczmyETrP3iZ8ntxPjzxmKfFGBI/5rso M0LpRQp8bfKGeS/Fghl9CYl8slR2iK7ewfPM4W7bMdaTrpmg7yVqc5iJWzouE4ge v8CSlDQb4ye3ix5vQv/n6TebUB0tovkC7stYWDpxvGjjqsGvHCgfotwjZT+B6q6Z 09gwzxMNTxXJhLynSC34MCN32EZLeW32jO06f2ARePTpm67VVMB0gNELQp/B -----END CERTIFICATE----- Certificate SHA1 Fingerprint (in hexadecimal): [4abdeeec950d359c89aec752a12c5b29f6d6aa0c] Key size (for RSA, modulus length) in bits: [ 4096 ] Valid From (YYYY-MM-DD): [ 2008-08-01 ] Valid To (YYYY-MM-DD): [ 2038-07-31 ] CRL HTTP URL (if any): [http:// ] CRL issuing frequency for subordinate CA certificates: [ 180 days ] CRL issuing frequency for subordinate EE certificates: [ 180 days ] OCSP responder URL (if any): [http://ocsp.camerfirma.com ] Class: [domain-validated, identity/organizationally-validated or EV] Certificate Policy URL: [http://policy.camerfirma.com ] CPS URL: [http://policy.camerfirma.com ] Requested Trust Indicators: [ email and/or SSL and/or code signing ] URL of a sample website using a certificate chained to this root (if applying for SSL): [https://
Accepting this bug so I can proceed with the information-gathering and verification phase.
Assignee: hecker → kathleen95014
It looks like the certificate provided for the "Chambers of Commerce Root - 2008" was copied incorrectly. Instead, the "Global Chambersign Root - 2008" root has been provided twice. Please provide the correct cert. It would be even better if you could provide a link on your company website for downloading each root. If not, then copying the root into bugzilla here is fine. Thanks, Kathleen
Thank you Kathleen for your comments, Here I send to you the correct certificate Chambers of Commerce Root - 2008 ( It is faster ), sorry for the mistake -----BEGIN CERTIFICATE----- MIIHTzCCBTegAwIBAgIJAKPaQn6ksa7aMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYD VQQGEwJFVTFDMEEGA1UEBxM6TWFkcmlkIChzZWUgY3VycmVudCBhZGRyZXNzIGF0 IHd3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTESMBAGA1UEBRMJQTgyNzQzMjg3 MRswGQYDVQQKExJBQyBDYW1lcmZpcm1hIFMuQS4xKTAnBgNVBAMTIENoYW1iZXJz IG9mIENvbW1lcmNlIFJvb3QgLSAyMDA4MB4XDTA4MDgwMTEyMjk1MFoXDTM4MDcz MTEyMjk1MFowga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpNYWRyaWQgKHNlZSBj dXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRIw EAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVyZmlybWEgUy5BLjEp MCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAtIDIwMDgwggIiMA0G CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCvAMtwNyuAWko6bHiUfaN/Gh/2NdW9 28sNRHI+JrKQUrpjOyhYb6WzbZSm891kDFX29ufyIiKAXuFixrYp4YFs8r/lfTJq VKAyGVn+H4vXPWCGhSRv4xGzdz4gljUha7MI2XAuZPeEklPWDrCQiorjh40G072Q DuKZoRuGDtqaCrsLYVAGUvGef3bsyw/QHg3PmTA9HMRFEFis1tPo1+XqxQEHd9ZR 5gN/ikilTWh1uem8nk4ZcfUyS5xtYBkL+8ydddy/Js2Pk3g5eXNeJQ7KXOt3EgfL ZEFHcpOrUMPrCXZkNNI5t3YRCQ12RcSprj1qr7V9ZS+UWBDsXHyvfuK2GNnQm05a Sd+pZgvMPMZ4fKecHePOjlO+Bd5gD2vlGts/4+EhySnB8esHnFIbAURRPHsl18Tl UlRdJQfKFiC4reRB7noI/plvg6aRArBsNlVq5331lubKgdaX8ZSD6e2wsWsSaR6s +12pxZjptFtYer49okQ6Y1nUCyXeG0+95QGezdIp1Z8XGQpvvwyQ0wlf2eOKNcx5 Wk0ZN5K3xMGtr/R5JJqyAQuxr1yW84Ay+1w9mPGgP0revq+ULtlVmhduYJ1jbLhj ya6BXBg14JC7vjxPNyK5fuvPnnchpj04gftI2jE9K+OJ9dC1vX7gUMQSibMjmhAx hduub+84Mxh2EQIDAQABo4IBbDCCAWgwEgYDVR0TAQH/BAgwBgEB/wIBDDAdBgNV HQ4EFgQU+SSsD7K1+HnA+mCIG8TZTQKeFxkwgeMGA1UdIwSB2zCB2IAU+SSsD7K1 +HnA+mCIG8TZTQKeFxmhgbSkgbEwga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpN YWRyaWQgKHNlZSBjdXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29t L2FkZHJlc3MpMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVy ZmlybWEgUy5BLjEpMCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAt IDIwMDiCCQCj2kJ+pLGu2jAOBgNVHQ8BAf8EBAMCAQYwPQYDVR0gBDYwNDAyBgRV HSAAMCowKAYIKwYBBQUHAgEWHGh0dHA6Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20w DQYJKoZIhvcNAQEFBQADggIBAJASryI1wqM58C7e6bXpeHxIvj99RZJe6dqxGfwW PJ+0W2aeaufDuV2I6A+tzyMP3iU6XsxPpcG1Lawk0lgH3qLPaYRgM+gQDROpI9CF 5Y57pp49chNyM/WqfcZjHwj0/gF/JM8rLFQJ3uIrbZLGOU8W6jx+ekbURWpGqOt1 glanq6B8aBMz9p0w8G8nOSQjKpD9kCk18pPfNKXG9/jvjA9iSnyu0/VU+I22mlaH FoI6M6taIgj3grrqLuBHmrS1RaMFO9ncLkVAO+rcf+g769HsJtg1pDDFOqxXnrN2 pSB7+R5KBWIBpih1YJeSDW4+TTdDDZIVnBgizVGZoCkaPF+KMjNbMMeJL0eYD6MD xvbxrN8y8NmBGuScvfaAFPDRLLmF9dijscilIeUcE5fuDr3fKanvNFNb0+RqE4QG tjICxFKuItLcsiFCGtpA8CnJ7AoMXOLQusxI0zcKzBIKinmwPQN/aUv0NCB9szTq jktk9T79syNnFQ0EuPAtwQlRPLJsFfClI9eDdOTlLsn+mCdCxqvGnrDQWzilm1De fhiYtUU79nm06PcaewaD+9CL2rvHvRirCG88gGtAPxkZumWK5r7VXNM21+9AUiRg OGcEMeyP84LG3rlV8zsxkVrctQgVrXYlCg17LofiDKYGvCYQbTed7N14jHyAxfDZ d0jQ -----END CERTIFICATE-----
Attached is the initial information gathering document which summarizes the information gathered and verified so far. Within the document the information that is still needed is highlighted in yellow. I will also summarize here. 1) Please see sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/ We need a publishable statement or letter from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for these roots, and that the CA does indeed follow these practices and meets the requirements of one of: ETSI TS 101 456 ETSI TS 102 042 WebTrust Principles and Criteria for Certification Authorities The WebTrust audit that is posted on http://www.camerfirma.com/mod_web/acreditaciones/auditorias.html is from 2003, which is too old. 2) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ please translate the relevant text from the latest CP or CPS into English that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates: a) for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf; b) for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; 3) Please provide text in English that describes the subordinate CAs for these roots. 4) Are there any subordinate CAs operated by third parties? 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) Please identify if all SSL certs issued from these roots are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber. Are there any SSL certs issued from these roots that are only DV? Eg the Organization attribute is not verified, only the domain name is verified? 6) Can you provide URLs for the CRLs to these roots? Is there a statement in the CPS (or other relevant document that subordinate CAs must agree to) that specifies the frequency of update for the CRLs for the end-entity certificates chaining up to this root? Would you please translate the relevant text into English? There is usually a statement in the CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 36 hours. 7) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Would you please comment as to whether any of these are relevant? If relevant, please provide further info. 8) For testing purposes, please provide URLs to websites whose certificates chain up to these roots. Note that these can be test sites. Thanks, Kathleen
Ok Kathleen, thak you, I will prepare the answers to your requirementes as soon as posible. Regards
Attached image auditor letter —
auditor letter about AC Camerfirma webtrust process
Thank you for the letter from the auditor. When was this audit performed? As part of our standard process, I will need to independently contact Ernst & Young to verify the audit and letter. Thanks, Kathleen
crl distribution point for roots certificates. crl.camerfirma.com/root_chambers_2008.crl crl.camerfirma.com/root_chambersign_2008.crl
This audit has been performed in October 2008. Sorry I didm´t realize that I whouldn´t answer your question. Please can you tell me when more or less this roots will be included in your trusted list ? Regards Ramiro (In reply to comment #13) > Thank you for the letter from the auditor. When was this audit performed? > > As part of our standard process, I will need to independently contact Ernst & > Young to verify the audit and letter. > > Thanks, > Kathleen
Thank you for the information. For each root, we will need either a test cert or (preferably) a website whose ssl cert chains up to the root. This will be used for testing purposes. Mozilla policy is that when the CA provides the audit report, I need to independently contact the auditing company to verify the authenticity of the audit report. I have found that my email address confuses the auditors, so would you please ask the auditor (Marc Martinez Marce) to look for and reply to my email? It will likely get forwarded to him by the E&Y Webmaster.
Ok, I will try to prepare soon a SSL certificate from each hierarchy. Please try to contact Marc again by email Marc.MartinezMarce@es.ey.com regards Ramiro
The auditor has responded to my inquiry and has verified the authenticity of the audit report provided by the CA.
Kathleen I have receive a complaint from our auditors about the audit report publication that I have send to you. This reports is not a real audit but a confirmation letter about the audit process for you personal knowlege. Please could you withdrow this document from public. I will send to you the final report in a few days. regards Ramiro (In reply to comment #19) > The auditor has responded to my inquiry and has verified the authenticity of > the audit report provided by the CA.
I have removed the link to the auditor's letter from the pending list in http://www.mozilla.org/projects/security/certs/pending/ Would you also like to remove it from the attachments to this bug?
I think it is enough, thank you very much Ramiro
This is a SSL certificate issued to a http server for test use.
Hi here enclised to this message can be found a SSL end user test certificate from our new roots "Chambers of Commerce ROOT 2008". In short time we will send another end user certificate from the other hierarchy "Chambersign GLobal ROOT 2008"
Attachment #368235 - Attachment description: AC Camerfirma new roots SSL certificate → SSL server certificate which chains to AC Camerfirma new roots
Attachment #368235 - Attachment mime type: application/octet-stream → application/x-x509-email-cert
Attachment #339338 - Attachment mime type: application/octet-stream → application/msword
Comment on attachment 368235 [details] SSL server certificate which chains to AC Camerfirma new roots The cert in this attachment is issued by Issuer: CN=Camerfirma Corporate Server - 2009, L=Madrid (see current address at https://www.camerfirma.com/address), serialNumber=A82743287, O=AC Camerfirma S.A., C=ES That issuer cert is not presently attached to this bug, and without it, one cannot establish that this cert was issued by either of the proposed new root certs.
Hi Ramiro, I get the same result as Nelson when I import the newly attached cert. It looks like we'll also need the cert for the SSL intermediate CA. Would you also please send us the new audit report? Thanks, Kathleen
Attached file Intermediate CA's CRL —
This is the intermediate CA certificate from "Chambers of Commerce ROOT 2208" that issue certificates in a multi-policy technique for SSL web sites and "electronic seal"
Hi Kathleen I will provide to you with the new audit report in a few days. I am still wainting to receiving the the final report from the auditors. Regards Ramiro
Comment on attachment 368295 [details] Intermediate CA's CRL This is a CRL for the intermediate CA, not the CA cert.
Attachment #368295 - Attachment description: Intermediate CA → Intermediate CA's CRL
Attachment #368295 - Attachment mime type: application/octet-stream → application/pkix-crl
This is the intermediate CA certificate from "Chambers of Commerce ROOT 2208" that issue certificates in a multi-policy technique for SSL web sites and "electronic seal"
Sorry it was a mistake.
Attachment #368496 - Attachment mime type: application/octet-stream → application/x-x509-ca-cert
Hi here enclosed I send an end user certificate from the Chambersign Global ROOT hierarchy and the complete certificate chain. Regards
Hi Kathleen it is only left from us providing the final audit report, isn´t it
Yes, this request is pending the audit report, then it can be added to the queue for public discussion.
Bug #485894 was created to request that these two roots, Chambers of Commerce Root – 2008 and Global Chambersign Root – 2008, be EV-enabled. I am closing that bug as a duplicate of this bug, and updating this bug to reflect that this request is also for EV-enablement. Taking into account this update, here is the information that is needed for this request: 1) OCSP max expiration time as per http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.” 2) Updated hierarchies including the EV intermediate CAs. 3) EV policy OID(s) as per http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 4) Example websites with EV certs chaining up to these roots. 5) CP/CPS with EV information. 6) Translations into English of the sections of CP/CPS and/or RA Operating Manual having to do with verification of identity/organization, domain name ownership, and email address ownership. 7) WebTrust CA and WebTrust EV audits
Summary: ADD new root certificate for camerifirma → ADD camerifirma EV root certificates
Whiteboard: information incomplete → EV, information incomplete
Hi Kathleen, here you are our webtrust certification. I think this completes the process. Now I will prepare out CPS and Policies to follow with the EV recognition process. https://cert.webtrust.org/ViewSeal?id=874 Regards Ramiro
Please Kathleen can you give me information in advance about what browser version will include our root certificates ? It is really important for us to know it Thank you
I have been waiting for response to my inquiries in Comment #36. Also, would you please provide a translation into English of the WebTrust CA audit? Did you have a WebTrust EV audit performed? If so, would you please provide the url to the audit report? I cannot predict what release these CAs will be included in. First we need to complete the Information Gathering and Verification phase, and then we need to complete the Public Discussion phase. These are described in https://wiki.mozilla.org/CA:How_to_apply
Hi Kathleen, thank you for your quick answer. We are at the moment running our EV audit, so I prefer if it is posible to include both CAs root as soon as possible even though this means a no EV flag, we are really in a hurry with this. Afterwards, can we activate them as EV or just include a new CA for EV certificatres ?. Best Regards Ramiro
Attaching the updated Information Gathering document to reflect that EV is no longer requested at this time. Please review this document for accuracy and completeness. Please provide the following information as soon as possible: 1) URLs to websites whose SSL certs chain up to these roots. (may be test sites) 2) Translations into English of the sections of CP/CPS and/or RA Operating Manual having to do with verification of identity/organization, domain name ownership, and email address ownership. Note that this request has been added to the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion The status column indicates where we are in the queue, which is the request whose status is “In First Discussion”. Most first discussions take one to two weeks. Since the discussions are dependent on volunteers reviewing and commenting on the requests, I try to limit the first discussions to one active discussion at a time. If your EV audit is completed before your public discussion begins, then we can include the EV enablement request at that time, as long as all of the information listed in Comment #36 has been provided.
Hi Kathleen here you are the two things you asked me for: website whose SSL cert chains up to this root. Need url to a website whose SSL cert chains up to this root. https://server1.camerfirma.com:8081/ https://server2.camerfirma.com:8082/ Translations into English of the sections of CP/CPS and/or RA Operating manual having to do with verification of identity/organization, domain name ownership, and email address ownership. From: CPS V3.1.2 3.1.8 Personal and Organization identity Authentication and his relationship. SSL Certificates Section: Certificate subscript identity existence is validated against the Internet Domains Data Bases. Afterwards the organization existence associates with this domain must be checked against the Companies Register Data Bases (Spanish Chambers of Commerce Data Base). Finally the RA operator will send the certificate to the administrative contact and technical contact included in the Internet domain data base. From the Operating Manual v1.0 Digital Certificate Generation Process. (section) From the RA application we get: URL to be certified, Organization Vat number identification, Digital certificate validity Applicant mail address. Before approve the request we must: Be assured of the organization existence, by means of one of these methods: a) Spanish Administration TAX Data Base. b) Chambers of Commerce Data Base. c) Spanish Companies Register Data Base. Be assured that the certificates is paid Be assured that the domain exists and is linked with the organization previously verified consulting the Internet Domain Data Bases. http://www.networksolutions.com http://www.gandi.net http://www.interdomain.com http://www.nic.es http://www.nominalia.com
Thank you for the information. > website whose SSL cert chains up to this root. Need url to a website whose SSL > cert chains up to this root. > https://server1.camerfirma.com:8081/ > https://server2.camerfirma.com:8082/ https://server1.camerfirma.com:8081/ The CRL Distribution Point of the SSL cert for https://server1.camerfirma.com:8081/ provides two urls: http://crl.camerfirma.com/camerfirma_cserver-2009.crl http://crl1.camerfirma.com/camerfirma_cserver-2009.crl The CRL Distribution Point of the SSL cert for https://server2.camerfirma.com:8082/ also provides two urls: http://crl.camerfirma.com/racer-2009.crl http://crl1.camerfirma.com/racer-2009.crl NextUpdate for all of these urls is 3 months. CPS version 3.1.1 section 4.5.9: Certification Authority will issue a new CRL immediately after a change in the CRL content and at least once a day in case of no change is produced. If the CRLs are issued at least once a day, should the NextUpdate be closer to a day? When I don’t enforce OCSP, both of the test sites work fine in Firefox. However, when I enforce OCSP in Firefox, I get the following error for both sites: Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert) Would you please try this, to see if you get the same error. If you do get the error, please see if you can resolve. One possibility is that the signing cert does not chain up to the root, which is one of the potentially problematic practices. > From: CPS V3.1.2 What is the url for V3.1.2 of the CPS? > From the Operating Manual v1.0 Is the Operating Manual a publicly available document? If so, please provide the URL. Is the Operating Manual included in the audit?
> website whose SSL cert chains up to this root. Need url to a website whose SSL > cert chains up to this root. > https://server1.camerfirma.com:8081/ > https://server2.camerfirma.com:8082/ https://server1.camerfirma.com:8081/ The CRL Distribution Point of the SSL cert for https://server1.camerfirma.com:8081/ provides two urls: http://crl.camerfirma.com/camerfirma_cserver-2009.crl http://crl1.camerfirma.com/camerfirma_cserver-2009.crl The CRL Distribution Point of the SSL cert for https://server2.camerfirma.com:8082/ also provides two urls: http://crl.camerfirma.com/racer-2009.crl http://crl1.camerfirma.com/racer-2009.crl NextUpdate for all of these urls is 3 months. CPS version 3.1.1 section 4.5.9: Certification Authority will issue a new CRL immediately after a change in the CRL content and at least once a day in case of no change is produced. If the CRLs are issued at least once a day, should the NextUpdate be closer to a day? Yes, at the moment these CAs are not issuing certificates so we keep a CRL for 3 month, when we begin to issue certificates we will issue a dayly CRL. When I don’t enforce OCSP, both of the test sites work fine in Firefox. However, when I enforce OCSP in Firefox, I get the following error for both sites: Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert) Would you please try this, to see if you get the same error. If you do get the error, please see if you can resolve. One possibility is that the signing cert does not chain up to the root, which is one of the potentially problematic practices. Yes, we will include this new CAs in our OCSP responder to avoid this problem. > From: CPS V3.1.2 What is the url for V3.1.2 of the CPS? it is no published yet, surelly we will publish the v3.1.4 instead. Anyway no changes have benn made in this point. > From the Operating Manual v1.0 Is the Operating Manual a publicly available document? If so, please provide the URL. No is an internal document. Is the Operating Manual included in the audit? Yes.
Thanks. >> when I enforce OCSP in Firefox, I get the following error for both sites: >> Invalid OCSP signing certificate in OCSP response. >> (Error code: sec_error_ocsp_invalid_signing_cert) > Yes, we will include this new CAs in our OCSP responder to avoid this problem. Please let me know when the change has happened.
Hi Kathleen this OCSP issue is taking us more time than expected. I hope this problen doesn´t delay our accreditation, does it ? best regards Ramiro
No. Everything else is complete, so you're still in the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion There are 12 requests ahead of yours, and each request takes at least one to two weeks. So it'll be a while before your request enters into public discussion.
Kathleen, are you saying that this CA can be admitted to the root CA list even while this OCSP problem remains outstanding?
Obviously not and it would be a waste of time. The CA should be put into the queue after having all outstanding issues verifiable solved.
OK Kathleen we will priorize this task to have this problem resolve as soon as posible. Thank you for your quick answer. Ramiro
> Kathleen, are you saying that this CA can be admitted to the root > CA list even while this OCSP problem remains outstanding? No, I'm saying that according to the queue for public discussion it will be at least 3 months before this request can get into public discussion. As long as the OCSP issue is fixed before then, it will not delay the discussion.
Hi Kathleen, We think the OCSP problem is already resolved. Please can you confirm this ?
I just tried it again, and it's still failing for me. For both of the test websites https://server1.camerfirma.com:8081/ https://server2.camerfirma.com:8082/ They work when I don't have OCSP enforced. However, if I go to Tools->Options->Validation and select the box for "When an OCSP server connection fails, treat the certificate as invalid" then reload the page for one of the test websites, I get the error Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert) Does it work for you?
We have included the new CA root certificates in our OCSP responder and this works fine when I select in Tools->Options->Validation "validate if a OCSP server is found" or "validate all certificates with ocsp.camerfirma.com"...but, yes, I can reproduce this error when I select "When an OCSP server connection fails, treat the certificate as invalid". Maybe because of the basic constrains extention in the certificate which is signing the OCSP response. It is mark as a end user certificate. Can you inform me about the certificate extention value are you expecting ?
This certificate is needed to validate the AC Camerfirma OCSP responses.
Kathleen please try to include the Intermediate CA in the certificate store. As happend in SSL conexion the OCSP responses have a intermediate CA. If this works we should include the ca intermediate certificate in the ocsp responses. regards Ramiro
I have found this remark in the Mozila wiki section. Does That means that we can not sign the ocsp responses with a certificate diferent from the Ca who has issued the certificate ??. Regards "OCSP Responses signed by a certificate under a different root: When an OCSP responder URL is included in end-entity certificates, Firefox 3 will by default attempt to check the certificate’s status via OCSP. If the OCSP signer certificate is not the certificate of the CAthat issued the certificate in question and is not issued by the CAthat issued the certificate in question the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE."
Kathleen can you try https://www.camerfirma.com this website is signed by the actual root keys and the ocsp response is signed as the Mozilla rules states. regards
Ramiro, please read RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2. These define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.
Kathleen Crystal clear. We are going to issue a new certificate to sign OCSP responses signed by the CA who issue the SSL certificate, I hope this solve the problem. Thank you
Kathleen can you try again https://www.camerfirma.com if this works, we will include this solution in the new keys OCSP responder. Regards
Yes, I can now go to https://www.camerfirma.com when I have OCSP enforced.
OK, Kathleen we will nown configure the ocsp responder for the new CAs in orther to check correctly the test URL. I will let you know it when it was ready. Thank you
Kathleen, there is any way to force an OCSP cache cleaning in firefox ??
> [is there] any way to force an OCSP cache cleaning in firefox ?? Restart the browser.
Hi Kathleen, we have made changes in the OCSP responder for https://server1.camerfirma.com:8081 ...etc Please can you check it? We get different responses; we think is because of the browser cache. We restart the browser but we found the same responses. There is another way to get assured that the cache is cleaned?
I am still getting OCSP errors when I try the test sites, even though I had cleared my cache and restarted Firefox. I even deleted all of the Camerfirma CAs and re-imported them. I found that the test websites are not set up to auto-discover their hierarchy, and I had to manually import the intermediate CAs. Can you also fix this? I think it's a webserver configuration. https://server1.camerfirma.com:8081/ For this website to load I had to manually import the “Camerfirma Corporate Server - 2009” intermediate CA. https://server2.camerfirma.com:8082/ For this website to load I had to manually import the “AC Camerfirma - 2009” intermediate CA and the “RACER - 2009” intermediate CA. For both sites when I enforce OCSP and reload the page I get the following error: Secure Connection Failed An error occurred during a connection to server2.camerfirma.com:8082. security library: invalid arguments. (Error code: sec_error_invalid_args)
Kathleen we have included the intermediate CA in our server. Please can you check the test URL again ? Thank you Rergards Ramiro
Both test websites work now, even when I enforce OCSP.
Whiteboard: EV, information incomplete → EV - Information Confirmed Complete
Ramiro, Camerfirma’s root inclusion request is almost to the top of the queue for public discussion. https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion From Comment #41: “We are at the moment running our EV audit…” If the EV audit has completed, please post a url to the audit statement (or attach it to this bug). This will allow us to include EV enablement in this same request. Also, do you happen to have a more recent WebTrust CA audit report? The one I have is from late 2008, so just over a year old. In Comment #45: “at the moment these CAs are not issuing certificates so we keep a CRL for 3 months, when we begin to issue certificates we will issue a daily CRL.” Is this still the case?
Hi Kathleen we have finished out EV audit, we are right now waiting the auditor statement. I have planned to send it to you next week. Yes, our current webtrust audit is from 2008. We are starting the renewal process. Yes, The CAs do not issue certificates at the moment, we are planning a controlled substitution from the actual CA during this year. Regards Ramiro
Hi Kathleen here you are the link to the auditor statement. Sorry, only available in spanish so far. http://docs.camerfirma.com/mod_web/usuarios/pdf/Informe_agrupado_Camerfirma_WebTrust_EV.pdf regards Ramiro
> Yes, our current webtrust audit is from 2008. We are starting the renewal process. OK > Yes, The CAs do not issue certificates at the moment, we are planning a controlled substitution from the actual CA during this year. OK > we have finished our EV audit Great! If you would like to included ev-enablement in this request, please provide the following: 1) The URL(s) to the Policy documentation for EV-enabled certificates. 2) Translation of the text from the corresponding CP/CPS that describes the organization and domain name validation procedures for EV-enabled certificates. 3) The EV Policy OID 4) A test website whose EV SSL certificate chains up to the root. (for each root) 5) Translation of the text from the corresponding CP/CPS relating to EV guidelines for CRLs: "CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days;" 6) Translation of the text from the corresponding CP/CPS relating to EV guidelines for OCSP: “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.” 7) Translation of the EV audit report into English (I can't seem to copy-paste the text from the audit report you provided, so I can't use Google-Translate.) 8) Is the EV audit report going to be posted on cert.webtrust.org? If not, I'll have to independently contact the auditor to confirm the authenticity of the audit report, so I'll need an email address to the appropriate person at Ernst & Young.
Hi Kathleen I going to answer some of your questions : Points 1),2),5),6),7) I will prepare it Point 3) We issue a comomn OID for Chambers of Commerce ROOT 2008 EV = 1.3.6.1.4.1.17326.10.14.2.*.* and for Chambersign GLobal ROOT 2008 EV= 1.3.6.1.4.1.17326.10.8.12.*.* In both hierarquies we use the last 2 digits for identify the Private Key management: 1.1 Private key generated stored in a software device and generated by the CA 1.2 Private key generated stored in a software device and generated by the User 2.1 Private key generated stored in a SSCD device and generated by the CA 2.2 Private key generated stored in a SSCD device and generated by the User Point 4) You can use the links I previosly sent to you https://server1.camerfirma.com:8081/ https://server2.camerfirma.com:8082/ Point 8) Ernst&Young contact Ángel Izquierdo Esteban Telf: +34 91 572 7273 | Fax: +34 91 572 7460 Mail: Angel.IzquierdoEsteban@es.ey.com Regards Ramiro
Thank you for the information. I will contact the auditor. For the EV Policy OIDs, is it ever the case that the ending two digits will be anything but 1.2 for EV SSL certificates?
the 1.2 is the most usual option, is it a EV requirement ? Sorry the Policy OID marked with EV is the end user certificate policy OID or the Root Certificate policy OID ?
For some reason I have the following in my InfoGathering Document in regards to the Potentially Problematic Practice about CAs generating key-pairs for subscribers: "AC Camerfirma only accept PKCS10 request for SSL certificates." So then it would seem that 1.1 and 2.1 would not be relevant for SSL certs.
Hi Kathleen you are right. the relevants ones are 1.2 and 2.2, the keys are generated by the user in a sofware environment or a SSCD environment. Regards
I have received email from the auditor confirming that Ernst & Young did indeed issue the auditor’s statement at the URL in Comment #73. The auditor also confirmed that this audit statement covers the “Chambers of Commerce Root - 2008” and “Global Chambersign Root – 2008” roots and their corresponding CA hierarchies.
Hi Ramiro, Do you have updates in regards to the following items from Comment #74? 1) The URL(s) to the Policy documentation for EV-enabled certificates. 2) Translation of the text from the corresponding CP/CPS that describes the organization and domain name validation procedures for EV-enabled certificates. 5) Translation of the text from the corresponding CP/CPS relating to EV guidelines for CRLs: "CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days;" 6) Translation of the text from the corresponding CP/CPS relating to EV guidelines for OCSP: “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.” Regards, Kathleen
Sorry for the delay Kathleen. I will send this info to you in a couple of days. Regards
Hi Kathleen Point 1 ----------------------------------- http://www.camerfirma.com/mod_web/usuarios/pdf/PC_Camerfirma_Corporate_Server_EV_1_0.pdf Point 2 ----------------------------------- 4.3 Cretificate issuing process. a) Before starting the issuing process, the AC should inform the subscriber of the terms and conditions for the use of the certificate. b) The AC should transmit this information through a perdurable communication channel, capable of being transmitted electronically and in a comprehensive language. c) The AC should check: • The existence of the organization, checking in public registries. • Checking the identity of the applicant or authorized person through supporting documents. The documentation will be handled personally in an AC Camerfirma registration office. Physical presence could be substituted for an online application signed with a valid and recognized certificate and for those other options approved by the current legislation. • That the organization has the control in the uses of the domain through consultation in the registries of domain. d) The applicant’s address and other contact details should be facilitated. e) The AC should comply with all the requirements imposed by the data protection legislation. Point 5 ------------------------------ 4.5.8 Emission frequency of CRL´S. The AC will provide the certificate revocation information through the CRL. The AC will publish and update the CRL at least once weekly and keeping it published for 10 days. Point 6 -------------------------------- 4.5.10 Availability of the online revocation status checking. The AC provides an online certificate status consultation service based in the OCSP protocol. This service will be updated at least every 4 days. The OCSP responses to this service should have a valid period of 10 days.
I am now opening the first public discussion period for this request from AC Camerfirma to add two root certificates: “Chambers of Commerce Root – 2008” and “Global Chambersign Root – 2008”. The request is to enable all three trust bits for both roots. The request is to also enable EV for both roots. 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 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 “Camerfirma Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of the CA should promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Information Confirmed Complete → EV - In Public Discussion
I have reviewed the information above and cannot see any concerns. I initially saw the 180 day CRL for end entity certificates as a problem, however this seems to have been addressed later in the application and considering the Firefox preference to use OCSP this should be fine. Kind Regards Steve Roylance (GlobalSign)
Steve, discussions are held at the mailing list, not in the bug. Would you mind adding your comments at the dev-security-policy@lists.mozilla.org list where the actually action (should) happen? :-)
The public discussion for this request is now closed. This request from Camerfirma is to add two root certificates (“Chambers of Commerce Root – 2008” and “Global Chambersign Root – 2008”) and enable all three trust bits for both roots. The request is to also enable EV for both roots. The discussion resulted in the following action items. ACTION Camerfirma: Update the CP/CPS documents to provide more specific information about how the domain registration services databases are used to verify that the certificate subscriber owns/controls the domain name to be included in the certificate. Post link to the updated CPS in this bug. ACTION Kathleen: After Camerfirma updates this bug with a link to the updated CPS, confirm that the clarifications were added as per the discussion. Then post recommendation for approval in this bug.
Whiteboard: EV - In Public Discussion → EV - Public Discussion Action Items - Update CPS
Hi Kathleen sorry for the delay. A new version of our CPS is published http://www.camerfirma.com/mod_web/usuarios/politicas/CPS_V_3_2_1.pdf Regards Ramiro
Attached is the translation of section 3.1.8 of the updated CPS. I have confirmed that the updates that were recommended during the discussion have been incorporated. This completes Camerfirma's action item as per comment #89. I will proceed with posting my recommendation to approve this request.
This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request from Camerfirma to add two root certificates: “Chambers of Commerce Root – 2008” and “Global Chambersign Root – 2008”. The request is to enable all three trust bits for both roots. The request is to also enable EV for both roots. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Camerfirma, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. Camerfirma appears to provide a service relevant to Mozilla users: they are a Regional CA in Spain, and the CA for Chambers of Commerce in Spain Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CPS and the CP for each type of certificate. The documents are in Spanish, and English translations of parts of the documents have been provided. Camerfirma Document Repository: http://policy.camerfirma.com/ CPS: http://www.camerfirma.com/mod_web/usuarios/politicas/CPS_V_3_2_1.pdf CP for Express Corporate Server: http://policy.camerfirma.com/politicas/PC_Camerfirma_Express_Corporate_Server_1_0_1.pdf CP for Corporate Server EV: http://www.camerfirma.com/mod_web/usuarios/pdf/PC_Camerfirma_Corporate_Server_EV_1_0.pdf CP for Code Signing: http://policy.camerfirma.com/politicas/PC_Camerfirma_CodeSign_1_0_1.pdf Section 7 [Validation]. Camerfirma appears to meet the minimum requirements for subscriber verification, as follows: * Email: Camerfirma’s process for requesting and issuing encryption certificates requires communication via the email address to be included in the certificate. For signing end user certificates physical presence is required, id card and an authorisation of a enterprise representative. All other communications are made by means of email. * Code: Camerfirma requires identification of the subscribing company and its representative as described in the CPS and in the CP for Code Signing. * SSL: Camerfirma verifies domain control by comparing the data in the certificate application with the data retrieved from a public database of Internet domains as listed in section 3.1.8 of the CPS. Email is also sent to the administrative and technical contacts of the domain to be included in the certificate, as found from querying a publicly available Internet domains database. * EV SSL: Camerfirma verifies the organization identity and the organization’s ownership/control of the domain name as per section 3.1.8 of the CPS and as per the CP for Corporate Server EV. * EV Policy OID: Camerfirma requests two EV Policy OIDS for each root. ** Chambers of Commerce Root – 2008 *** 1.3.6.1.4.1.17326.10.14.2.1.2 for non SSCD keys and *** 1.3.6.1.4.1.17326.10.14.2.2.2 for SSCD keys ** Global Chambersign Root – 2008 *** 1.3.6.1.4.1.17326.10.8.12.1.2 for non SSCD keys and *** 1.3.6.1.4.1.17326.10.8.12.2.2 for SSCD keys ** If testing determines that it is problematic to have two EV Policy OIDs for a root, then Camerfirma would choose to use the non SSCD keys OID. Section 8-10 [Audit]. Camerfirma is audited by Ernst & Young according to the WebTrust CA and WebTrust EV criteria. The WebTrust CA audit report from the end of 2008 is posted on the webtrust.org website (https://cert.webtrust.org/ViewSeal?id=874). The WebTrust EV audit that was completed in 2009 was provided by Camerfirma. I exchanged email with the auditor at Ernst & Young, and the auditor confirmed that the WebTrust EV audit statement is authentic and that it covers these two roots. Spanish: http://docs.camerfirma.com/mod_web/usuarios/pdf/Informe_agrupado_Camerfirma_WebTrust_EV.pdf English: http://docs.camerfirma.com/mod_web/usuarios/pdf/Informe_agrupado_Camerfirma_EV_English.pdf Section 13 [Certificate Hierarchy]. http://www.camerfirma.com/mod_web/repositorio/otrascas.html * The “Chambers of Commerce Root – 2008” root will have internally-operated subordinate CAs: Express Corporate Server for SSL certificates; Corporate Server EV; CodeSign; TSA for Time Stamping process that issues TSU certificates; and AC Camerfirma, Certificados Camerales which issues certificates for end entities (Enterprise certificates for employees and representatives). ** Chambers of Commerce act as RAs for end user registration. * The “Global Chambersign Root – 2008” root will have internally-operated subordinate CAs that issue certificates for general use globally. There is currently an intermediate CA called AC Camerfirma which signed a sub-CA called RACER. This 2nd level Intermediate CA issues certificates for citizens and enterprise employees and representatives. ** Other companies act as RAs for end user registration. Other: * CRL: ** Chambers of Commerce Root – 2008 ARL: http://crl.camerfirma.com/root_chambers_2008.crl ** End-entity CRL for server certs: http://crl.camerfirma.com/camerfirma_cserver-2009.crl ** Global Chambersign Root – 2008 ARL: http://crl.camerfirma.com/root_chambersign_2008.crl ** End-entity CRL for server certs: http://crl.camerfirma.com/racer-2009.crl ** NextUpdate for the end-entity CRLs for both roots is currently 3 months. “at the moment these CAs are not issuing certificates so we keep a CRL for 3 months, when we begin to issue certificates we will issue a daily CRL.” ** CP Server EV section 4.5.8: The CA will publish and update the CRL at least once weekly and keeping it published for 10 days. * OCSP: http://ocsp.camerfirma.com ** CP Server EV section 4.5.10 This service will be updated at least every 4 days. The OCSP responses to this service should have a valid period of 10 days. Based on this assessment I intend to approve this request from Camerfirma to add the “Chambers of Commerce Root – 2008” and “Global Chambersign Root – 2008” root certificates, enable all three trust bits for both roots, and enable EV for both roots.
Whiteboard: EV - Public Discussion Action Items - Update CPS → EV - Pending Approval
To the representatives of Camerfirma: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. As per the summary in Comment #92, and on behalf of the Mozilla project I approve this request from Camerfirma to include the following root certificates in Mozilla, with trust bits set as indicated, and to enable EV for both roots. * Chambers of Commerce Root - 2008 (web sites, email, code signing) * Global Chambersign Root - 2008 (web sites, email, code signing) I will file the NSS and PSM bugs to effect the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM
Depends on: 562395
Depends on: 562399
I have filed bug 562395 against NSS and bug 562399 against PSM for the actual changes.
Thank you so much for your work Kathleen. Best Regards Ramiro
Whiteboard: EV - Approved - awaiting NSS and PSM → EV - In FF4Beta - awaiting PSM
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: EV - In FF4Beta - awaiting PSM → EV - In FF4Beta
EV audit info
Product: mozilla.org → NSS
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: