CATCert Root Inclusion Request
Kathleen Wilson
the websites trust bit.
CATCert is the Catalan Agency of Certification (Ag�ncia Catalana de
Certificaci�), a public company that serves as the government CA of the
Region of the Autonomic Community of Catalunya in Spain.
EC-ACC stands for: Entitat de Certificaci� de l�Ag�ncia Catalana de
Certificaci�.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=295474
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#CATCert
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=551896
Noteworthy points:
* The primary documents 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
* CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=379561
* 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).
* The request is to turn on the Websites trust bit.
* Identity and Organizational verification procedures are described in
section 3 of the CP. Translation of section 3 into English was provided
as an attachment to the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=479370
** In the CP section 3.2.2.3.1, �Requirements for class 1 certificates�,
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.
** CP section 3.2.2.3.2, �Requirements for class 2 certificates�, is
there in case some day the commercial strategy of CATCert changes in
order to issue certificates to private corporations. Currently no class
2 SSL certificates are issued, and there is no plan to do so.
* 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.
* The Operative Procedure, applied by all the Registration Entities is
available at http://www.catcert.cat/web/cas/1_0_2_er_tcat.jsp. The link
is called �Procediments� points to a zip file which contains the file
D1132-PO-00-procediment_operatiu_ER _T-CAT_20110808.pdf
Sections 1.3.2.4 and 1.3.2.5 describe validation of the certificate
subscriber�s identity and authority. Translations are provided in the
Information Gathering document.
* Operative Procedure section 1.3.2.6:
** 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.
* EV Policy OID: Not requesting EV treatment at this time.
* Test Websites
** EC-SAFP:
https://contractaciopublica.gencat.cat/ecofin_pscp/AppJava/notice.pscp?reqCode=searchCn&idCap=203732
** EC-AL:
https://seu.badalona.cat/portalWeb/badalona.portal?_nfpb=true&_pageLabel=seu_electronica
** EC-UR: https://seuelectronica.upc.edu/
** EC-URV: https://portal.urv.cat/portal/dt
* CRL:
http://epscd.catcert.net/crl/ec-acc.crl
http://epscd.catcert.net/crl/ec-al.crl
http://epscd.catcert.net/crl/ec-gencat.crl
http://epscd.catcert.net/crl/ec-safp.crl
http://epscd.catcert.net/crl/ec-ur.crl
http://epscd.catcert.net/crl/ec-urv.crl
http://epscd.catcert.net/crl/ec-parlament.crl
http://epscd.catcert.net/crl/ec-idcat.crl
** CP section 4.9.7.2: The Certification Body shall issue a Linked CRL
at least every 24 hours.
* OCSP: http://ocsp.catcert.net
* Audit: Audits have been performed by Ernst & Young according to the
WebTrust CA and WebTrust EV criteria. The audit reports re posted on the
cert.webtrust.org website: https://cert.webtrust.org/ViewSeal?id=1063
and https://cert.webtrust.org/ViewSeal?id=1189
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Delegation of Domain / Email validation to third parties
** 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.
** CP section 1.3.4: There are three types of register entities:
1) Internal Registration Entities operated by a subscriber institution
of class 1 certificates.
2) Virtual Registration Entities, relevant to certificate subscriber
institutions that have delegated the registry to CATCert or to Associate
Registration Entities
3) Associate Registration Entities, which collaborate with the
subscriber institutions of class 1 certificates in the certificates
issuing process, and which collaborate with Certification Entities in
the class 2 certificates issuing process.
Institutions, in order to become Internal Registration Entities, will
have to design and implement the technical, juridical and security
procedures regarding the lifecycle of the certificates that they issue.
These procedures will be previously validated by the Certification Entity.
This begins the discussion of the request from CATCert to add the
�EC-ACC� root certificate, and turn on the websites trust bit. At the
conclusion of this discussion, I will provide a summary of issues noted
and action items. If there are no outstanding issues, then this request
can be approved. If there are outstanding issues or action items, then
an additional discussion may be needed as follow-up.
Kathleen
Erwann Abalea
It also has a specific certificatePolicy (useless in a root): 1.3.6.1.4.1.15096.1.3.1.10
The certificate EC-UR has a different OID in its certificatePolicies extension: 1.3.6.1.4.1.15096.1.3.1.12
It also has a userNotice policyQualifier encoded in visibleString, with an 8bits variant. Accented characters may not display correctly depending on the client settings.
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
The OCSP responder for EC-UR has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, which is not among the policy OIDs allowed to EC-UR by EC-ACC.
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
The certificate delivered to the test site seuelectronica.upc.edu has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, again not among the policy OIDs allowed to EC-UR by EC-ACC.
It also has T61String elements in the subject field (deprecated long ago for interoperability reasons), and a jurisdictionOfIncorporationCountryName element which does not use the standard 2-letter country code format.
It also has an empty dNSName in the subjectAltName extension, and invalid characters in this same extension (DirName with PrintableString elements with 8-bits characters).
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
Erwann Abalea
Manuel Rella
________________________________
De: dev-security-policy-bounces+mrella=catce...@lists.mozilla.org en nombre de Erwann Abalea
Enviado el: mar 23/08/2011 17:33
Para: mozilla-dev-s...@lists.mozilla.org
CC: mozilla-dev-s...@lists.mozilla.org
Asunto: Re : CATCert Root Inclusion Request
The root certificate (EC-ACC) has a negative serial number. EE:2B:3D:EB:D4:21:DE:14:A8:62:AC:04:F3:DD:C4:01 is used, without the prefixing 00 to make it positive. The numerical value is -11D4C2142BDE21EB579D53FB0C223BFF in hex, and this is not allowed by RFC2459 and its successors.
*** We agree with that point, since 2002 the RFC 3280 and later RFC 5280 force CAs not to issue negative numbers. The fact is that our root CA created in 2003 is not accomplishing that point because in design time was used the RFC2459 that didn't have this requirement about serial numbers. Anyway it is specified in RFCs 3280 and 5280 that "Certificate users SHOULD be prepared to gracefully handle such certificates", so the practical experience is that we have not been reported yet for any interoperability problems caused by this issue. Furthermore we are planning to create another root certificate during 2012 with SHA-256 algorithm, so we will take special care at this point. We hope this will not be a blocking point for the inclusion of CATCert's root certificate in Firefox navigator.
It also has a specific certificatePolicy (useless in a root): 1.3.6.1.4.1.15096.1.3.1.10
The certificate EC-UR has a different OID in its certificatePolicies extension: 1.3.6.1.4.1.15096.1.3.1.12
*** The OID map was created following the RFC2459 that doesn't restrict the OIDs generated by a subordinated CA. As before, we will apply this requirement in the new SHA-256 hierarchy and hope this will not be a blocking point.
It also has a userNotice policyQualifier encoded in visibleString, with an 8bits variant. Accented characters may not display correctly depending on the client settings.
*** This is a known issue for us, we codify with PrintableString/teletexstring when it should be UTF-8, this was an ancient requirement (about 2004) of the systems of the "Agencia Tributaria" of Spain -> "Taxes Agency of Spain" for its internal compatibility with de hierarchy certificates. We are going to ask again to that Agency about the need of that requirement nowadays, and in function of his answer unify all to UTF-8 in the new SHA-2 hierarchy.
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
*** Yes, this is nowadays functionality, we are planning to simplify this attribute and leave only the keyId in the new SHA-2 hierarchy and in the final certificates issued by this.
The OCSP responder for EC-UR has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, which is not among the policy OIDs allowed to EC-UR by EC-ACC.
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
The certificate delivered to the test site seuelectronica.upc.edu has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, again not among the policy OIDs allowed to EC-UR by EC-ACC.
*** Same explanation as before, we based the initial implementation in RFC2459.
It also has T61String elements in the subject field (deprecated long ago for interoperability reasons),
*** Same explanation as before about the compatibility with "Agencia Tributaria".
and a jurisdictionOfIncorporationCountryName element which does not use the standard 2-letter country code format.
*** Yes this is a buggy implementation, we must validate that this attribute complies with the 3166 ISO as the country (C) attribute already does, we are going to implement as soon as possible (before september ends) the code that controls that issue to avoid problems.
It also has an empty dNSName in the subjectAltName extension, and invalid characters in this same extension (DirName with PrintableString elements with 8-bits characters).
*** We are going to investigate why dNSName has a blank character when it should not, and in which cases this bug is produced, it will be resolved also before september ends.
It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
*** Same explanation as before, we are going leave only keyId in the new SHA-2 implementation.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Erwann Abalea
Le jeudi 25 août 2011 15:11:03 UTC+2, Manuel Rella a écrit :
> First of all thank you for your comments because will help improve our compliance with latest standards, we will now answer each point with the nowadays situation:
> ________________________________
> De: dev-security-policy-bounces+mrella=catce...@lists.mozilla.org en nombre de Erwann Abalea
> Enviado el: mar 23/08/2011 17:33
>
>> The root certificate (EC-ACC) has a negative serial number. EE:2B:3D:EB:D4:21:DE:14:A8:62:AC:04:F3:DD:C4:01 is used, without the prefixing 00 to make it positive. The numerical value is -11D4C2142BDE21EB579D53FB0C223BFF in hex, and this is not allowed by RFC2459 and its successors.
> *** We agree with that point, since 2002 the RFC 3280 and later RFC 5280 force CAs not to issue negative numbers. The fact is that our root CA created in 2003 is not accomplishing that point because in design time was used the RFC2459 that didn't have this requirement about serial numbers.
You're right, RFC2459 didn't enforce non-negative serial numbers. But I doubt you really choosed to specify such a large negative number. That's only a guess, but I think you generated some random bytes (maybe the result of a hash), and considered the serial number as an octet string.
>> It also has a specific certificatePolicy (useless in a root): 1.3.6.1.4.1.15096.1.3.1.10
>>
>> The certificate EC-UR has a different OID in its certificatePolicies extension: 1.3.6.1.4.1.15096.1.3.1.12
>
> *** The OID map was created following the RFC2459 that doesn't restrict the OIDs generated by a subordinated CA. As before, we will apply this requirement in the new SHA-256 hierarchy and hope this will not be a blocking point.
RFC2459 didn't, but the X.509 standard, since its 2000 edition, does:
"The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this
certificate may be valid." (text taken from the 200/03 edition).
>> It also has a userNotice policyQualifier encoded in visibleString, with an 8bits variant. Accented characters may not display correctly depending on the client settings.
>
> *** This is a known issue for us, we codify with PrintableString/teletexstring when it should be UTF-8, this was an ancient requirement (about 2004) of the systems of the "Agencia Tributaria" of Spain -> "Taxes Agency of Spain" for its internal compatibility with de hierarchy certificates. We are going to ask again to that Agency about the need of that requirement nowadays, and in function of his answer unify all to UTF-8 in the new SHA-2 hierarchy.
You're not using T61String here, but VisibleString, which doesn't allow you to tell which encoding variant was used (the relying party must guess it).
Please tell them that T.61, the base standard for T61String/TeletexString, has been withdrawn years ago (the 1993 edition has never been published, the 1988 was declared obsolete, we can think the whole T.61 has been withdrawn around 1993).
>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>
> *** Yes, this is nowadays functionality, we are planning to simplify this attribute and leave only the keyId in the new SHA-2 hierarchy and in the final certificates issued by this.
It's listed on http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html as a possible reason to reject the inclusion of the root certificate.
>> The OCSP responder for EC-UR has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, which is not among the policy OIDs allowed to EC-UR by EC-ACC.
>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>> The certificate delivered to the test site seuelectronica.upc.edu has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, again not among the policy OIDs allowed to EC-UR by EC-ACC.
>
> *** Same explanation as before, we based the initial implementation in RFC2459.
>
>
>> It also has T61String elements in the subject field (deprecated long ago for interoperability reasons),
>
> *** Same explanation as before about the compatibility with "Agencia Tributaria".
>
>> and a jurisdictionOfIncorporationCountryName element which does not use the standard 2-letter country code format.
>
> *** Yes this is a buggy implementation, we must validate that this attribute complies with the 3166 ISO as the country (C) attribute already does, we are going to implement as soon as possible (before september ends) the code that controls that issue to avoid problems.
If you're not applying for EV, why are you inserting these fields? Do you have legal requirements to do so?
>> It also has an empty dNSName in the subjectAltName extension, and invalid characters in this same extension (DirName with PrintableString elements with 8-bits characters).
>
> *** We are going to investigate why dNSName has a blank character when it should not, and in which cases this bug is produced, it will be resolved also before september ends.
It's not a blank character, it's an empty value (length=zero).
And while T61String and VisibleString-with-8-bit-characters are valid (from the X.5xx and X.6[89]x standards), a PrintableString with 8bits characters is not X.680 compliant (this ITU recommendation can be freely downloaded).
> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>
> *** Same explanation as before, we are going leave only keyId in the new SHA-2 implementation.
--
Erwann.
Erwann Abalea
Le jeudi 25 août 2011 15:11:03 UTC+2, Manuel Rella a écrit :
> First of all thank you for your comments because will help improve our compliance with latest standards, we will now answer each point with the nowadays situation:
> ________________________________
> De: dev-security-policy-bounces+mrella=catce...@lists.mozilla.org en nombre de Erwann Abalea
> Enviado el: mar 23/08/2011 17:33
>
>> The root certificate (EC-ACC) has a negative serial number. EE:2B:3D:EB:D4:21:DE:14:A8:62:AC:04:F3:DD:C4:01 is used, without the prefixing 00 to make it positive. The numerical value is -11D4C2142BDE21EB579D53FB0C223BFF in hex, and this is not allowed by RFC2459 and its successors.
> *** We agree with that point, since 2002 the RFC 3280 and later RFC 5280 force CAs not to issue negative numbers. The fact is that our root CA created in 2003 is not accomplishing that point because in design time was used the RFC2459 that didn't have this requirement about serial numbers.
You're right, RFC2459 didn't enforce non-negative serial numbers. But I doubt you really choosed to specify such a large negative number. That's only a guess, but I think you generated some random bytes (maybe the result of a hash), and considered the serial number as an octet string.
>> It also has a specific certificatePolicy (useless in a root): 1.3.6.1.4.1.15096.1.3.1.10
>>
>> The certificate EC-UR has a different OID in its certificatePolicies extension: 1.3.6.1.4.1.15096.1.3.1.12
>
> *** The OID map was created following the RFC2459 that doesn't restrict the OIDs generated by a subordinated CA. As before, we will apply this requirement in the new SHA-256 hierarchy and hope this will not be a blocking point.
RFC2459 didn't, but the X.509 standard, since its 2000 edition, does:
"The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this
certificate may be valid." (text taken from the 200/03 edition).
>> It also has a userNotice policyQualifier encoded in visibleString, with an 8bits variant. Accented characters may not display correctly depending on the client settings.
>
> *** This is a known issue for us, we codify with PrintableString/teletexstring when it should be UTF-8, this was an ancient requirement (about 2004) of the systems of the "Agencia Tributaria" of Spain -> "Taxes Agency of Spain" for its internal compatibility with de hierarchy certificates. We are going to ask again to that Agency about the need of that requirement nowadays, and in function of his answer unify all to UTF-8 in the new SHA-2 hierarchy.
You're not using T61String here, but VisibleString, which doesn't allow you to tell which encoding variant was used (the relying party must guess it).
Please tell them that T.61, the base standard for T61String/TeletexString, has been withdrawn years ago (the 1993 edition has never been published, the 1988 was declared obsolete, we can think the whole T.61 has been withdrawn around 1993).
>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>
> *** Yes, this is nowadays functionality, we are planning to simplify this attribute and leave only the keyId in the new SHA-2 hierarchy and in the final certificates issued by this.
It's listed on http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html as a possible reason to reject the inclusion of the root certificate.
>> The OCSP responder for EC-UR has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, which is not among the policy OIDs allowed to EC-UR by EC-ACC.
>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>> The certificate delivered to the test site seuelectronica.upc.edu has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, again not among the policy OIDs allowed to EC-UR by EC-ACC.
>
> *** Same explanation as before, we based the initial implementation in RFC2459.
>
>
>> It also has T61String elements in the subject field (deprecated long ago for interoperability reasons),
>
> *** Same explanation as before about the compatibility with "Agencia Tributaria".
>
>> and a jurisdictionOfIncorporationCountryName element which does not use the standard 2-letter country code format.
>
> *** Yes this is a buggy implementation, we must validate that this attribute complies with the 3166 ISO as the country (C) attribute already does, we are going to implement as soon as possible (before september ends) the code that controls that issue to avoid problems.
If you're not applying for EV, why are you inserting these fields? Do you have legal requirements to do so?
>> It also has an empty dNSName in the subjectAltName extension, and invalid characters in this same extension (DirName with PrintableString elements with 8-bits characters).
>
> *** We are going to investigate why dNSName has a blank character when it should not, and in which cases this bug is produced, it will be resolved also before september ends.
It's not a blank character, it's an empty value (length=zero).
And while T61String and VisibleString-with-8-bit-characters are valid (from the X.5xx and X.6[89]x standards), a PrintableString with 8bits characters is not X.680 compliant (this ITU recommendation can be freely downloaded).
> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>
> *** Same explanation as before, we are going leave only keyId in the new SHA-2 implementation.
--
Erwann.
andrea...@hotmail.com
In the CA Hierarchy it is said EC-idCAT only issue SSL certificate for
www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
Secure Connection Failed
An error occurred during a connection to www.idcat.net.
The OCSP server found the request to be corrupted or improperly
formed.
(Error code: sec_error_ocsp_malformed_request)
[...]
Checking the CP/CPS section I can found a document recently updated,
probably because in comment 70 (bugzilla) it is said that some
procedures are descripted only in internal documentation (while it
should be public).
Does it mean all catalan public employees are good technicians and
they know how to issue digital certificates in a secure way? Did they
need this documentation?
If I'm right, it is not necessary to own IT knowledge in order to work
in city councils, then if the controls are not good enough, wrong
certificates can be issued.
I've googled a little and I've found the two public certificates
(attached to bugzilla). It proves:
Bad practices
Lack of security IT expertise
Lack of security IT awareness (managers)
Employees not properly trained who can issue certificates
Lack of automatic/manual controls
Inefficient auditory
I've been able to find these problems.
I'm sure this provider is not the only one who does not comply all
requirements, but is the one analyzed.
Security is a more serious matter than companies think.
My opinion is:
this provider should not be recognized
this data should be spread to other companies as a good practice
(Microsoft, Apple, Adobe, Google, …)
Auditory company should be penalized
Auditory reports should be more rigorous
I'm sorry if I misunderstood something.
Erwann Abalea
> In the CA Hierarchy it is said EC-idCAT only issue SSL certificate for
> www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
The OCSP Responder used to validate the www.idcat.cat certificate is not signed by the same CA (www.idcat.cat certificate is signed by EC-IDCat which in turn is signed by EC-ACC, this OCSP responder is directly signed by EC-ACC).
This is not valid.
I'll take a look at the 2 published certificates.
Please, could you post in non-anonymous mode? I don't think an anonymous contribution can count in the "at least 2 reviewers" rule :)
Erwann Abalea
> www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
The OCSP Responder used to validate the www.idcat.cat certificate is not signed by the same CA (www.idcat.cat certificate is signed by EC-IDCat which in turn is signed by EC-ACC, this OCSP responder is directly signed by EC-ACC).
Erwann Abalea
> Le dimanche 28 août 2011 10:27:56 UTC+2, [sans nom] a écrit :
> > In the CA Hierarchy it is said EC-idCAT only issue SSL certificate for
> > www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
>
> The OCSP Responder used to validate the www.idcat.cat certificate is not signed by the same CA (www.idcat.cat certificate is signed by EC-IDCat which in turn is signed by EC-ACC, this OCSP responder is directly signed by EC-ACC).
> This is not valid.
It should have been solved in november 2010. Maybe you solved the problem for http://ocsp.catcert.cat but not for its "https" counterpart?
Anyway, the OCSP service doesn't work with GET requests either. That means that for Windows-based browsers (IE, Safari on Win, Chrome on Win), Mac-based browsers (Safari on Mac, Chrome on Mac), and Opera, the OCSP request is performed, a bad answer is received, and the CRL is finally downloaded.
That also means it prevents Mozilla products to switch to GET-type requests (a wanted feature) in order to benefit from cache strategies.
Erwann Abalea
> > In the CA Hierarchy it is said EC-idCAT only issue SSL certificate for
> > www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
>
> The OCSP Responder used to validate the www.idcat.cat certificate is not signed by the same CA (www.idcat.cat certificate is signed by EC-IDCat which in turn is signed by EC-ACC, this OCSP responder is directly signed by EC-ACC).
> This is not valid.
It should have been solved in november 2010. Maybe you solved the problem for http://ocsp.catcert.cat but not for its "https" counterpart?
David E. Ross
You are creating duplicate replies. Please post your comments only in
the newsgroup mozilla.dev.security.policy or the mailing list
mozilla-dev-s...@lists.mozilla.org but not both. I think
threading works better for messages posted through the newsgroup.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Erwann Abalea
[...]
> You are creating duplicate replies. Please post your comments only in
> the newsgroup mozilla.dev.security.policy or the mailing list
> mozilla-dev-s...@lists.mozilla.org but not both. I think
> threading works better for messages posted through the newsgroup.
I already noticed it, and I'm really sorry for this. My reading and posting is from Google Groups, only. I don't know what is done behind.
Erwann Abalea
[...]
> the newsgroup mozilla.dev.security.policy or the mailing list
> mozilla-dev-s...@lists.mozilla.org but not both. I think
> threading works better for messages posted through the newsgroup.
I already noticed it, and I'm really sorry for this. My reading and posting is from Google Groups, only. I don't know what is done behind.
Erwann Abalea
Just a test with the old Google Groups interface, please ignore.
Jean-Marc Desperrier
> Le lundi 29 août 2011 17:29:59 UTC+2, David E. Ross a écrit :
> [...]
>> > You are creating duplicate replies. Please post your comments only in
>> > the newsgroup mozilla.dev.security.policy or the mailing list
> I already noticed it, and I'm really sorry for this. My reading and posting is from Google Groups, only. [...]
I already noticed those duplicates message are definitely linked to the
method use to post, adn to a bug in the architecture used. It would be
good to have an open description of how this system works exactly, what
software/configuration the various layers use.
Too bad there's not a meta group about the mailing lists.
Maybe mozilla.support.other would be adequate ? But I'm worried there
will not be the adequate people on that group.
Manuel Rella Ruiz
> Bonjour,
>
> Le jeudi 25 août 2011 15:11:03 UTC+2, Manuel Rella a écrit :
>> First of all thank you for your comments because will help improve our compliance with latest standards, we will now answer each point with the nowadays situation:
>> ________________________________
>> De: dev-security-policy-bounces+mrella=catce...@lists.mozilla.org en nombre de Erwann Abalea
>> Enviado el: mar 23/08/2011 17:33
>>
>>> The root certificate (EC-ACC) has a negative serial number. EE:2B:3D:EB:D4:21:DE:14:A8:62:AC:04:F3:DD:C4:01 is used, without the prefixing 00 to make it positive. The numerical value is -11D4C2142BDE21EB579D53FB0C223BFF in hex, and this is not allowed by RFC2459 and its successors.
>
>> *** We agree with that point, since 2002 the RFC 3280 and later RFC 5280 force CAs not to issue negative numbers. The fact is that our root CA created in 2003 is not accomplishing that point because in design time was used the RFC2459 that didn't have this requirement about serial numbers.
>
> You're right, RFC2459 didn't enforce non-negative serial numbers. But I doubt you really choosed to specify such a large negative number. That's only a guess, but I think you generated some random bytes (maybe the result of a hash), and considered the serial number as an octet string.
>
Yes, the serial number was generated by HSM functions in an aleatory
way, and it was in result a negative number. We will solve this with the
new SHA-256 hierarchy, verifiying serial generated numbers are positive
numbers.
>>> It also has a specific certificatePolicy (useless in a root): 1.3.6.1.4.1.15096.1.3.1.10
>>>
>>> The certificate EC-UR has a different OID in its certificatePolicies extension: 1.3.6.1.4.1.15096.1.3.1.12
>>
>> *** The OID map was created following the RFC2459 that doesn't restrict the OIDs generated by a subordinated CA. As before, we will apply this requirement in the new SHA-256 hierarchy and hope this will not be a blocking point.
>
> RFC2459 didn't, but the X.509 standard, since its 2000 edition, does:
> "The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this
> certificate may be valid." (text taken from the 200/03 edition).
>
Yes, we will solve it in the new hierarchy, arranging OIDs or deleting
them, the standard says that :
"This extension may, at the option of the certificate issuer, be either
critical or non-critical.If the extension is flagged non-critical, use
of this extension does not necessarily constrain use of the certificate
to the policies listed."
In our case it is flag as non-critical and should not lead to problems.
Nowadays we have not detected problems with any validation system by
this issue.
>>> It also has a userNotice policyQualifier encoded in visibleString, with an 8bits variant. Accented characters may not display correctly depending on the client settings.
>>
>> *** This is a known issue for us, we codify with PrintableString/teletexstring when it should be UTF-8, this was an ancient requirement (about 2004) of the systems of the "Agencia Tributaria" of Spain -> "Taxes Agency of Spain" for its internal compatibility with de hierarchy certificates. We are going to ask again to that Agency about the need of that requirement nowadays, and in function of his answer unify all to UTF-8 in the new SHA-2 hierarchy.
>
> You're not using T61String here, but VisibleString, which doesn't allow you to tell which encoding variant was used (the relying party must guess it).
>
> Please tell them that T.61, the base standard for T61String/TeletexString, has been withdrawn years ago (the 1993 edition has never been published, the 1988 was declared obsolete, we can think the whole T.61 has been withdrawn around 1993).
>
Ok, we will ask them for the possibility of update to UTF-8, and if the
answer is yes, we will update it on the new SHA-2 hierarchy.
>>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>>
>> *** Yes, this is nowadays functionality, we are planning to simplify this attribute and leave only the keyId in the new SHA-2 hierarchy and in the final certificates issued by this.
>
> It's listed on http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html as a possible reason to reject the inclusion of the root certificate.
>
This is true but in fact we haven't get any problems about that, and we
hope no to be a blocking point since we will solve it in the next
SHA-256 hierarchy.
>>> The OCSP responder for EC-UR has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, which is not among the policy OIDs allowed to EC-UR by EC-ACC.
>>> It also has both keyId and issuer+serial elements in its authorityKeyIdentifier extension.
>>> The certificate delivered to the test site seuelectronica.upc.edu has a certificatePolicy OID 1.3.6.1.4.1.15096.1.3.1.19, again not among the policy OIDs allowed to EC-UR by EC-ACC.
>>
>> *** Same explanation as before, we based the initial implementation in RFC2459.
>>
>>
>>> It also has T61String elements in the subject field (deprecated long ago for interoperability reasons),
>>
>> *** Same explanation as before about the compatibility with "Agencia Tributaria".
>>
>>> and a jurisdictionOfIncorporationCountryName element which does not use the standard 2-letter country code format.
>>
>> *** Yes this is a buggy implementation, we must validate that this attribute complies with the 3166 ISO as the country (C) attribute already does, we are going to implement as soon as possible (before september ends) the code that controls that issue to avoid problems.
>
> If you're not applying for EV, why are you inserting these fields? Do you have legal requirements to do so?
This was a requirement of the profile requirements defined by the
Industry Ministery group, that defines some standard fields for all the
government CAs in Spain to improve interoperability.
Anyway we are going to solve the problem with this field in september
and we will inform then.
>
>>> It also has an empty dNSName in the subjectAltName extension, and invalid characters in this same extension (DirName with PrintableString elements with 8-bits characters).
>>
>> *** We are going to investigate why dNSName has a blank character when it should not, and in which cases this bug is produced, it will be resolved also before september ends.
>
> It's not a blank character, it's an empty value (length=zero).
Ok we will look at that, we are going to solve the problem in september
and we will inform then.
Manuel Rella Ruiz
> Le lundi 29 août 2011 11:02:42 UTC+2, Erwann Abalea a écrit :
>> Le dimanche 28 août 2011 10:27:56 UTC+2, [sans nom] a écrit :
>>> In the CA Hierarchy it is said EC-idCAT only issue SSL certificate for
>>> www.idcat.cat domain, but if I'm right OCSP does not work for this EC.
Yes, the only SSL certificate issued by the CA: EC-idCAT is the one used
at www.idcat.cat domain. In fact we planned to resolve this problem
making the next certificate for this domain generated from the CA:
EC-SAFP, instead of EC-idCAT, so the EC-SAFP doesn't have the OCSP
problem that you are reporting. In this way, EC-idCAT will only issue
personal certificates to citizens but not SSL certificates. If this is
critical for you, we can try to advance the issuer change of the SSL
domain certificate of www.idcat.cat.
>>
>> The OCSP Responder used to validate the www.idcat.cat certificate is not signed by the same CA (www.idcat.cat certificate is signed by EC-IDCat which in turn is signed by EC-ACC, this OCSP responder is directly signed by EC-ACC).
>> This is not valid.
>
> It should have been solved in november 2010. Maybe you solved the problem for http://ocsp.catcert.cat but not for its "https" counterpart?
Yes this is the issue, but our first intention is to resolve the problem
with the explained in the previous answer.
>
> Anyway, the OCSP service doesn't work with GET requests either. That means that for Windows-based browsers (IE, Safari on Win, Chrome on Win), Mac-based browsers (Safari on Mac, Chrome on Mac), and Opera, the OCSP request is performed, a bad answer is received, and the CRL is finally downloaded.
> That also means it prevents Mozilla products to switch to GET-type requests (a wanted feature) in order to benefit from cache strategies.
We have already reported this problem to the product developer
(Safelayer) but we have notice that the problem is in fact in the web
frontals apache configuration, our operations area is investigating why.
We will report you as soon as the problem is resolved.
Manuel Rella Ruiz
> Auditory company should be penalized
> Auditory reports should be more rigorous
We are still avaluating this problem to get all information around it,
we hope to answer soon.
Manuel Rella Ruiz
certificates, the results by CA are:
* EC-AL:
--------
-17 active certificates issued to internal government domains not
following FQDN syntax.
-5 active certificates issued to internal government domains no public
ones but following FQDN syntax (but with not public tld)
-5 active certificates issued to external IPs of government systems.
* EC-SAFP:
----------
-3 active certificates issued to internal government domains not
following FQDN syntax
-82 active certificates issued to internal government domains no public
ones but following FQDN syntax (but with not public tld): most of them
for the same organization: Generalitat de Catalunya (the regional
government in Catalonia)
-5 active certificates issued to external IPs of government systems
* EC-PARLAMENT:
---------------
-1 active certificates issued to internal government domains not
following FQDN syntax
* EC-UR:
--------
-1 active certificates issued to internal government domains not
following FQDN syntax
-2 active certificates issued to internal IPs
* ER-URV:
--------
-1 active certificates issued to internal government domains not
following FQDN syntax
* EC-idCAT:
-----------
-no problems of that kind
We have a document with the detail of each one of these certificates and
we can pass it in “private” mode to a Firefox responsible.
In all cases we have validated we have in our archive the legal request
documentation, so we have the proof about the use of these certificates
for a very clear defined administration and responsible.
These certificates were issued before the implantation of EV controls
this year and we have now to define if we will allow future internal
domain certificates or not, (for EV certificates is clear they must be
public registered domain). We know internal domains are considered not a
good practice by Firefox, but it the other hand it seems that internal
domains certificates are useful and necessary for our clients.
Our main preoccupation know is find a solution to the 82 certificates
issued by EC-SAFP to the Generalitat of Catalonia, because most of them
are destined to internal critical systems: as the internal mail system
of all Generalitat, and many corporative internal intranets (fyi all
these domains have the sintax: <xxxx>.<yyyy>.INTRANET). So before
contacting them to explain the situation, we would like to know
certainly if maintaining active the certificates of these internal
domains for this particular organization is a blocking issue to include
our root in Firefox. In fact the probability of risk to the Firefox
public users is very low with these concrete 82 certificates, because
they are used in the Generalitat internal networks that are not open to
public citizens, but only to administration workers in a controlled
environment.
We are also open to sign an specific agreement for assuming the
responsibility of any incident about these certificates.
Comments and constructive suggestions will be helpful for us to find a
common solution for these certificates.
Manuel Rella
>> Anyway, the OCSP service doesn't work with GET requests either. That
>> means that for Windows-based browsers (IE, Safari on Win, Chrome on
>> Win), Mac-based browsers (Safari on Mac, Chrome on Mac), and Opera,
>> the OCSP request is performed, a bad answer is received, and the CRL
>> is finally downloaded.
>> That also means it prevents Mozilla products to switch to GET-type
>> requests (a wanted feature) in order to benefit from cache strategies.
>
> We have already reported this problem to the product developer
> (Safelayer) but we have notice that the problem is in fact in the web
> frontals apache configuration, our operations area is investigating why.
> We will report you as soon as the problem is resolved.
>
We have already solved the problem of GET requests, now the OCSP is
responding to them. We have also seen an increment of this kind of
requests and we will monitorize the server to see the impact in its
performance.
In relation to our OCSP server and the DigiNotar attack, we are also
evaluating the technical changes to use the white list of valid
certificates for generating the OCSP answers instead the use of CRL.
We keep working in all the other issues detected by the community and we
will inform about their status.
Manuel Rella
working on an extra TLD control list to limit the use of internal
domains to a very few internal extensions (very used by our main
clients: the catalonian government):
..intranet
..gencat
..local
It's not a perfect practice but it is a better policy than allowing all
internal extensions.
We are also working to add to the list of forgiven domains not only the
phishing list but also alexa 1000, in order to require an extra control
to issue that kind of certificates.
(and for your information, we have decided to issue the future EV
certificates only from the registry entity at central office of
CATCert to reduce issuance risk).
Eddy Nigg
> ...intranet
> ...gencat
> ...local
>
Please note that any subscriber and its relying parties that make use of
such names will have no protection whatsoever at the moment. Those
internal names will be most likely disallowed in the future and
apparently there are certain implementations and deployments with the
Windows platform that would make an attack on such networks undetectable.
I suggest to help your government to move away from this practice as
soon as possible instead of prolonging and helping them stay vulnerable.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Erwann Abalea
> We would like to give more information about this issue, we are now
> working on an extra TLD control list to limit the use of internal
> domains to a very few internal extensions (very used by our main
> clients: the catalonian government):
>
> ..intranet
> ..gencat
> ..local
>
> It's not a perfect practice but it is a better policy than allowing all
> internal extensions.
Why isn't the catalonian government using the official ".es" TLD, or at least reserve a ".cat" domain for its own use? ".intranet" and ".gencat" are not reserved TLDs, and can be found in the wild in the future.
Jean-Marc Desperrier
> Why isn't the catalonian government using the official ".es" TLD,
> or at least reserve a ".cat" domain for its own use?
language, so .cat can not be for exclusive use of the Catalonian
autonomous community. See http://en.wikipedia.org/wiki/.cat
http://www.iso.org/iso/country_codes/iso_3166-faqs/iso_3166_faqs_specific.htm
- What is the code for Catalonia in ISO 3166-1?
There is no separate ISO 3166-1 code for Catalonia. It is part of the
Kingdom of Spain and its codes ES, ESP and 724 are also applicable to
Catalonia.
Actually there's the ES-CT code for Catalonia, but I don't believe this
can be registered as a TLD.
Manuel Rella
> On 09/19/2011 04:31 PM, From Manuel Rella:
>> ...intranet
>> ...gencat
>> ...local
>>
>
> Please note that any subscriber and its relying parties that make use of
> such names will have no protection whatsoever at the moment. Those
> internal names will be most likely disallowed in the future and
> apparently there are certain implementations and deployments with the
> Windows platform that would make an attack on such networks undetectable.
>
> I suggest to help your government to move away from this practice as
> soon as possible instead of prolonging and helping them stay vulnerable.
>
security area of the CTTI (CTTI is the information systems public
provider for Generalitat of Catalonia and the owner of the centrals IT
servers of Generalitat) in order to avoid the creation of new
".intranet" domains and to evaluate the transfer of the already ones to
".cat" tld.
We have explained to them that is possible that ICANN opens the public
".intranet" tld, and this is dangerous because for example one bank
could register “geec.intranet" domain that matches with an already
issued certificate, and this could lead to a phishing attack hard to
detect. Now the security area of CTTI will talk to the architecture
area and will leave feedback to us about the possibility and timing to
transfer to “.cat” domains, we hope to have information of that soon.
ianG
>> We would like to give more information about this issue, we are now
>> working on an extra TLD control list to limit the use of internal
>> domains to a very few internal extensions (very used by our main
>> clients: the catalonian government):
>>
>> ..intranet
>> ..gencat
>> ..local
>>
>> It's not a perfect practice but it is a better policy than allowing all
>> internal extensions.
* Catalonia is more or less against ES when it can be, for political
purposes.
* .es is controlled by a slow, expensive domain registrar.
> or at least reserve a ".cat" domain for its own use?
> ".intranet" and ".gencat" are not reserved TLDs, and can be found in the wild in the future.
The protection is more heavily dependent on the security of their
internal situation than certs might usually expect. Which is fine, they
take their risks, and they know their risks.
What is more the point is that in the future, vendors are likely to not
accept any non-public facing domains. They should be warned that this
is the case; they may discover problems and should prepare a new regime.
iang
Eddy Nigg
> ".intranet" tld, and this is dangerous because for example one bank
> could register “geec.intranet" domain that matches with an already
> issued certificate, and this could lead to a phishing attack hard to
> detect.
same *.intranet, *.gencat or *.local from your CA, allowing me to attack
the governmental network or anybody else for that matter.
Erwann Abalea
> On 20/09/11 02:07 AM, Erwann Abalea wrote:
>
> I would speculate that the following:
>
> * Catalonia is more or less against ES when it can be, for political
> purposes.
> * .es is controlled by a slow, expensive domain registrar.
> > or at least reserve a ".cat" domain for its own use?
>
> Reserving a TLD? Too much trouble.
Well, they don't like ".es", they don't like ".cat", and a city has even registered its official domain in the ".gi" (Gibraltar) TLD.
Gibraltar is a member of the United Kingdom, but geographically located in south of Spain.
> > ".intranet" and ".gencat" are not reserved TLDs, and can be found in the wild in the future.
> As long as they know the risk they are taking, it is reasonable, IMO.
> The protection is more heavily dependent on the security of their
> internal situation than certs might usually expect. Which is fine, they
> take their risks, and they know their risks.
> What is more the point is that in the future, vendors are likely to not
> accept any non-public facing domains. They should be warned that this
> is the case; they may discover problems and should prepare a new regime.
Stephen Schultze
> Erwann Abalea wrote:
>> Why isn't the catalonian government using the official ".es" TLD,
>
> It probably doesn't want to.
>
>> or at least reserve a ".cat" domain for its own use?
>
> ..cat already exist, but cat is a ISO 639-2 code for the Catalan
> language, so .cat can not be for exclusive use of the Catalonian
> autonomous community. See http://en.wikipedia.org/wiki/.cat
>
> http://www.iso.org/iso/country_codes/iso_3166-faqs/iso_3166_faqs_specific.htm
My apologies. You may continue to go about your serious discussion.
Jean-Marc Desperrier
domain. You can start teaching your favorite pet now and reserve mču.cat
instead.
Jean-Marc Desperrier
> I don't see that coming. How would my actual Firefox version now that ICANN has created a brand new TLD?
will still be legitimate. It would be rejection by the CAs at the time
they receive the request.
Kathleen Wilson
> CATCert has applied to add the “EC-ACC” root certificate, and turn on
> the websites trust bit.
>
> CATCert is the Catalan Agency of Certification (Agència Catalana de
> Certificació), a public company that serves as the government CA of the
> Region of the Autonomic Community of Catalunya in Spain.
>
> EC-ACC stands for: Entitat de Certificació de l’Agència Catalana de
> Certificació.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=295474
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#CATCert
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=551896
>
> Noteworthy points:
>
> * The primary documents 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
>
> * CA Hierarchy Diagram:
> https://bugzilla.mozilla.org/attachment.cgi?id=379561
>
> * 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).
>
Thank you to all of you who have reviewed and commented on this request
from CATCert to add the “EC-ACC” root certificate, and turn on the
websites trust bit.
Here is a summary of the discussion.
Concerns were raised regarding CATCert’s current EC-ACC root
certificate, and CATCert plans to create a new SHA-256 hierarchy and
address the concerns by:
- Making sure the serial number is not negative
- Restricting OIDs generated by sub-CAs
- Using UTF-8 string, not T61
- Making sure the authority key ID does not include both the key ID and
the issuer's issuer name and serial number
- Complying with 3166 ISO 2-letter country code format
In regards to one of the sub-CAs, a concern was raised about the OCSP
service not working with GET requests. CATCert has resolved the problem.
CATCert performed an investigation of the domains that certs have been
issued for, and provided information about certificates that have been
issued for internal domains.
While the Mozilla CA Certificate Policy does not yet prohibit issuance
of SSL certificates for internal domains, this is considered to be a
potentially problematic practice.
https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
Is this summary complete and accurate? Does anyone have further
constructive feedback or comments to add before I close this discussion?
I propose that we do not include the current EC-ACC root certificate,
but re-consider CATCert's request when the SHA-256 root certificate has
been created. I would summarize the action items and place this request
in the “Responding to First Discussion” list:
https://wiki.mozilla.org/CA:Schedule#CAs_Responding_to_First_Discussion
Then after CATCert completes the action items, I will open a second
round discussion (without having to wait through the discussion queue
again).
https://wiki.mozilla.org/CA:How_to_apply#Response_to_public_discussion
Kathleen
Kyle Hamilton
On Wed, Oct 19, 2011 at 4:37 PM, Kathleen Wilson <kathle...@yahoo.com> wrote:
> Concerns were raised regarding CATCert’s current EC-ACC root certificate,
> and CATCert plans to create a new SHA-256 hierarchy and address the concerns
> by:
> - Making sure the serial number is not negative
> - Restricting OIDs generated by sub-CAs
> - Using UTF-8 string, not T61
> - Making sure the authority key ID does not include both the key ID and the
> issuer's issuer name and serial number
> - Complying with 3166 ISO 2-letter country code format
> In regards to one of the sub-CAs, a concern was raised about the OCSP
> service not working with GET requests. CATCert has resolved the problem.
> CATCert performed an investigation of the domains that certs have been
> issued for, and provided information about certificates that have been
> issued for internal domains.
> While the Mozilla CA Certificate Policy does not yet prohibit issuance of
> SSL certificates for internal domains, this is considered to be a
> potentially problematic practice.
> https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
> I propose that we do not include the current EC-ACC root certificate, but
> re-consider CATCert's request when the SHA-256 root certificate has been
> created. I would summarize the action items and place this request in the
> “Responding to First Discussion” list:
> https://wiki.mozilla.org/CA:Schedule#CAs_Responding_to_First_Discussion
ianG
> Is this summary complete and accurate? Does anyone have further
> constructive feedback or comments to add before I close this discussion?
issues as fairly minor. None of them seem to impact Mozilla public
users more adversely that they are willing to deal with already. Most
of them seem bureaucratic or standards-compliant.
I can't see a reason to block inclusion. Just my 2c.
iang
Manuel Rella
the concerns. Just leave me make a comment about this issue:
- Complying with 3166 ISO 2-letter country code format
We are still working in all these issues, especially in solving all the
concerning to the "problematic practice" of internal certificates: we
are working now in the communication plan to all our clients, in order
to tell them that we will soon centralize the approval of SSL
certificates in our central office. This approval will be done only by
expert personnel, in order to avoid problematic SSL certificates; this
is the same control that we are going to apply for our EV certificates.
The solution of the other items requires the creation of a new
certification hierarchy, that will be done most probably during 2012. It
will be a complex project that could need many months of work.
Of course, we would prefer to get the Firefox recognition as soon as
possible. In fact, we are very nearly to get the Microsoft EV
recognition, during November, and it would be difficult for us to
explain to our clients the reason why we don't have the Firefox
recognition yet.
In order to get your recognition as soon as possible, we could consider
the signing of an agreement between Firefox and CATCert in order to
solve the pending concerns during 2012, which means our assumption of
the responsibility about them, we expect this to be possible.
Kathleen Wilson
> On Wed, Oct 19, 2011 at 4:37 PM, Kathleen Wilson <kathle...@yahoo.com> wrote:
>> and CATCert plans to create a new SHA-256 hierarchy and address the concerns
>> by:
>> - Making sure the serial number is not negative
>
> RFC2459 semantics and doesn't claim strict 3280/5280 support. This does not create
> a technical problem with any released version of Firefox or Thunderbird, and I
> believe that this will never be an issue for Mozilla's userbase. I oppose the
> necessity of this action item, though I do laud the move.
>
>> - Using UTF-8 string, not T61
> conditioning acceptance on this for that reason. If it does not cause Mozilla users
> grief, we should not be worrying about it here. (It's documented, we know about it,
> and the particular consumer of those certificates may not be able to handle that
> eventuality. Do we really need to transitively force another entity to comply
> with (from their viewpoint) arbitrary and capricious demands from a non-state,
> non-citizen entity?)
>
>> issuer's issuer name and serial number
>
>> In regards to one of the sub-CAs, a concern was raised about the OCSP
>> service not working with GET requests. CATCert has resolved the problem.
>
> with cautious optimism about future CA openness.
>
>> issued for, and provided information about certificates that have been
>> issued for internal domains.
>> While the Mozilla CA Certificate Policy does not yet prohibit issuance of
>> SSL certificates for internal domains, this is considered to be a
>> potentially problematic practice.
>> https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
>
> see a problem. Those customers should by this time understand why and
> how they're vulnerable, and those certificates will expire over time.
>
As Kyle pointed out, the "valid" issues can be addressed as new
intermediate and end-entity certificates are issued.
Therefore, if there are no other concerns, then I propose that CATCert's
current EC-ACC root certificate be approved for inclusion. Before
inclusion, I believe that CATCert should update the CP and/or DPC
documents accordingly to indicate how the concerns will be resolved as
new intermediate and end-entity certificates are issued.
As Manuel has stated, CATCert plans to create a new SHA-256 hierarchy
which will address the other concerns that were raised. Creation and
inclusion of that root would be tracked separately.
Kathleen
Manuel Rella
concerns and put it in our public procedures.
As advance, instead of creating a new hierarchy from the scratch, we are
now evaluating the possibility of doing a "quick clonation" of all the
CATCert hierarchy, this is maintaining the same 2048 RSA keys but
reissuing new CA certificates with the solution for the profile
concerns, and including adaptation to SHA-256.
Manuel Rella
we have putted all the pending items at the public general certification
policy (the document over all the specific CPS).
You can find the spanish version at the public URL (pages 89-90):
http://www.catcert.cat/descarrega_cas/oficina_politicas/D1111_N-PGDC_v3r6_cas.pdf
And the catalan one in (pages 90-91):
http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-PGDC_v3r6_cat.pdf
They are redacted in a very general way (because the public general
certification policy is a high level document) but we expect this to be
enough.
Thank you,
Manuel
Manuel Rella
for it.
Kathleen Wilson
>> we have putted all the pending items at the public general certification
>> policy (the document over all the specific CPS).
>>
>> You can find the spanish version at the public URL (pages 89-90):
>> http://www.catcert.cat/descarrega_cas/oficina_politicas/D1111_N-PGDC_v3r6_cas.pdf
>>
>> And the catalan one in (pages 90-91):
>> http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-PGDC_v3r6_cat.pdf
>>
>> They are redacted in a very general way (because the public general
>> certification policy is a high level document) but we expect this to be
>> enough.
>>
>> Thank you,
>> Manuel
>
> I forgot! if you need some "manual" transtation don't hesitate to ask
> for it.
Thanks,
Kathleen
Manuel Rella
7 Profiles of certificates and certificate revocation lists
[………]
7.1 Certificate profiles
[………]
7.1.10 Specifications for all Certification Entities
Certificate authorities must respect the technological generally
accepted uses, and "must" adapt to best practices and most advanced
technical requirements.
Additionally, the renewal of certificate authorities immediately after
this version of the General Policy must comply with the following
technical specifications:
- The algorithm used should be subject to renewal if there is a risk
decryption warned by the community. The Certification Entities after
this General Policy, will be renewed with the algorithm SHA-256.
- The serial numbers of the certificates must be generated in any case
in positive.
- The used codification will be UTF-8.
- The "extension" authorityKeyIdentifier" will be simplified.
- The OIDs generated by certificate intermediate authorities will be
restricted.
----------
Best regards,
Manuel
Kathleen Wilson
> Al 07/11/2011 20:24, En/na Kathleen Wilson ha escrit:
>> On 11/7/11 7:56 AM, Manuel Rella wrote:
>>>> we have putted all the pending items at the public general
>>>> certification
>>>> policy (the document over all the specific CPS).
>>>>
>>>> You can find the spanish version at the public URL (pages 89-90):
>>>> http://www.catcert.cat/descarrega_cas/oficina_politicas/D1111_N-PGDC_v3r6_cas.pdf
>>>>
>>>> And the catalan one in (pages 90-91):
>>>> http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-PGDC_v3r6_cat.pdf
>>>>
>>>> They are redacted in a very general way (because the public general
>>>> certification policy is a high level document) but we expect this to be
>>>> enough.
>>>>
>>>> Thank you,
>>>> Manuel
>>>
>> sections.
>
> [………]
> 7.1 Certificate profiles
> [………]
> 7.1.10 Specifications for all Certification Entities
>
> Certificate authorities must respect the technological generally
> accepted uses, and "must" adapt to best practices and most advanced
> technical requirements.
>
> Additionally, the renewal of certificate authorities immediately after
> this version of the General Policy must comply with the following
> technical specifications:
>
> - The algorithm used should be subject to renewal if there is a risk
> decryption warned by the community. The Certification Entities after
> this General Policy, will be renewed with the algorithm SHA-256.
>
> - The serial numbers of the certificates must be generated in any case
> in positive.
>
> - The used codification will be UTF-8.
>
> - The "extension" authorityKeyIdentifier" will be simplified.
>
> - The OIDs generated by certificate intermediate authorities will be
> restricted.
>
> ----------
>
> Best regards,
> Manuel
>
Spanish: http://www.catcert.cat/web/cas/5_1_politica_general.jsp
Link called "Política General de Certificación"
Catalan: http://www.catcert.cat/web/cat/5_1_politica_general.jsp
Link called "Política general de Certificació"
I believe these changes address the concerns that have been raised in
this discussion.
Kathleen
Kathleen Wilson
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion was in regards to the request from CATCert to add the
“EC-ACC” root certificate and turn on the websites trust bit.
During the course of this discussion some recommendations were made
regarding using positive serial numbers, using UTF-8, simplifying the
authorityKeyIdentifier, and restricting the OIDS generated by subCAs.
These were addressed with an update to the CP that indicates related
technical specifications that the certificate authorities must comply
with upon renewal.
CATCert plans to create a new SHA-256 hierarchy in 2012. Creation and
inclusion of the new root will be tracked separately.
I will post a summary of the request and my recommendation for approval
in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=295474
I am now closing this discussion. Any further follow-up on this request
should be added directly to the bug.
Thanks,
Kathleen