Closed
Bug 295474
Opened 20 years ago
Closed 13 years ago
Add CATCert root CA certificate (Spain)
Categories
(CA Program :: CA Certificate Root Program, task, P3)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: fferre, Assigned: kwilson)
References
()
Details
(Whiteboard: Included in FF 11)
Attachments
(18 files, 5 obsolete files)
(deleted),
text/PDF
|
Details | |
(deleted),
application/gzip
|
Details | |
(deleted),
application/gzip
|
Details | |
(deleted),
application/gzip
|
Details | |
(deleted),
application/gzip
|
Details | |
(deleted),
application/gzip
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/zip
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/pdf
|
Details |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Build Identifier: We are the Catalan Agency of Certification (Agència Catalana de Certificació or CATCert). Our aim is to provide digital certification services and promote the usage of digital signature in order to make safer the communications within the Catalan government and the communications (within and for) the Catalan government. Reproducible: Always
Reporter | ||
Comment 1•20 years ago
|
||
The request letter with the explanation about how CATCert fulfills the requirements stablished on the Mozilla CA Certificate Policy.
Reporter | ||
Comment 2•20 years ago
|
||
Reporter | ||
Comment 3•20 years ago
|
||
Reporter | ||
Comment 4•20 years ago
|
||
Reporter | ||
Comment 5•20 years ago
|
||
Reporter | ||
Comment 6•20 years ago
|
||
Comment 7•18 years ago
|
||
I confirm that this is an enhancement request. :)
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Certificate Authority to file requests asking for their certificates to be included in the default certificate store. → Add CATCert root CA certificate
Reporter | ||
Comment 8•18 years ago
|
||
Dear Sir, do you have any schedule for the bug to get fixed, i.e., or CA certificates to be included on your products?. We haven't had activity related to this issue since 2005 as you can see on this webpage meanwhile other colleagues from other spanish CAs do have had activity and even resolved their cases. We would gladly like to hear from you soon.
Updated•18 years ago
|
QA Contact: ca-certificates
Comment 9•18 years ago
|
||
As you may know, the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html states: "We require that all CAs whose certificates are distributed with our software products provide some service relevant to typical users of our software products." Both bug 295474 and bug 342503 are on hold, pending the formulation of a policy on whether certificate authorities who deal with a constituency smaller than a country meet this requirement. Without limitation, possible resolutions include shipping the roots to everyone, shipping them only in a subset of builds, and deciding not to ship them at all. I will post in this bug again when we've decided what to do. Thank you for your patience. Gerv
Comment 10•18 years ago
|
||
Dear Gervase, I will find some time to read these documents as well. However, as the main Catalan localizer, who is also well aware of Mozilla products usage in his territory, the inclusion of this feature will be highly desirable and would also be useful to extend Mozilla products usage in local and regional administrations. Best regards,
Updated•18 years ago
|
Priority: -- → P3
Comment 11•18 years ago
|
||
Reassign all open CA bugs to me. Apologies for the bugspam. Gerv
Assignee: hecker → gerv
Comment 12•18 years ago
|
||
Maybe this is a new development, but since cacert, through the idcat initiative, is distributing certificates free of charge to any citizen that request them, and these certificates are accepted by various national agencies and can be used for encrypting and signing emails, I think this is a valuable service. On top of that they distribute the certificate with an usb memory stick in a specially encrypted partition and provide a pkcs11 module both for firefox and thunderbird (though it crashes thunderbird here, but that's another matter).
Comment 14•18 years ago
|
||
We have decided that applications from sub-country governmental organisations will be considered after all the others have been processed. Please could you provide data about your CA and certificates in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again. CA Details ---------- CA Name: Website: One Paragraph Summary of CA, including the following: - General nature (e.g., commercial, government, academic/research, nonprofit) - Primary geographical area(s) served - Number and type of subordinate CAs Audit Type (WebTrust, ETSI etc.): Auditor: Auditor Website: Audit Document URL(s): Certificate Details ------------------- (To be completed once for each certificate) Certificate Name: Summary Paragraph, including the following: - End entity certificate issuance policy, i.e. what you plan to do with the root Certificate HTTP URL (on CA website): Version: SHA1 Fingerprint: Modulus Length (a.k.a. "key length"): Valid From (YYYY-MM-DD): Valid To (YYYY-MM-DD): CRL HTTP URL: OCSP URL: Class (domain-validated, identity/organisationally-validated or EV): Certificate Policy URL: CPS URL: Requested Trust Indicators (email and/or SSL and/or code): URL of website using certificate chained to this root (if applying for SSL): Thanks for your help in this matter. :-) Gerv
Comment 15•17 years ago
|
||
Information has not been provided - resolving INCOMPLETE. Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
Reporter | ||
Comment 16•17 years ago
|
||
CA Details -------------- CA Name: EC-ACC Website: www.catcert.net One Paragraph Summary of CA, including the following: - General nature (e.g., commercial, government, academic/research, nonprofit) The Catalan Agency of Certification (Agència Catalana de Certificació - CATCert) is providing digital certification services and promoting the usage of digital signature in order to make safer the communications within and for the Catalan government. - Primary geographical area(s) served The Region of the Autonomic Community of Catalunya. - Number and type of subordinate CAs Seven subordinate CAs, six of them issuing end entity certificates. Audit Type (WebTrust, ETSI etc.): Web Trust CA, ETSI TS 101 456 Auditor: Ernst &Young Auditor Website: www.ey.com/es Audit Document URL(s): El document de la ETSI i el document de la WEB Trust WEB TRUST: https://cert.webtrust.org/SealFile?seal=466&file=pdf ETSI TS 101 456: http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101456v010101p.pdf (Policy requirements for certification authorities issuing qualified certificates) Certificate Details ------------------- Certificate Name: EC-GENCAT Summary Paragraph, including the following: EC-GENCAT is providing digital certification services and promoting the usage of digital signature in order to make safer the communications within and for the Regional Catalan government. Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/gencat.crt Version: V3 SHA1 Fingerprint: f0 b7 5b b7 93 11 b0 e5 d0 10 f1 ed 8d c7 e5 8f 15 be 68 fd Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2003-01-08 Valid To (YYYY-MM-DD): 2027-01-08 CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl http://epscd2.catcert.net/crl/ec-acc.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Organisationally validated Certificate Policy URL: EC-AL http://www.catcert.net/descarrega/doc_legal/EC-AL_pdc_general.pdf EC-IDCAT http://www.catcert.net/descarrega/doc_legal/idCAT_pedc.pdf EC-UR http://www.catcert.net/descarrega/doc_legal/EC-UR_pedc.pdf EC-SAFP http://www.catcert.net/descarrega/doc_legal/EC-SAFP_pdc_general.pdf CPS URL: https://www.catcert.net/verCIC-1 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://login.diba.cat Certificate Details ------------------- Certificate Name: EC-AL Summary Paragraph, including the following: EC-AL’s certificates are not issued to general public, but only to the civil servants and computers or devices of the Catalan government: this is city and town councils, regional councils, county councils, as well as autonomous agencies and public funded companies. Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/al_csrs.crt Version: V3 SHA1 Fingerprint: a4 1a 5e 9b d2 ff 6d 52 be 21 e5 eb 35 fe 56 07 77 12 47 0a Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2003-01-08 Valid To (YYYY-MM-DD): 2019-01-08 CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl http://epscd2.catcert.net/crl/ec-acc.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Organisationally validated Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-AL_dpc.pdf CPS URL: https://www.catcert.net/verCIC-2 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://login.diba.cat Certificate Details ------------------- Certificate Name: EC-SAFP Summary Paragraph, including the following: EC-SAFP’s certificates are not issued to general public, but only to the civil servants and computers or devices of agencies and departments of the Catalan Regional Government and public funded companies of the Catalan Regional Government (depending on the Secretaria d’Administració i Funció Pública). Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/safs_csrs.crt Version: V3 SHA1 Fingerprint: 09 55 ab 72 a8 3b 37 34 c3 89 07 e1 1f d2 95 66 42 71 56 e6 Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2003-01-08 Valid To (YYYY-MM-DD):2019-01-08 CRL HTTP URL: http://epscd.catcert.net/crl/ec-gencat.crl http://epscd2.catcert.net/crl/ec-gencat.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Organisationally validated Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-SAFP_dpc.pdf CPS URL: https://www.catcert.net/verCIC-2 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://www.e-ajrubi.net/ Certificate Details ------------------- Certificate Name: EC-PARLAMENT Summary Paragraph, including the following: EC-PARLAMENT’s certificates are not issued to general public, but only to the civil servants and computers or devices of the Catalan Parliament. Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/parlament_csrs.crt Version: V3 SHA1 Fingerprint: 82 70 f2 9f db 1f a3 1c 2a 85 46 11 a4 9d fa 6f c8 8d 06 90 Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2004-06-30 Valid To (YYYY-MM-DD): 2020-06-29 CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl http://epscd2.catcert.net/crl/ec-acc.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Organisationally validated Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-AL_pdc_general.pdf CPS URL: https://www.catcert.net/verCIC-2 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): NONE Certificate Details ------------------- Certificate Name: EC-UR Summary Paragraph, including the following: EC-UR’s certificates are not issued to general public, but to employees, students and computers or devices of Catalan universities and research centres connected to the “Anella Científica” group. Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/ur_csrs.crt Version: V3 SHA1 Fingerprint: d7 af fd f4 7f df f6 86 5d db f1 46 d8 86 4c 70 6c fa 00 32 Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2003-12-17 Valid To (YYYY-MM-DD): 2019-12-17 CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl http://epscd2.catcert.net/crl/ec-acc.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): organizationally validated Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-UR_dpc.pdf CPS URL: https://www.catcert.net/verCIC-2 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://www.catcampus.org/ Certificate Details ------------------- Certificate Name: EC-URV Summary Paragraph, including the following: EC-UR’s certificates are not issued to general public, but to employees, students and computers or devices of the Universitat Rovira i Virgili (URV). Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/urv_csrs.crt Version: V3 SHA1 Fingerprint: 01 55 fe c9 a2 21 7b b2 2a 0f 57 76 4b 30 e8 03 03 51 85 14 Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2005-05-03 Valid To (YYYY-MM-DD): 2013-05-03 CRL HTTP URL: http://epscd.catcert.net/crl/ec-ur.crl http://epscd2.catcert.net/crl/ec-ur.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Organisationally validated. Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-URV_dpc.pdf CPS URL: https://www.catcert.net/verCIC-3 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://actes.urv.cat Certificate Details ------------------- Certificate Name: EC-idCat Summary Paragraph, including the following: EC- idCAT’s certificates are issued to catalan citizens. Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/ec-idcat.cer Version: V3 SHA1 Fingerprint: 50 49 88 bd b7 df e0 dd a8 eb f6 98 e0 b5 c4 65 02 fb 41 fc Modulus Length (a.k.a. "key length"): RSA (2048 bits) Valid From (YYYY-MM-DD): 2003-1-31 Valid To (YYYY-MM-DD): 2019-10-31 CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl http://epscd2.catcert.net/crl/ec-acc.crl OCSP URL: http://ocsp.catcert.net Class (domain-validated, identity/organisationally-validated or EV): Identity validated Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/idCAT_dpc.pdf CPS URL: https://www.catcert.net/verCIC-2 Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. URL of website using certificate chained to this root (if applying for SSL): https://www.idcat.net/
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Updated•17 years ago
|
Summary: Add CATCert root CA certificate → Add CATCert root CA certificate (Spain)
Comment 17•17 years ago
|
||
This should not be assigned to me at the moment - reassigning to default owner. Gerv
Assignee: gerv → hecker
Status: REOPENED → NEW
Comment 19•16 years ago
|
||
Any advance on this? Is the information complete, isn't? Different Spanish certificate bugs seem to be stalled by no apparent reason for years.
Comment 20•16 years ago
|
||
It might be that the scope of this is CA is limited (and might be a regional government CA). Priority for those are low.
Comment 21•16 years ago
|
||
Eddy, the regional aspect was discussed a couple of years ago in a Mozilla newsgrop: http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/7ed60b1c316e9ae8/e5760202586c443c?hl=ca&lnk=gst&q=catcert#e5760202586c443c Microsoft is including these regional certificates, which are actually used by most citizens, administrations and universities of densely populated areas such as Barcelona for several years. Anyway, the Spanish FNMT, which is not so widely used in some areas, is not even approved yet. So please, any help would be appreciated so we can offer a product in equal conditions regarding this aspect. I think that more than two years is a significant dramatic amount of time. I'm at your disposal to anything that I could offer in order to help to unblock this situation.
Comment 22•16 years ago
|
||
I'm not aware of a change in policy concerning regional CAs. There are two issues of concern. The Mozilla CA Policy requirement and regionally limited CAs. I'm copying Kathleen to this bug in order for her to look at it and start eventual document gathering. However please take into account that this bug most likely will have a lower priority.
Comment 23•16 years ago
|
||
Eddy, thanks for adding Kathleen to this bug, so she can try to advance this. If there were any Mozilla policy document about this regional aspect, could you point it to me? As I commented in the linked newsgroup thread, we should take into account that some regional governments Catalonia (7,5 million potential people) can have a larger impact than some national ones. For instance, in case there were a certificate for Andorra (100.000 potential people). I understand that priorities must be drawn, but after such a long time, and direct browser competetion in such an advanced situation, I think we should not make it delay longer (all Spanish certificates). As I commented again, I'm at your disposal for anything and I can act as intermediary if needed. Thanks!
Assignee | ||
Updated•16 years ago
|
Assignee: hecker → kathleen95014
Assignee | ||
Comment 25•16 years ago
|
||
A discussion in mozilla.dev.security.policy called “Accepting root CA certificates for regional government CAs”, indicates that we can proceed with processing the Spain regional government CAs. I realize that some of the information has been gathered previously, but Mozilla procedures have changed and some of the existing information needs to be updated. As such, we will proceed with the Information Gathering and Verification Phase as described in https://wiki.mozilla.org/CA:How_to_apply. Attached is the Initial Information Gathering document which summarizes the information that has been gathered, with highlights in yellow where additional or updated information is needed. Please review the document for accuracy and completeness. I will also summarize below where further clarification or updates are needed. 1) CA Hierarchy a) Please verify the information in the document. Is this the full list of subordinate CA chaining up to this EC-ACC root? Which of these sub-CAs are operated internally, and which of these are operated by external third parties? b) Please list all of the subordinate CAs that are operated by external third parties. c) Has this root been involved in cross-signing with any other roots? 2) Please either provide pointers to the text/sections in the English CPS, or provide translations into English of the sections of the appropriate CP/CPS documents pertaining to: Verification of ownership/control of domain name Verification of ownership/control of email address Section 7 of http://www.mozilla.org/projects/security/certs/policy/ Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices 3) When I enforce OCSP in Firefox, I get errors trying to access https://actes.urv.cat and https://www.idcat.net/. Please investigate. 4) The WebTrust audit is from 2005. Do you have a more recent audit?
Reporter | ||
Comment 27•16 years ago
|
||
(In reply to comment #25) > Created an attachment (id=371567) [details] > Initial Information Gathering Document > > A discussion in mozilla.dev.security.policy called “Accepting root CA > certificates for regional government CAs”, indicates that we can proceed with > processing the Spain regional government CAs. > > I realize that some of the information has been gathered previously, but > Mozilla procedures have changed and some of the existing information needs to > be updated. As such, we will proceed with the Information Gathering and > Verification Phase as described in https://wiki.mozilla.org/CA:How_to_apply. > > Attached is the Initial Information Gathering document which summarizes the > information that has been gathered, with highlights in yellow where additional > or updated information is needed. Please review the document for accuracy and > completeness. I will also summarize below where further clarification or > updates are needed. > > 1) CA Hierarchy > a) Please verify the information in the document. Is this the full list of > subordinate CA chaining up to this EC-ACC root? Which of these sub-CAs are > operated internally, and which of these are operated by external third parties? This is the full list of Subordinate CA Chaining. Find attached Hierarchy Map. There are not Sub-CA's operated by third parties. Just the Registration Authorities. > b) Please list all of the subordinate CAs that are operated by external third > parties. There ar no CA's operated by external third parties. > c) Has this root been involved in cross-signing with any other roots? NO > > 2) Please either provide pointers to the text/sections in the English CPS, or > provide translations into English of the sections of the appropriate CP/CPS > documents pertaining to: > Verification of ownership/control of domain name > Verification of ownership/control of email address > Section 7 of http://www.mozilla.org/projects/security/certs/policy/ > Potentially Problematic Practices, > http://wiki.mozilla.org/CA:Problematic_Practices > All the information we receive in CATCert to issue certificates (including domains and e-mails of CDS) come in a document signed by a representative of the corresponding organisation, which has public faith (as in the case of council secretaries ), or has been entitled to such action. In this case, the legitimacy is signed by the mayor (highest authority within the body) or similar charges in the case of EC-SAPF. > 3) When I enforce OCSP in Firefox, I get errors trying to access > https://actes.urv.cat and https://www.idcat.net/. Please investigate. OCSP answers are signed by EC-ACC. In order to our tests, when the certificate to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), Firefox's implementations does not follow the hierarchy path, and so an error is given (SECERROR OCSP UNAUTHORIZED RESPONSE) > > 4) The WebTrust audit is from 2005. Do you have a more recent audit? No, but the requirements have not changed. A new security plan is being deployed, and as soon it is completed, a new audit will be done.
Assignee | ||
Comment 28•16 years ago
|
||
> All the information we receive in CATCert to issue certificates (including > domains and e-mails of CDS) come in a document signed by a representative of > the corresponding organisation, which has public faith (as in the case of > council secretaries ), or has been entitled to such action. In this case, the > legitimacy is signed by the mayor (highest authority within the body) or > similar charges in the case of EC-SAPF. I don’t understand how this meets section 7 of the Mozilla CA Policy. Please… a) Explain how the ownership/control of the domain name is verified. b) Explain how the ownership/control of the email address is verified. c) Review the list of Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones are relevant. Provide further information (including pointers to CP/CPS section numbers when relevant). >> 3) When I enforce OCSP in Firefox, I get errors trying to access >> https://actes.urv.cat and https://www.idcat.net/. Please investigate. > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), > Firefox's implementations does not follow the hierarchy path, and so an error > is given (SECERROR OCSP UNAUTHORIZED RESPONSE) I’m not an OCSP expert. Perhaps someone on this bug notification can provide some guidance? If not, we can proceed, and this should get resolved in the discussion phase. >> 4) The WebTrust audit is from 2005. Do you have a more recent audit? > No, but the requirements have not changed. A new security plan is being > deployed, and as soon it is completed, a new audit will be done. What is the frequency of your audits? When do you expect the new audit to be complete? Please make sure that the new audit is compliant with sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/.
Comment 29•16 years ago
|
||
(In reply to comment #27) > > 3) When I enforce OCSP in Firefox, I get errors trying to access > > https://actes.urv.cat and https://www.idcat.net/. Please investigate. > > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), > Firefox's implementations does not follow the hierarchy path, and so an error > is given (SECERROR OCSP UNAUTHORIZED RESPONSE) Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560. NSS strictly enforces the 3 rules at the bottom of page 10, and gives the error code you cited above when the response does not conform to those rules.
Reporter | ||
Comment 30•15 years ago
|
||
Reporter | ||
Comment 31•15 years ago
|
||
Reporter | ||
Comment 32•15 years ago
|
||
Reporter | ||
Comment 33•15 years ago
|
||
(In reply to comment #28) > > All the information we receive in CATCert to issue certificates (including > > domains and e-mails of CDS) come in a document signed by a representative of > > the corresponding organisation, which has public faith (as in the case of > > council secretaries ), or has been entitled to such action. In this case, the > > legitimacy is signed by the mayor (highest authority within the body) or > > similar charges in the case of EC-SAPF. > > I don’t understand how this meets section 7 of the Mozilla CA Policy. Please… > > a) Explain how the ownership/control of the domain name is verified. Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of the domain name is verified. "The responsible of the service must verify the URL of the server and the data using the WHOIS service (www.whois.net). With this procedure, it is verified that the server exists." > > b) Explain how the ownership/control of the email address is verified. > It is not a requirement of the spanish Law, to include the e-mail field on the certificate, that's why an specific procedure for the verification of the e-mail is not defined at the procedure. Anyway, as explained in item 1.3.2.6of the operative procedure, the information related to the identity of the user is supplied by a previously authirozed third part. > c) Review the list of Potentially Problematic Practices, > http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones > are relevant. Provide further information (including pointers to CP/CPS > section numbers when relevant). > CATCert does not operate with any of the potentially problematic practices. > >> 3) When I enforce OCSP in Firefox, I get errors trying to access > >> https://actes.urv.cat and https://www.idcat.net/. Please investigate. > > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate > > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), > > Firefox's implementations does not follow the hierarchy path, and so an error > > is given (SECERROR OCSP UNAUTHORIZED RESPONSE) > > I’m not an OCSP expert. Perhaps someone on this bug notification can provide > some guidance? If not, we can proceed, and this should get resolved in the > discussion phase. > > >> 4) The WebTrust audit is from 2005. Do you have a more recent audit? > > No, but the requirements have not changed. A new security plan is being > > deployed, and as soon it is completed, a new audit will be done. > > What is the frequency of your audits? > When do you expect the new audit to be complete? > Please make sure that the new audit is compliant with sections 8, 9, and 10 of > http://www.mozilla.org/projects/security/certs/policy/.
Reporter | ||
Comment 34•15 years ago
|
||
(In reply to comment #28) > > All the information we receive in CATCert to issue certificates (including > > domains and e-mails of CDS) come in a document signed by a representative of > > the corresponding organisation, which has public faith (as in the case of > > council secretaries ), or has been entitled to such action. In this case, the > > legitimacy is signed by the mayor (highest authority within the body) or > > similar charges in the case of EC-SAPF. > > I don’t understand how this meets section 7 of the Mozilla CA Policy. Please… > > a) Explain how the ownership/control of the domain name is verified. > > b) Explain how the ownership/control of the email address is verified. > > c) Review the list of Potentially Problematic Practices, > http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones > are relevant. Provide further information (including pointers to CP/CPS > section numbers when relevant). > > >> 3) When I enforce OCSP in Firefox, I get errors trying to access > >> https://actes.urv.cat and https://www.idcat.net/. Please investigate. > > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate > > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), > > Firefox's implementations does not follow the hierarchy path, and so an error > > is given (SECERROR OCSP UNAUTHORIZED RESPONSE) > > I’m not an OCSP expert. Perhaps someone on this bug notification can provide > some guidance? If not, we can proceed, and this should get resolved in the > discussion phase. > > >> 4) The WebTrust audit is from 2005. Do you have a more recent audit? > > No, but the requirements have not changed. A new security plan is being > > deployed, and as soon it is completed, a new audit will be done. > > What is the frequency of your audits? > When do you expect the new audit to be complete? > Please make sure that the new audit is compliant with sections 8, 9, and 10 of > http://www.mozilla.org/projects/security/certs/policy/. Find attached the last audits which were made this year, for idCAT and T-CAT products.
Reporter | ||
Comment 35•15 years ago
|
||
(In reply to comment #29) > (In reply to comment #27) > > > 3) When I enforce OCSP in Firefox, I get errors trying to access > > > https://actes.urv.cat and https://www.idcat.net/. Please investigate. > > > > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate > > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), > > Firefox's implementations does not follow the hierarchy path, and so an error > > is given (SECERROR OCSP UNAUTHORIZED RESPONSE) > > Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560. > NSS strictly enforces the 3 rules at the bottom of page 10, and gives the error > code you cited above when the response does not conform to those rules. We use delegation, so we accomplish the following: OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate Regarding the three possible rules: 1. Matches a local configuration of OCSP signing authority for the certificate in question; or 2. Is the certificate of the CA that issued the certificate in question; or 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question." We don't accomplish number 2. But we do accomplish "1" and "3" so that should be enough.
Comment 36•15 years ago
|
||
In comment #33, it is stated that: "Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of the domain name is verified. 'The responsible of the service must verify the URL of the server and the data using the WHOIS service (www.whois.net). With this procedure, it is verified that the server exists.' This merely verifies the existence of the domain name. It does not verify that the person, company, or organization requesting a site certificate actually owns and controls that domain and is authorized to request a certificate for the domain.
Reporter | ||
Comment 37•15 years ago
|
||
Item 1.3.2.1. explains how the application forms and the corresponding documentation es received and registered. Item 1.3.2.2. explains how the service responsible verifies that the application form has been handwritten signed by the applicant. If not, the application is denied. Item 1.3.2.3. Explains that is verified that all the documentation has been supplied, and that it is correct Items 1.3.2.4 and 1.3.2.5, explain that it si verified the identity of the applicant and organization specified at the application form - If the documentation is sent by e-mail, it must be digitally signed by the authorized applicant. - If it is sent by traditional mail, the signature of the applicant will be handwritten. - For some kind of certificates, images as company-logo in example are required. Item 1.3.2.6 explains that the identity of the Key holder is verified indirectly by the applicant.
Assignee | ||
Comment 38•15 years ago
|
||
In regards to Comment #35 > We use delegation, so we accomplish the following: > OCSP signing delegation SHALL be designated by the inclusion of > id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the > OCSP response signer's certificate > Regarding the three possible rules: > 1. Matches a local configuration of OCSP signing authority for > the certificate in question; or > 2. Is the certificate of the CA that issued the certificate in question; or > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension > and is issued by the CA that issued the certificate in question. > We don't accomplish number 2. But we do accomplish "1" and "3" so that > should be enough. I believe that before including the root in NSS, the websites with SSL certs chaining to this root must work, even when OCSP is enforced. According to Comment #29, NSS strictly enforces all 3 of the rules, and gives the error when the response does not conform to those rules. Is this something CATCert can resolve? > idCAT Audit: https://bugzilla.mozilla.org/attachment.cgi?id=387879 > T-CAT Audit: https://bugzilla.mozilla.org/attachment.cgi?id=387880 It’s not clear to me which of the following audit criteria were used, as per section 8 of http://www.mozilla.org/projects/security/certs/policy/ ETSI TS 101 456 ETSI TS 102 042 WebTrust Principles and Criteria for Certification Authorities It’s also not clear to me what the tables are saying (being in a language other than English doesn’t help). It would be better to have a statement from an auditor that states what the criteria were (as per one or more of the above list), which roots and sub-CAs were audited, which documents were included in the audit, when the audit was performed, what issues were noted, and if all of the criteria were reasonably met. Note that the audit statement needs to be from an auditor that meets sections 9 and 10 of http://www.mozilla.org/projects/security/certs/policy/. > Item 1.3.2.7 of the Operative Procedure I have used Google Translate on all of section 1.3 of the Operative Procedure, and I did not find anything about how the output of WHOIS is used or compared to the data of the applicant in order to verify that the applicant owns/controls that domain. > It is not a requirement of the spanish Law, to include the e-mail field on > the certificate, that's why an specific procedure for the verification of > the e-mail is not defined at the procedure. Anyway, as explained in item > 1.3.2.6 of the operative procedure, the information related to the identity > of the user is supplied by a previously authirozed third part. Section 7 of the Mozilla CA Policy (http://www.mozilla.org/projects/security/certs/policy/) is about verifying that the applicant owns/controls the email address referenced in the certificate. Verification of the identity of the applicant does not completely satisfy this requirement. If CATCert does not have an audited procedure for verifying the ownership of the email address, then I recommend that you not request to enable the Email trust bit. Based on the information I have been able to review for this request, I think that only the Websites trust bit should be requested. I don’t think that there are documented/audited procedures that meet the requirements for enabling the Email and Code Signing trust bits. Is CATCert OK with proceeding with only requesting the Websites trust bit?
Comment 39•15 years ago
|
||
(In reply to comment #38) > I believe that before including the root in NSS, the websites with SSL certs > chaining to this root must work, even when OCSP is enforced. I fully and absolutely agree.
Assignee | ||
Updated•15 years ago
|
Whiteboard: information incomplete
Assignee | ||
Comment 40•15 years ago
|
||
There has been no activity in this bug for almost 8 months. Is this request obsolete?
Assignee | ||
Comment 41•15 years ago
|
||
Closing bug due to no recent response from CA.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → INCOMPLETE
Reporter | ||
Comment 42•14 years ago
|
||
Hi Kathleen, sorry for the delay giving feedback. We have been working hard in order to accomplish your requirements. Currently, the situation is the following: - Regarding to the first pending point, we recently passed a Webtrust audit. See the certificate on the following link: https://cert.webtrust.org/ViewSeal?id=1063 - About the second pending point, we will have a technical solution for the OCSP matter on september. The purpose of this entry is to let you know that we are working on it, and once solved the complications, would like to reopen the bug. For CATCert it is very important to get our certificates included in your distribution, and for that purpose, have our Director's support. Is it possible to reopen the bug?
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Assignee | ||
Comment 43•14 years ago
|
||
Yes, we can continue with this request. Attached is an updated Information Gathering Document which reflects our current process, as described here: https://wiki.mozilla.org/CA:How_to_apply Please review this document for accuracy and completeness, update the information that has changed, and provide further information or clarification as indicated by the items highlighted in yellow.
Assignee | ||
Comment 45•14 years ago
|
||
Thanks for translating the audit into English. Please see the attached "Updated Information Gathering Document" for the other information/clarifications that are still needed.
Reporter | ||
Comment 46•14 years ago
|
||
Hi Kathleen, we have reviewed the documentation you mentioned, and we have taken some decisions: 1.- We only request for the Websites trust bit. 2.- Our CPS (in catalan) can be found online at http://www.catcert.cat/registre Our CPS (in spanish) can be found online at http://www.catcert.cat/web/cas/5_0_regulacio.jsp (we are defining the alias). 3.- Some time ago we explained how the domain checking was done and documented in our internal procedure. We add the same explanation, but this time we add the translation of the procedure referred part. If you agree that this procedure complies with your requirements we will refer it from the CPS (or we will add this part of the procedure to our CPS if this is necessary). Summarizing next steps: 1.- Only authorized personal from Catalan Administration can request a certificate (Domain Server Certificate). 2.- (Items 1.3.2.1 – 1.3.2.5) It’s checked the applicant is an authorized person. 3.- (Item 1.3.2.7) It is checked using www.whois.net the existence of the server and the ownership. Regarding the step 3, in your recommended practices it’s mentioned it can be correlated the whois information with other sources. At this moment we only use one source because only authorized people can be applicants, but it’s not a problem for us to add another source if this is not enough for you. We add some glossary in order to make the understanding of the described processes easier: Subscriber: It is the person in charge of the public entity (subscriber entity) authorized to apply for certificates (for us, they are our clients, all of them are people who holds a public office). Subscriber Card: This is the form to be filled in by the Subscriber. In this form it is requested all the information in order to know who can apply for certificates. Application Form: This is the form to be filled in order to apply for certificates. Item 1.3.2.1. explains how the application forms and the corresponding documentation is received and registered. 1.3.2.1 Reception and registry of the documentation. Once the documentation referring to a request arrives to the Registration Entity, it is registered as entrance for the person entrusted of the registry. Afterwards, this documentation is delivered to the person in charge of the service, and this person continues with the formality. Item 1.3.2.2. explains how the person in charge of the Registration Entity verifies that the application form has been handwritten signed by the applicant. If not, the application is denied. 1.3.2.2 Checking the existence of subscriber card. The person in charge has to verify that the Subscriber has signed the subscriber card. In case the Subscriber has not signed it, the person in charge of the Registration Entity will send an electronic mail (digitally signed and with acknowledgment of receipt) to the person in charge of the subscriber entity briefing him of it is required having previously signed the subscriber card in order to go on. Until the subscriber card is not formalized the process of request will remain stopped (in "pending" state) and the action carried out will be registered by the person in charge of the Registration Entity. Item 1.3.2.3. Explains that it is verified that all the documentation has been supplied, and that it is correct 1.3.2.3 Checking the documentation and notification to the subscriber The person in charge of the Registration Entity will have to verify that the person in charge of the subscriber entity gives all the documentation required and in a proper format. In case any document was missing or any error was detected, it would be communicated to the person in charge of the subscriber entity by signed electronic mail and with acknowledgment of receipt. The reasons why the process and the actions have been halted will be indicated, and the action carried out will be registered. The process of Request will remain stopped (request in "pending" state) until all the documentation required is received. In case the request is accepted, the person in charge of the Registration Entity will notify to the person in charge of the subscriber entity by signed electronic mail that the request is being processed. Items 1.3.2.4 and 1.3.2.5, explain that it is verified the identity of the applicant and organization are the specified ones at the application form 1.3.2.4 Validation of the identity and authority of the applicant The person in charge of the Registration Entity has to check out that who makes the request for obtaining a digital certificate is authorized, it means that he/she is who was specified in the subscriber card. The valid methods for receiving the information required of a request for obtaining a certificate are detailed next: 1) By electronic mail: The person in charge of the subscriber entity sends an electronic mail to the person in charge of the Registration Entity digitally signed, and he/she attaches the electronic documents, also digitally signed, by the people indicated in the subscriber card. It means, the person in charge of the Registration Entity has to check out that the applicant indicated in the card has signed the request. In case that the Registration Entity does not have telematic registry, the documentation will be printed after being verified the signature and will be sealed with the indication “It is exact copy of an electronic document, which I have verified that the electronic signature is correct". Also it will be necessary that the person in charge of the Registration Entity signs at the foot of the seal. 2) By postal mail: The person in charge of the subscriber entity makes to arrive at the person in charge of the Registration Entity the documentation in paper signed by the people indicated in the subscriber card. In case the authentication and authorization of the applicant is not correct, the person in charge of the Registration Entity will reject the request and will send a signed electronic mail to the person in charge of the entity subscriber. Otherwise, the process continues. 1.3.2.5 Validation of the identity and authority of the certifier The person in charge has to check out that who delivers the documental justification really is authorized, it means this person is the Certifier that it was specified in the subscriber card. The valid methods for receiving the information required of a request for obtaining a certificate are detailed next: 1) The person in charge of the subscriber entity sends an electronic mail to the person in charge of the Registration Entity signed digitally, and the electronic documents are attached, also digitally signed by the people indicated in the subscriber card. It means, the person in charge of the Registration Entity has to check out that the certifier indicated in the card is who has signed the certificate. In case that the Registration Entity does not have telematic registry, the documentation will be printed after being verified the signature and will be sealed with the indication “It is exact copy of an electronic document, which I have verified that the electronic signature is correct". Also it will be necessary that the person in charge of the Registration Entity signs at the foot of the seal. 2) By postal mail: The person in charge of the subscriber entity makes to arrive at the person in charge of the Registration Entity the documentation in paper signed by the people indicated in the subscriber card. In case the authentication and authorization of the applicant is not correct, the person in charge of the Registration Entity will reject the request and will send a signed electronic mail to the person in charge of the entity subscriber. Otherwise, the process continues. Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of the domain name is verified. 1.3.2.7 Checking of the certificate data (Domain Server Certificates) In case of Domain Server Certificates requests, the person in charge of the Registration Entity will verify the existence and ownership of the server URL and the registration data using the WHO IS (www.whois.net). This way he/she verifies the existence of the server. The result will be converted to pdf format and it will be signed digitally by de person in charge of the Registration Entity. A digital copy will be stored and another will be printed and attached to the request, stored into the Registration Entity archive. This procedure can be find in catalan on: http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip
Assignee | ||
Comment 47•14 years ago
|
||
Thanks for the information and translations. Please see the newly attached "Updated Information Gathering Document". The items highlighted in yellow indicate where further information or clarification is still needed.
Attachment #458011 -
Attachment is obsolete: true
Reporter | ||
Comment 48•14 years ago
|
||
1. OCSP Responder URL: We are working on it. In our development environment it works properly, so we will migrate the production environment soon. We will let you know when the OCSP works properly. 2. CP/CPS: When we created the CPS it was translated to English, but we have not updated the English version since then. It means this document is obsolete. The same document in Spanish can be downloaded from: http://www.catcert.cat/web/cas/5_0_regulacio.jsp --> http://www.catcert.cat/web/cas/5_1_politica_general.jsp --> http://www.catcert.cat/descarrega_cas/oficina_politicas/D1111_N-PGDC_v3r3_cast.pdf We have defined 2 alias (Catalan: www.catcert.cat/registre and Spanish: www.catcert.cat/registro) in order to access to the last release of the regulations (you have called it “Document Repository”). If you need the translation to English of some parts I can do it. 3. Domain Name. Ownership / Control Comment #36: Comment #38: CATCert only generates website certificates for Catalan Public Administrations. As mentioned before (1.3.2.1-1.3.2.7 of the Operative Procedure document) only authorized people can apply for certificates, and it is checked. Registration Entity contacts the owner listed in the whois (http://www.whois.net/ and http://www.internic.net/whois.html for domains .cat) to verify that the applicant has the right to use the domain or subdomain. In order to verify it, the person in charge of the Registration Entity extracts the admin data and sends an e-mail asking if the applicant owns/controls the subdomain. Once the confirmation is received, the certificate is generated. 4. Potentially Problematic Practices. 4.1. RAs are external to CATCert but they belong to the Catalan Public Administration. It means they have in common the application of the controls specified at the Spanish Law 30/92 about procedures of the Public Administration. These RAs sign a contract with CATCert, and their way of working is periodically audited using the clauses of the contract. 4.2. Certificates referencing hostnames or private IP addresses: NO. 4.3. Issuing SSL Certificates for Internal Domains: NO
Assignee | ||
Comment 49•14 years ago
|
||
>> 1. OCSP Responder URL: >> We are working on it. In our development environment it works properly, so we >> will migrate the production environment soon. We will let you know when the >> OCSP works properly. OK. Please post a comment in this bug when ready. >> 2. CP/CPS: Thank you for the clarification about the documents. Please provide translations into English of Section 3.2.2 and 3.2.3 of Política General de Certificación Agència Catalana de Certificació. (http://www.catcert.cat/web/cas/5_1_politica_general.jsp) >> 4.1. RAs are external to CATCert but they belong to the Catalan Public >> Administration. It means they have in common the application of the controls >> specified at the Spanish Law 30/92 about procedures of the Public >> Administration. These RAs sign a contract with CATCert, and their way of >> working is periodically audited using the clauses of the contract. Is this documented in the CP/CPS? If yes, please provide corresponding url, page/section numbers, and translations.
Reporter | ||
Comment 50•14 years ago
|
||
Reporter | ||
Comment 51•14 years ago
|
||
Assignee | ||
Comment 52•14 years ago
|
||
Thank you for the translations. Please post an update in this bug when the OCSP issues have been resolved, as per Comment #48.
Attachment #475580 -
Attachment is obsolete: true
Reporter | ||
Comment 53•14 years ago
|
||
Finally our OCSP service is working properly. We have tested firefox in the next URLs: SAFP https://contractaciopublica.gencat.cat/ecofin_pscp/AppJava/notice.pscp?reqCode=searchCn&idCap=203732 AL https://seu.badalona.cat/portalWeb/badalona.portal?_nfpb=true&_pageLabel=seu_electronica UR https://seuelectronica.upc.edu/ URV https://portal.urv.cat/portal/dt Until now we have never generated Server Certificates for: Parlament and Gencat It means these ones can not be tested using Firefox if I’m right.
Comment 54•14 years ago
|
||
Sorry for the whining but, can we move this quickly, Francesc & Kathleen? After so long, Catalan community of Firefox users would be highly benefited by this, and we would love to have this available, at latest, by the time new Firefox 4 would be released. Thanks!
Comment 55•14 years ago
|
||
To all those who are impatient for this certificate to be approved and implemented for Gecko-based products: The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing. For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time. The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process. This request was closed TWICE because the certificate authority failed to provide necessary information in a timely manner. See comment #15 and comment #41. Thus, the problem lies in the hands of CATCert and not Mozilla. Further expressions of the need for haste will not speed the process. Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database. Those who are anxious for this root certificate -- those who already trust it and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificate themselves. The link is at <http://www.mozilla.org/projects/security/certs/pending/#CATCert>. When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button. On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there. Note well: These are my personal comments. I do not work for either the Mozilla Foundation or the Mozilla Corporation. Thus, these comments do not reflect the position of either organization.
Comment 56•14 years ago
|
||
(In reply to comment #55) Thanks for the informative comments, Dave. I'm well aware of the delay of response from CatCert and their responsibility. According to comment 53, all necessary information seems to be already finished, http://www.mozilla.org/projects/security/certs/pending/#CATCert —changing the color from red to green—. If not, I would appreciate a comment about. Note: I don't work for neither Mozilla nor CatCert. I'm a 6 years member of Mozilla Catalan community interested in helping Mozilla to progress in my society.
Assignee | ||
Comment 57•14 years ago
|
||
I am able to browse to the websites listed in Comment #53. I have OCSP enforced, and I confirmed that the SSL cert for each site has http://ocsp.catcert.net as the OCSP URI in the AIA.
Assignee | ||
Comment 58•14 years ago
|
||
Assignee | ||
Comment 59•14 years ago
|
||
This request is already in the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion The goal is to have each discussion take about two weeks. However, that time varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may be in the discussion for several weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer. How can you help reduce the time that your request sits in the queue? You can help by reviewing and providing your feedback in the public discussions of root inclusion requests, or by asking a knowledgeable colleague to do so. Participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request. Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: information incomplete → Information confirmed complete
Comment 60•14 years ago
|
||
Thanks Kathleen for your work. From now on, I would encourage interested parts to join ongoing discussions in the mailing list (as described in the links above) https://lists.mozilla.org/listinfo/dev-security-policy
Reporter | ||
Comment 61•13 years ago
|
||
We'd like to start Extended Validation Certificates recognition. What steps must we follow? Thanks.
Assignee | ||
Comment 62•13 years ago
|
||
Please provide the following information regarding EV... 1) URLs and section numbers of the CP/CPS documentation regarding verification of organization identity and domain name ownership/control for EV certs. 2) EV Policy OID(s) 3) URL to a website whose EV SSL cert chains up to this root (may be a test site). 4) EV Audit statement 5) Updated CA Hierarchy info (e.g. differences from what is described in the attached Information Gathering Document).
Reporter | ||
Comment 63•13 years ago
|
||
Thanks Kathleen, we are preparing the required information. As a reference of our progress, we have already obtained Webtrust's EV seal: https://cert.webtrust.org/ViewSeal?id=1189 Anyway, we want to be sure that EV recognition, does not delay the recognition process for the rest of our certificates, as we've been working on for a long time. We'd like to finish the current process as fast as possible, so will start with EV certificates recognition only if it's a parallel process and doesn't delay the recognition of the rest of certificates. Could you confirm us this point, please?
Assignee | ||
Comment 64•13 years ago
|
||
I am planning to start this discussion the week of August 15. When do you expect to have the rest of the EV information available as per comment #62?
Assignee | ||
Comment 65•13 years ago
|
||
I am re-reviewing this request to prepare it for the upcoming public discussion. Regarding Comment #46: > 3.- Some time ago we explained how the domain checking was done and > documented in our internal procedure. > We add the same explanation, but this time we add the translation of the > procedure referred part. If you agree that this procedure complies with your > requirements we will refer it from the CPS (or we will add this part of the > procedure to our CPS if this is necessary). > > Summarizing next steps: > 1.- Only authorized personal from Catalan Administration can request a > certificate (Domain Server Certificate). > 2.- (Items 1.3.2.1 – 1.3.2.5) It’s checked the applicant is an authorized > person. > 3.- (Item 1.3.2.7) It is checked using www.whois.net the existence of the > server and the ownership. > Regarding the step 3, in your recommended practices it’s mentioned it can be > correlated the whois information with other sources. At this moment we only > use one source because only authorized people can be applicants, but it’s > not a problem for us to add another source if this is not enough for you. > Please let me know where I can find these 3 items in the CP or CPS documents. According to the Mozilla CA Certificate Policy, this information must be in publicly available and audited documentation. https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
Reporter | ||
Comment 66•13 years ago
|
||
Regarding Comment #64: These are fantastic news Kathleen! answering your question, we hope to have all EV information at the end of september or at maximum at october (we have to delay the creation of the test URLs in order to apply minimal changes to the certificates profile in order to acomplish with new Spanish Industry Ministery requirements).
Reporter | ||
Comment 67•13 years ago
|
||
Regarding Comment #65: The points 1 and 2: ------------------- are specified in each CPS, you can find all them at the link: http://www.catcert.cat/web/cas/5_2_declaracio.jsp . There you have a different CPS for each certification authority (they are in Spanish): - EC-ACC: is the root entity and is offline - EC-AL : this entity only issues certificates to “local government” of Catalonia (these are the city councils). - EC-GENCAT and EC-SAFP: they only issue certificates to “autonomic government of Generalitat”. - EC-UR: only issues certificates to public universities (in Spain, universities are also public administration). - EC-URV: only issues certificates to the public Rovira Virgili University (is public administration). - EC-Parlament: only issues certificates to the Catalonia Parliament. - EC-idCAT: only issues certificates to citizens of Catalonia and it does not issue SSL server certificates to other administrations (except itself SSL certificate for the www.idcat.cat domain). So all server certificates are only issued to the limited well-known public governments and administrations of Catalonia. In each CPS you can find the authorization requirements, for example in the EC-AL: -------------------- 4.1 SOLICITUD DE EMISIÓN DE CERTIFICADO .... 38 4.1.1 Legitimación para solicitar la emisión .... 38 4.1.2. Procedimiento de alta; Responsabilidades .... 38 4.2 PROCEDIMIENTO DE SOLICITUD DE CERTIFICACIÓN .... 39 4.2.1 Requisitos generales para todos los certificados .... 39 4.2.2. Requisitos específicos para el CEIXSA .... 40 4.2.3.Informaciones adicionales para el CDS, el CDSCD y el CDS-1 de Sede Electrónica .... 40 4.2.4 Informaciones adicionales para el CIPISR.... 40 4.2.5. Otros certificados.... 41 --------------------- To sum up: each client administration sends us a client data form with the information of the authorized people that can request the issue of certificates for that administration. This form is typically signed and sealed by the mayor or some other high government organ of that administration. We verify the data in the form, address, public composition of the organization, and so on, with the database of public organizations (maintained by the Public administrations department of the Catalonia Government). Then, the authorized people can request certificates in most of cases online with EACAT (the Catalonian Extranet for administration) (www.eacat.cat), signing the application form with its own digital certificate through Internet (only people with the correct assigned role can do it, this is verified automatically in online requests or manually in the residual paper ones). Then, some automatic verification is done (included for EV) to check the correct domain format, no appearance in anti-phishing list, etc. And finally, before the issue of certificate, there is a manual verification, searching the WHOIS database to see the ownership of the domain, as explained later. This is the same in all the other certification authorities. The point 3: ------------ can be found at the public procedure, applied by all the ER-TCAT (Registration Entities) at the URL: http://www.catcert.cat/web/cas/1_0_2_er_tcat.jsp , there is a “Procediments” link that goes directly to: http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip . Inside the ZIP file there is the operative procedure for the registration entities: D1132-PO-00-procediment_operatiu_20070920.pdf, and in the title “1.3.2.7 Verificació de les dades del certificat CDS i CDSDC” you can find the requirement to validate the existence and server ownership using WHOIS services, doing a quick translation it says: In the case of a request for a CDS (“server certificate”), the responsible of the SCD (“Digital Certificate Service”) will verify the URL of the server with WHO IS (www.whois.net), in order to verify its existence. The resulting page will be converted to PDF format and will be signed digitally. It is saved one printed copy and one in electronic format in the file of that request. --- If you need any further information or more detail in some part, please let us know. Thank you.
Assignee | ||
Comment 68•13 years ago
|
||
(In reply to comment #67) > Regarding Comment #65: > > > The points 1 and 2: > ------------------- > > are specified in each CPS, you can find all them at the link: > http://www.catcert.cat/web/cas/5_2_declaracio.jsp . > > There you have a different CPS for each certification authority > <snip> > In each CPS you can find the authorization requirements, for example in the > EC-AL: > -------------------- > 4.1 SOLICITUD DE EMISIÓN DE CERTIFICADO .... 38 > 4.1.1 Legitimación para solicitar la emisión .... 38 > 4.1.2. Procedimiento de alta; Responsabilidades .... 38 > 4.2 PROCEDIMIENTO DE SOLICITUD DE CERTIFICACIÓN .... 39 > 4.2.1 Requisitos generales para todos los certificados .... 39 > 4.2.2. Requisitos específicos para el CEIXSA .... 40 > 4.2.3.Informaciones adicionales para el CDS, el CDSCD y el CDS-1 de Sede > Electrónica .... 40 > 4.2.4 Informaciones adicionales para el CIPISR.... 40 > 4.2.5. Otros certificados.... 41 > --------------------- > > > To sum up: each client administration sends us a client data form with the > information of the authorized people that can request the issue of > certificates for that administration. This form is typically signed and > sealed by the mayor or some other high government organ of that > administration. We verify the data in the form, address, public composition > of the organization, and so on, with the database of public organizations > (maintained by the Public administrations department of the Catalonia > Government). > > Then, the authorized people can request certificates in most of cases online > with EACAT (the Catalonian Extranet for administration) (www.eacat.cat), > signing the application form with its own digital certificate through > Internet (only people with the correct assigned role can do it, this is > verified automatically in online requests or manually in the residual paper > ones). > > Then, some automatic verification is done (included for EV) to check the > correct domain format, no appearance in anti-phishing list, etc. > > And finally, before the issue of certificate, there is a manual > verification, searching the WHOIS database to see the ownership of the > domain, as explained later. > > This is the same in all the other certification authorities. > > I am looking in the EC-AL DPC (using Google Translate) to try to find the sections about correct domain format, anti-phishing, and whois. I cannot find this text. What section(s) should I be looking in?
Reporter | ||
Comment 69•13 years ago
|
||
Hi Kathleen, first of all thank you for the effort of using Google Translate; you are right, in the current CPS there is not the low level information for the items requested, but we are applying them: - Domain format controls: our application verifies automatically that the domain is in FQDN form. If not, the certificate cannot be issued. - Anti-phishing controls: the application verifies automatically that the domain is neither in the public list of phishing (www.phishtank.com) nor in the internal database of certificates issued by CATCert and revoked by phishing reason. - Registration of domain: the manual validation of whois is only mentioned in the public procedure of register entity operation, which I mentioned in my last post. Nowadays, the detail of the information about the automatic controls (verification of domain format and anti-phishing) is only in the administration procedure (document not public for security reasons). We should quickly add the information about those automatic controls in the public operating procedure, but changing the CPS would require a little more time, because in order to change CPS we need the final approval of all the political partners associated to each certification authority, and maybe some of them are now on holidays. Would be the option of putting the information in the public operating procedure valid for you (meanwhile we put it on all CPS, get the approval to publish, and so on)?
Assignee | ||
Comment 70•13 years ago
|
||
> - Domain format controls: our application verifies automatically that the > domain is in FQDN form. If not, the certificate cannot be issued. > - Anti-phishing controls: the application verifies automatically that the > domain is neither in the public list of phishing (www.phishtank.com) nor in > the internal database of certificates issued by CATCert and revoked by > phishing reason. When does the application for verifying domain format and anti-fishing actually get run? e.g. is it when someone requests the certificate creation? > - Registration of domain: the manual validation of whois is only mentioned > in the public procedure of register entity operation, which I mentioned in > my last post. Thank you for the clarification. > > Nowadays, the detail of the information about the automatic controls > (verification of domain format and anti-phishing) is only in the > administration procedure (document not public for security reasons). We > should quickly add the information about those automatic controls in the > public operating procedure, but changing the CPS would require a little more > time, because in order to change CPS we need the final approval of all the > political partners associated to each certification authority, and maybe > some of them are now on holidays. > Would be the option of putting the information in the public operating > procedure valid for you (meanwhile we put it on all CPS, get the approval to > publish, and so on)? I think the operating procedure is fine. Our requirement is that the information be available in a public and audited document. I have another question... In the CPS there is information about class 1 and class 2 certificates. Are SSL certificates issued for both class 1 and class 2? I'm not sure I understand what class 1 certificates are.
Reporter | ||
Comment 71•13 years ago
|
||
(In reply to Kathleen Wilson from comment #70) > > - Domain format controls: our application verifies automatically that the > > domain is in FQDN form. If not, the certificate cannot be issued. > > - Anti-phishing controls: the application verifies automatically that the > > domain is neither in the public list of phishing (www.phishtank.com) nor in > > the internal database of certificates issued by CATCert and revoked by > > phishing reason. > > > When does the application for verifying domain format and anti-fishing > actually get run? e.g. is it when someone requests the certificate creation? > Yes it is, but also done when the registry entity operator does the internal approbation to allow the generation, and also when the effective certificate generation is done by other operator. > > > - Registration of domain: the manual validation of whois is only mentioned > > in the public procedure of register entity operation, which I mentioned in > > my last post. > > Thank you for the clarification. > > > > > Nowadays, the detail of the information about the automatic controls > > (verification of domain format and anti-phishing) is only in the > > administration procedure (document not public for security reasons). We > > should quickly add the information about those automatic controls in the > > public operating procedure, but changing the CPS would require a little more > > time, because in order to change CPS we need the final approval of all the > > political partners associated to each certification authority, and maybe > > some of them are now on holidays. > > Would be the option of putting the information in the public operating > > procedure valid for you (meanwhile we put it on all CPS, get the approval to > > publish, and so on)? > > > I think the operating procedure is fine. Our requirement is that the > information be available in a public and audited document. That’s perfect, on Monday we will work on completing the public procedure and hope to have it uploaded to the web on Tuesday (I will post when it’s done). > > > I have another question... > > In the CPS there is information about class 1 and class 2 certificates. Are > SSL certificates issued for both class 1 and class 2? I'm not sure I > understand what class 1 certificates are. Well, class 1 are certificates issued only to public administrations or to people that have a direct work contract with them (these are public employees). And class 2 are certificates issued to citizens. In the specific case of server certificates we only issue class 1 certificates; for example when we get a request for a class 2 server certificate we redirect them to another certification authorities such as: camerfirma, firmaprofesional, verisign etc.
Assignee | ||
Comment 72•13 years ago
|
||
(In reply to Francesc Ferré from comment #71) > > > > In the CPS there is information about class 1 and class 2 certificates. Are > > SSL certificates issued for both class 1 and class 2? I'm not sure I > > understand what class 1 certificates are. > > Well, class 1 are certificates issued only to public administrations or to > people that have a direct work contract with them (these are public > employees). And class 2 are certificates issued to citizens. In the specific > case of server certificates we only issue class 1 certificates; for example > when we get a request for a class 2 server certificate we redirect them to > another certification authorities such as: camerfirma, firmaprofesional, > verisign etc. In the General CP: "3.2.2.3.1 Requirements for class 1 certificates It is not required to carry out an authentication procedure of the titular organization of the certificate for class 1 certificates, because these are corporative certificates where the subscriber organization of the certificate is the same than the Registration Entity." I don't understand what this means. My notes indicate that SSL certs are OV, but that would mean that the organization verification is performed as well as the domain ownership/control verification. Then section, 3.2.2.3.2 "Requirements for class 2 certificates", provides a high level description of identity, organization, and domain name verification. Is it correct to say that this section does not apply to the issuance of SSL certificates because CATCert does not issue class 2 SSL certs?
Reporter | ||
Comment 73•13 years ago
|
||
(In reply to Francesc Ferré from comment #71) > > Nowadays, the > detail of the information about the automatic controls > > (verification of > domain format and anti-phishing) is only in the > > administration procedure > (document not public for security reasons). We > > should quickly add the > information about those automatic controls in the > > public operating > procedure, but changing the CPS would require a little more > > time, > because in order to change CPS we need the final approval of all the > > > political partners associated to each certification authority, and maybe > > > some of them are now on holidays. > > Would be the option of putting the > information in the public operating > > procedure valid for you (meanwhile > we put it on all CPS, get the approval to > > publish, and so on)? > > > I > think the operating procedure is fine. Our requirement is that the > > information be available in a public and audited document. > That’s perfect, > on Monday we will work on completing the public procedure and hope to have > it uploaded to the web on Tuesday (I will post when it’s done). We have already uploaded a more complete public operation procedure for registry entities, you can found it on URL: http://www.catcert.cat/web/cas/1_0_2_er_tcat.jsp and clicking at the "Procedimientos" link at the end of the page, inside you will find the document: D1132-PO-00-procediment_operatiu_ER _T-CAT_20110808.pdf , and inside of the document at point 1.3.2.6 there is the next explanation (translated to english): 1.1.1.1 Verification of the data of server certificates containing public URLs When receiving requests for server certificates that include a public URL, the person in charge of the ER T-CAT will verify the server URL and the data using the WHO IS service (http://www.whois.net and http://www.internic.net/whois.html for domains .cat).The result will be converted to PDF format and digitally signed. A copy in digital format will be saved and another one will be printed and attached to the request file. The person in charge will validate that the domain belongs to the same organization that requests the certificate. If it does not, the process must be stopped and the owner of the domain indicated by WHOIS and the responsible for the certificate requesting organization must be contacted in order to validate the correctness of the domain before generating the certificate. Otherwise the application also performs automatic controls on the quality of the URL domain, such as: - the automatic validation that the domain is a Fully Qualified Domain Name (FQDN) as the syntax: <subdomain>. <domain>. <tld> , for example: "www.catcert.cat" - it is automatically validated that the URL of the domain is: • not included in the AntiPhishing list www.phishtank.com • not included in any previous certificate issued by CATCert and revoked by phishing reason This anti-phishing control is done in each step of the flow, from the initial request to the final generation, because a domain can enter the anti-phishing lists at any time.
Reporter | ||
Comment 74•13 years ago
|
||
(In reply to Kathleen Wilson from comment #72) > (In reply to Francesc Ferré from comment #71) > > > > > > In the CPS there is information about class 1 and class 2 certificates. Are > > > SSL certificates issued for both class 1 and class 2? I'm not sure I > > > understand what class 1 certificates are. > > > > Well, class 1 are certificates issued only to public administrations or to > > people that have a direct work contract with them (these are public > > employees). And class 2 are certificates issued to citizens. In the specific > > case of server certificates we only issue class 1 certificates; for example > > when we get a request for a class 2 server certificate we redirect them to > > another certification authorities such as: camerfirma, firmaprofesional, > > verisign etc. > > > In the General CP: "3.2.2.3.1 Requirements for class 1 certificates > It is not required to carry out an authentication procedure of the titular > organization of the certificate for class 1 certificates, because these are > corporative certificates where the subscriber organization of the > certificate is the same than the Registration Entity." > > I don't understand what this means. My notes indicate that SSL certs are OV, > but that would mean that the organization verification is performed as well > as the domain ownership/control verification. > Yes, this point refers to the case that the Registry entity organization requests certificates to itself. In this case, the organization doesn’t have to apply controls to authenticate to itself because this identity is already well known. For example, when the registry entity of the Barcelona Council has to request certificates to itself it doesn’t have to verify the existence of the Barcelona Council as an organization. Furthermore, there are specific requirements to SSL sever certificates in each CPS that complement the general CP, for example if you go to point 3.2.2.1.1.3 at the EC-AL CPS (http://catcert.cat/descarrega_cas/oficina_politicas/D1111_N-DPC-EC-AL_v3r6_cas.pdf), you can see that in case of server certificates it must be validated, in all cases, that: - The server exists - The domains ownership - The authorization of the organization in order to issue the certificate > > Then section, 3.2.2.3.2 "Requirements for class 2 certificates", provides a > high level description of identity, organization, and domain name > verification. Is it correct to say that this section does not apply to the > issuance of SSL certificates because CATCert does not issue class 2 SSL > certs? Yes, it is, but if some day the “comercial” strategy of CATCert changes in order to issue certificates to private corporations, then they would apply (I don’t think this is going to happen).
Assignee | ||
Comment 76•13 years ago
|
||
I am now opening the first public discussion period for this request from CATCert to add the “EC-ACC” root certificate, and turn on the websites trust bit. 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 “CATCert Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of CATCert must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
Reporter | ||
Comment 79•13 years ago
|
||
(In reply to andreawngfld from comment #78) > Created attachment 556371 [details] > wrong issued certificates > > See first discussion The controls that verify the correctness of the domain names where implanted this year just before the EV seal achievement, but unfortunately these are certificates issued before. On Monday we are going to investigate the number of certificates issued with internal IP or with incorrect FQDN form, and will discuss with our direction in order to find the way to revoke them with the minimum technical and political impact for our clients, because some of these certificates are probably used in production environments that should not stop. We will inform here with the progress of each step to solve this problem.
Assignee | ||
Comment 80•13 years ago
|
||
Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
Comment 81•13 years ago
|
||
(In reply to Kathleen Wilson from comment #80) > Please review the CA Communication that was recently sent, and is available > here: https://wiki.mozilla.org/CA:Communications > > Please add a comment to this bug to provide your response to the action > items listed in the CA Communication. For more information about action > items #1 and #3, please see items #6 and #7 of > https://wiki.mozilla.org/CA: > Information_checklist#Verification_Policies_and_Practices Hi Katheleen, we have covered the basis of all the items, if you need more information we can prepare a sum up of the controls and send directly to your email address.
Assignee | ||
Comment 82•13 years ago
|
||
Added info regarding controls for cert issuance and registry entities.
Attachment #551896 -
Attachment is obsolete: true
Assignee | ||
Comment 83•13 years ago
|
||
The public comment period for this request is now over. This request has been evaluated as per Mozilla’s CA Certificate 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 to add the “EC-ACC” root certificate and turn on the websites trust bit. Section 4 [Technical]. I am not aware of instances where CATCert has 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]. CATCert appears to provide a service relevant to Mozilla users: It is a public company that serves as the government CA of the Region of the Autonomic Community of Catalunya 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 CP, DPC for each subCA, and the Operative Procedure. The documents are in Spanish and Catalan. English translations of some sections have been provided. Document Repository: http://www.catcert.cat/registre CP: http://www.catcert.cat/web/cat/5_1_politica_general.jsp DPC (Declaración de Prácticas de Certificación) for each sub-CA: http://www.catcert.cat/web/cat/5_2_declaracio.jsp Operative Procedure: http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip File: D1132-PO-00-procediment_operatiu_ER _T-CAT_20110808.pdf Section 7 [Validation]. CATCert appears to meet the minimum requirements for subscriber verification, as follows: * SSL: SSL certificates are only issued to the limited well-known public governments and administrations of Catalonia. The subCAs that can issue SSL certs are EC-SAFP, EC-AL, EC-UR, EC-URV, and EC-Parlamant. Their DPC documents have the following in section 3.2.2: For device certificates secure server and domain controller, in addition to checking has been carried out by the organization responsible for the secure server is checked: ** The existence of the server. ** Ownership of the domain name from the registry. **Authorization for the organization of the issuance of the certificate on the server. Verification of SSL certificate subscribers requires a manual step of identity/organization verification. Additionally,CATCert has automatic blocks in place for high-profile domain names. * Email: N/A. Not requesting the email trust bit at this time. * Code: N/A. Not requesting the code signing trust bit at this time. Section 15 [Certificate Hierarchy]. This root has internally-operated subordinate CAs. The subCAs are used to distinguish who the certificates are issued to. ** The EC-idCAT subCA issues certificates to Catalan citizens. It does not issue SSL certificates to other administrations (except itself SSL certificate for the www.idcat.cat domain). ** The EC-SAFP (sub-CA of EC-GENCAT), EC-AL (Administracions Locals de Catalunya), and EC-Parlament (Parlament de Catalunya) subCAs only issue certificates to the civil servants and computers or devices of the Regional Catalan government, the Catalan Government, and the Catalan Parliament. Including city and town councils, regional councils, county councils, as well as autonomous agencies and public funded companies. ** The EC-UR (Universitats i Recerca) and EC-URV (Universitat Rovira i Virgili) subCAs only issue certificates to employees, students and computers or devices of Catalan universities and research centers connected to the “Anella Científica” group, and the Universitat Rovira i Virgili (URV). * RAs are external to CATCert but they belong to the Catalan Public Administration. It means they have in common the application of the controls specified at the Spanish Law 30/92 about procedures of the Public Administration. These RAs sign a contract with CATCert, and their way of working is periodically audited using the clauses of the contract. * Both CRL and OCSP are provided under this root ** CP section 4.9.7.2: The Certification Body shall issue a Linked CRL at least every 24 hours. Section 8-10 [Audit]. Audits have been performed by Ernst & Young according to the WebTrust CA and WebTrust EV criteria. The audit reports are posted on the cert.webtrust.org website: https://cert.webtrust.org/ViewSeal?id=1063 and https://cert.webtrust.org/ViewSeal?id=1189 Note: Not requesting EV treatment at this time. Based on this assessment I intend to approve this request to add the “EC-ACC” root certificate and turn on the websites trust bit.
Whiteboard: In public discussion → Pending Approval
Assignee | ||
Comment 84•13 years ago
|
||
To the representatives of CATCert: 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 #83, and on behalf of Mozilla I approve this request from CATCert to include the following root certificate in Mozilla products: * EC-ACC (websites) I will file the NSS bug to effect the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Comment 86•13 years ago
|
||
I update the bug with the webtrust renew link: https://cert.webtrust.org/ViewSeal?id=1238
Assignee | ||
Comment 87•13 years ago
|
||
EC-ACC is a "Builtin Object Token" in FF 11.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 13 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → Included in FF 11
Reporter | ||
Comment 88•11 years ago
|
||
Dear Kathleen, Please, update Mozilla's spreadsheet of included root certificates with the following information: URL to Test Website: https://www.aoc.cat/ Company Website : http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert Certificate Policy (CP) : http://www.aoc.cat/content/download/25607/46726/file/politicaGeneralCertificacioAngles.pdf Certification Practice Statement (CPS): http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert/Regulacio Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf Baseline Requirements Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf EV Audit : https://cert.webtrust.org/SealFile?seal=1648&file=pdf Auditor : Ernst & Young Audit Criteria : WebTrust Audit Statement Date : 2014/03/10
Assignee | ||
Comment 89•11 years ago
|
||
(In reply to Francesc Ferré from comment #88) > Dear Kathleen, > > Please, update Mozilla's spreadsheet of included root certificates with the > following information: > > URL to Test Website: https://www.aoc.cat/ > Company Website : > http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert > Certificate Policy (CP) : > http://www.aoc.cat/content/download/25607/46726/file/ > politicaGeneralCertificacioAngles.pdf > Certification Practice Statement (CPS): > http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert/ > Regulacio > > Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf Done. > Baseline Requirements Audit : > https://cert.webtrust.org/SealFile?seal=1647&file=pdf Maybe I'm missing something, but I don't see reference to the Baseline Requirements audit in this file. http://www.webtrust.org/homepage-documents/item72056.pdf > EV Audit : https://cert.webtrust.org/SealFile?seal=1648&file=pdf This root is not enabled for EV. Thanks, Kathleen
Reporter | ||
Comment 90•10 years ago
|
||
Dear Kathleen, We would like to enable this root for EV. How do we have to proceed?. Do we have to create a new bug for this request or we can just keep on using this one?. Thank you, Francesc,
Assignee | ||
Comment 91•10 years ago
|
||
Please file a new bug. https://wiki.mozilla.org/CA:How_to_apply#Enable_EV_for_an_included_root
Assignee | ||
Comment 92•9 years ago
|
||
Updated•8 years ago
|
Product: mozilla.org → NSS
Updated•2 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•