Camerfirma Root Inclusion Request
Kathleen Wilson
in Spain) has applied to add two root certificates: �Chambers of
Commerce Root � 2008� and �Global Chambersign Root � 2008�. The request
is to enable all three trust bits for both roots. The request is to also
enable EV for both roots.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=406968
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Camerfirma
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=426075
Noteworthy points:
* There is a �Chambers of Commerce Root� root certificate currently
included in NSS, which is SHA1 2048-bit. This new �Chambers of Commerce
Root � 2008� root is SHA1 4096-bit.
* The �Chambers of Commerce Root � 2008� root will have
internally-operated subordinate CAs: Express Corporate Server for SSL
certificates; Corporate Server EV; CodeSign; TSA for Time Stamping
process that issues TSU certificates; and AC Camerfirma, Certificados
Camerales which issues certificates for end entities (Enterprise
certificates for employees and representatives).
** Chambers of Commerce act as RAs for end user registration.
* There is a �Global Chambersign Root� root certificate currently
included in NSS, which is SHA1 2048-bit. This new �Global Chambersign
Root � 2008� root is SHA1 4096-bit.
* The �Global Chambersign Root � 2008� root will have
internally-operated subordinate CAs that issue certificates for general
use globally. There is currently an intermediate CA called AC Camerfirma
which signed a sub-CA called RACER. This 2nd level Intermediate CA
issues certificates for citizens and enterprise employees and
representatives.
** Other companies act as RAs for end user registration.
* The CP and CPS documents are in Spanish. Translations of sections of
the documents have been provided and are included in the Information
Gathering document.
CPS: http://policy.camerfirma.com/politicas/CPS_V_3.1.4.pdf
CP Server EV:
http://www.camerfirma.com/mod_web/usuarios/pdf/PC_Camerfirma_Corporate_Server_EV_1_0.pdf
* The request is to enable all three trust bits for both roots.
** CPS section 3.1.8: To make a correct identification of the identity
of the subscriber, RA requires:
*** The appointed applicant's physical and presentation of their
National Identity, passport or residence.
*** Identification of the company, for which the required documentation
RA relevant depending on the type of entity. This information is
included in the Operating manuals of RA.
*** Documentation proving the link or the ability to represent the
Signer / Subscriber in respect of the entity. The certificate of legal
person, where the signer / subscriber and the applicant must demonstrate
distinct evidence that the applicant has sufficient powers to make such
license application. In the certificates that describe a relationship RA
representation to generate the necessary evidence to prove that
representation for which use the means necessary in creating the basis
of guidelines set in the LFE including consultation to public records.
This information is included in the operational manuals of RA.
*** To secure server certificates, the subscriber identity is verified
through access to databases of Internet domains and the certificates are
delivered to the authorities who appear in those databases. In the case
of secure server certificates AC Camerfirma only receives request in
PKCS # 10 format of the applicant.
*** For code-signing certificates require identifying Camerfirma the
company that issued the certificate and its representative on the terms
before described in this paragraph and except as incorporated in the
operating manuals of RA.
*** The encryption certificates will be issued automatically presenting
a valid identity certificate.
** For signing end user certificates physical presence is required, id
card and an authorisation of a enterprise representative. All other
communications are made by means of email.
** From the RA Operating Manual (internal document, but included in audits)
*** Before approve the request RA must be assured of the organization
existence, by means of one of these methods: Spanish Administration TAX
Data Base, Chambers of Commerce Data Base, Spanish Companies Register
Data Base.
*** Be assured that the domain exists and is linked with the
organization previously verified consulting the Internet Domain Data
Bases: http://www.networksolutions.com, http://www.gandi.net,
http://www.interdomain.com, http://www.nic.es, or http://www.nominalia.com
* The request is to also enable EV for both roots.
** CP Server EV CP Section 1.2: AC Camerfirma is in accordance with
current versions of "CA / Browser Forum Gidelines for Issuance and
Management of Extended Validation certificates "published in
http://www.cabforum.org.
** CP Server EV Section 4.1: The CA shall ensure that:
*** The existence of the organization, through access to public records
or owners.
*** Checking the identity of the applicant or person authorized by
supporting evidence. The documentation will be delivered in person in an
AC Camerfirma registration office. Physical presence could be
substituted for an online application signed with a valid and recognized
certificate and for those other options approved by the current legislation.
*** That the organization has the control in the uses of the domain
through consultation in the registries of domain.
* EV Policy OID:
** Chambers of Commerce Root � 2008: 1.3.6.1.4.1.17326.10.14.2.*.*
** Global Chambersign Root � 2008: 1.3.6.1.4.1.17326.10.8.12.*.*
*** The last 2 digits are used for identify the Private Key management,
and can be 1.2 or 2.2:
**** 1.2 Private key generated stored in a software device and generated
by the User
**** 2.2 Private key generated stored in a SSCD device and generated by
the User
* Test Websites:
** Chambers of Commerce Root � 2008: https://server1.camerfirma.com:8081/
** Global Chambersign Root � 2008: https://server2.camerfirma.com:8082/
* CRL:
** Chambers of Commerce Root � 2008 ARL:
http://crl.camerfirma.com/root_chambers_2008.crl
** End-entity CRL for server certs:
http://crl.camerfirma.com/camerfirma_cserver-2009.crl
** Global Chambersign Root � 2008 ARL:
http://crl.camerfirma.com/root_chambersign_2008.crl
** End-entity CRL for server certs: http://crl.camerfirma.com/racer-2009.crl
** NextUpdate for the end-entity CRLs for both roots is currently 3
months. �at the moment these CAs are not issuing certificates so we keep
a CRL for 3 months, when we begin to issue certificates we will issue a
daily CRL.�
** CP Server EV section 4.5.8: The CA will publish and update the CRL at
least once weekly and keeping it published for 10 days.
* OCSP: http://ocsp.camerfirma.com
** CP Server EV section 4.5.10 This service will be updated at least
every 4 days. The OCSP responses to this service should have a valid
period of 10 days.
* Audit: Camerfirma is audited by Ernst & Young according to the
WebTrust CA and WebTrust EV criteria. The WebTrust CA audit report from
the end of 2008 is posted on the webtrust.org website
(https://cert.webtrust.org/ViewSeal?id=874). The WebTrust EV audit that
was completed in 2009 was provided by Camerfirma. I exchanged email with
the auditor at Ernst & Young, and the auditor confirmed that the
WebTrust EV audit statement is authentic and that it covers these two roots.
This begins a one-week discussion period. After that week, 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
Kathleen Wilson
Would at least two people please review and comment on this request?
Information about what reviewers should look for is available here:
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
I will greatly appreciate your help in reviewing this request so that we
can make further progress in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Kathleen
Eddy Nigg
> All,
>
> Would at least two people please review and comment on this request?
>
By browsing through this request I believe there will be a couple of
questions. But I can't promise to make it before the weekend :-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
chemalogo
> All,
>
> Would at least two people please review and comment on this request?
>
> Information about what reviewers should look for is available here:https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
>
> I will greatly appreciate your help in reviewing this request so that we
> can make further progress in the queue for public discussion:https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
>
> Kathleen
>
> On 2/12/10 10:51 AM, Kathleen Wilson wrote:
>
> > Camerfirma (a Regional CA in Spain, and the CA for Chambers of Commerce
> > Commerce Root – 2008” and “Global Chambersign Root – 2008”. The request
> > is to enable all three trust bits for both roots. The request is to also
> > enable EV for both roots.
>
> > The request is documented in the following bug:
> >https://bugzilla.mozilla.org/show_bug.cgi?id=406968
>
> > And in the pending certificates list here:
> >http://www.mozilla.org/projects/security/certs/pending/#Camerfirma
>
> > Summary of Information Gathered and Verified:
> >https://bugzilla.mozilla.org/attachment.cgi?id=426075
>
> > Noteworthy points:
>
> > included in NSS, which is SHA1 2048-bit. This new “Chambers of Commerce
> > Root – 2008” root is SHA1 4096-bit.
> > * The “Chambers of Commerce Root – 2008” root will have
> > internally-operated subordinate CAs: Express Corporate Server for SSL
> > certificates; Corporate Server EV; CodeSign; TSA for Time Stamping
> > process that issues TSU certificates; and AC Camerfirma, Certificados
> > Camerales which issues certificates for end entities (Enterprise
> > certificates for employees and representatives).
> > ** Chambers of Commerce act as RAs for end user registration.
>
> > included in NSS, which is SHA1 2048-bit. This new “Global Chambersign
> > Root – 2008” root is SHA1 4096-bit.
> > * The “Global Chambersign Root – 2008” root will have
> > internally-operated subordinate CAs that issue certificates for general
> > use globally. There is currently an intermediate CA called AC Camerfirma
> > which signed a sub-CA called RACER. This 2nd level Intermediate CA
> > issues certificates for citizens and enterprise employees and
> > representatives.
> > ** Other companies act as RAs for end user registration.
>
> > * The CP and CPS documents are in Spanish. Translations of sections of
> > the documents have been provided and are included in the Information
> > Gathering document.
> > CPS:http://policy.camerfirma.com/politicas/CPS_V_3.1.4.pdf
> > CP Server EV:
>
> > * The request is to also enable EV for both roots.
> > ** CP Server EV CP Section 1.2: AC Camerfirma is in accordance with
> > current versions of "CA / Browser Forum Gidelines for Issuance and
> > Management of Extended Validation certificates "published in
> >http://www.cabforum.org.
> > ** CP Server EV Section 4.1: The CA shall ensure that:
> > *** The existence of the organization, through access to public records
> > or owners.
> > *** Checking the identity of the applicant or person authorized by
> > supporting evidence. The documentation will be delivered in person in an
> > AC Camerfirma registration office. Physical presence could be
> > substituted for an online application signed with a valid and recognized
> > certificate and for those other options approved by the current
> > legislation.
> > *** That the organization has the control in the uses of the domain
> > through consultation in the registries of domain.
>
> > * EV Policy OID:
> > ** Global Chambersign Root – 2008: 1.3.6.1.4.1.17326.10.8.12.*.*
> > *** The last 2 digits are used for identify the Private Key management,
> > and can be 1.2 or 2.2:
> > **** 1.2 Private key generated stored in a software device and generated
> > by the User
> > **** 2.2 Private key generated stored in a SSCD device and generated by
> > the User
>
> > * Test Websites:
> > ** Global Chambersign Root – 2008:https://server2.camerfirma.com:8082/
>
> > * CRL:
> > ** Chambers of Commerce Root – 2008 ARL:
> >http://crl.camerfirma.com/root_chambers_2008.crl
> > ** End-entity CRL for server certs:
> >http://crl.camerfirma.com/camerfirma_cserver-2009.crl
> >http://crl.camerfirma.com/root_chambersign_2008.crl
> > ** End-entity CRL for server certs:
> >http://crl.camerfirma.com/racer-2009.crl
> > ** NextUpdate for the end-entity CRLs for both roots is currently 3
> > a CRL for 3 months, when we begin to issue certificates we will issue a
> > ** CP Server EV section 4.5.8: The CA will publish and update the CRL at
> > least once weekly and keeping it published for 10 days.
>
> > * OCSP:http://ocsp.camerfirma.com
> > ** CP Server EV section 4.5.10 This service will be updated at least
> > every 4 days. The OCSP responses to this service should have a valid
> > period of 10 days.
>
> > * Audit: Camerfirma is audited by Ernst & Young according to the
> > WebTrust CA and WebTrust EV criteria. The WebTrust CA audit report from
> > the end of 2008 is posted on the webtrust.org website
> > (https://cert.webtrust.org/ViewSeal?id=874). The WebTrust EV audit that
> > was completed in 2009 was provided by Camerfirma. I exchanged email with
> > the auditor at Ernst & Young, and the auditor confirmed that the
> > WebTrust EV audit statement is authentic and that it covers these two
> > roots.
>
> > This begins a one-week discussion period. After that week, 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
>
>
I have reviewed the information above and cannot see any concerns. I
am an independent technical (CISA #) auditor in Spain and know very
well the activity of the main Certification Services Providers (CSP)
in Spain.
Camerfirma is one of the first CSP that initiated its activity years
ago and I've been lucky enough to visit its data processing center at
different times, as auditor for a regional agency which performs CSP
rating to include in a list of trustworthy CSP to make transactions
among citizens and regional goverment.
From my point of view Camerfirma is an entity in meeting more
stringent standards without ignoring the business point of view.
Jean-Marc Desperrier
> ** From the RA Operating Manual (internal document, but included in audits)
> *** Before approve the request RA must be assured of the organization
> existence, by means of one of these methods: Spanish Administration TAX
> Data Base, Chambers of Commerce Data Base, Spanish Companies Register
> Data Base.
The first and the third can only authenticate spanish companies, right ?
Is the second cross-european ?
Jean-Marc Desperrier
> * There is a �Chambers of Commerce Root� root certificate currently
> included in NSS, which is SHA1 2048-bit. This new �Chambers of Commerce
> Root � 2008� root is SHA1 4096-bit.
I'm not convinced it make much sense to update a 2048-SHA1 root to a
4096-SHA1 root.
They are quite good reason to believe than the time where withdrawal of
the use of SHA1 algorithm will strongly recommended will come earlier,
certainly not later than the equivalent recommendation for a 2048 RSA
key size.
Let's send the right message, the weakest part of a SHA1-2048 RSA key is
SHA1, not 2048 RSA (*). So a 4096-SHA1 root brings nothing above a
2048-SHA1 root.
Therefore I believe that Mozilla should have a policy of not allowing
such an update for an existing key.
This being said, given that such a policy if adopted, was not in
existence when Camerfirma filled it's request and when it was initially
processed, I'm not of the opinion this should have any consequence over
the approval of Camerfirma's request.
(*) Please understand me correctly, I'm not saying SHA1 is really weak,
and I certainly believe for example that updating from 1024-SHA1 to
2048-SHA1 would be a strong security gain.
Nelson Bolyard
> Kathleen Wilson wrote:
>> included in NSS, which is SHA1 2048-bit. This new “Chambers of Commerce
>> Root – 2008” root is SHA1 4096-bit.
>
> I'm not convinced it make much sense to update a 2048-SHA1 root to a
> 4096-SHA1 root.
Cryptographically, it doesn't. But I think you'll find the CAs will argue
that it also doesn't make sense to upgrade to a hash algorithm that is not
supported in Windows XP. The problem (as I understand it) is that WinXP
supports RSA including large key sizes but doesn't support SHA2. So, CAs
are free to lengthen RSA key sizes, but feel they are not free to use SHA2.
CAs won't take actions that exclude WinXP IE users. :-/
> Let's send the right message, the weakest part of a SHA1-2048 RSA key is
> SHA1, not 2048 RSA (*). So a 4096-SHA1 root brings nothing above a
> 2048-SHA1 root.
>
> Therefore I believe that Mozilla should have a policy of not allowing
> such an update for an existing key.
IF the browser makers can agree, as a group, to disallow signatures with
such a combination of key and hash, then I would agree Mozilla should agree
to it. Perhaps Mozilla should suggest that in the CA-Browser forum. But
for Mozilla to unilaterally say "WE will not accept certs with such a
signature combination" may only serve to exclude Mozilla products from
certain markets.
> This being said, given that such a policy if adopted, was not in
> existence when Camerfirma filled it's request and when it was initially
> processed, I'm not of the opinion this should have any consequence over
> the approval of Camerfirma's request.
>
> (*) Please understand me correctly, I'm not saying SHA1 is really weak,
> and I certainly believe for example that updating from 1024-SHA1 to
> 2048-SHA1 would be a strong security gain.
--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
Jean-Marc Desperrier
> you'll find the CAs will argue
> that it also doesn't make sense to upgrade to a hash algorithm that is not
> supported in Windows XP.
Of course ! But there's no reason to let them plunge into the warm,
fuzzy feeling of having done something to enhance the security of their
users when they actually didn't.
BTW, SHA2 is supported by Windows XP SP3.
> IF the browser makers can agree, as a group, to disallow signatures with
> such a combination of key and hash, then I would agree Mozilla should agree
> to it. Perhaps Mozilla should suggest that in the CA-Browser forum. But
> for Mozilla to unilaterally say "WE will not accept certs with such a
> signature combination" may only serve to exclude Mozilla products from
> certain markets.
I was only talking about *upgrading* an *existing* CA, this means a CA
that's already included in Mozilla.
What about adding it to problematic practices ?
Ramiro Muñoz Muñoz
Only Spanish Companies registration.
We are focus on spanish market so far.
Regards
Ramiro Muñoz Muñoz
> > included in NSS, which is SHA1 2048-bit. This new “Chambers of Commerce
>
> I'm not convinced it make much sense to update a 2048-SHA1 root to a
> 4096-SHA1 root.
>
> They are quite good reason to believe than the time where withdrawal of
> the use of SHA1 algorithm will strongly recommended will come earlier,
> certainly not later than the equivalent recommendation for a 2048 RSA
> key size.
>
> Let's send the right message, the weakest part of a SHA1-2048 RSA key is
> SHA1, not 2048 RSA (*). So a 4096-SHA1 root brings nothing above a
> 2048-SHA1 root.
>
> Therefore I believe that Mozilla should have a policy of not allowing
> such an update for an existing key.
>
> This being said, given that such a policy if adopted, was not in
> existence when Camerfirma filled it's request and when it was initially
> processed, I'm not of the opinion this should have any consequence over
> the approval of Camerfirma's request.
>
> (*) Please understand me correctly, I'm not saying SHA1 is really weak,
> and I certainly believe for example that updating from 1024-SHA1 to
> 2048-SHA1 would be a strong security gain.
Hi Jean-Marc
We have talk interlnally about this issue and we decided to issue a
certificate with a strong RSA key and a SHA-1 hash because OS and
applications compatibility problems, and later we can issue a new
certificate with the same RSA public key and a stronger hash
algorithm.
Eddy Nigg
>
> Would at least two people please review and comment on this request?
Just a few thoughts:
>> *** To secure server certificates, the subscriber identity is verified
>> through access to databases of Internet domains and the certificates are
>> delivered to the authorities who appear in those databases. In the case
>> of secure server certificates AC Camerfirma only receives request in
>> PKCS # 10 format of the applicant.
I'm missing how the domain validation is performed? Please be specific...
>> *** Be assured that the domain exists and is linked with the
>> organization previously verified consulting the Internet Domain Data
>> Bases: http://www.networksolutions.com, http://www.gandi.net,
>> http://www.interdomain.com, http://www.nic.es, or
>> http://www.nominalia.com
Why is this not disclosed in the CP/CPS? This is a core requirement of
the Mozilla CA policy and can't be assumed, it must be disclosed
properly (and audited).
>> * EV Policy OID:
>> ** Chambers of Commerce Root – 2008: 1.3.6.1.4.1.17326.10.14.2.*.*
>> ** Global Chambersign Root – 2008: 1.3.6.1.4.1.17326.10.8.12.*.*
>> *** The last 2 digits are used for identify the Private Key management,
>> and can be 1.2 or 2.2:
I suspect that there might be a technical problem. I suggest to check
with Kai Engert if multiple EV OID entries for the same CA roots are
possible. It might be not possible with the current implementation.
>> **** 1.2 Private key generated stored in a software device and generated
>> by the User
>> **** 2.2 Private key generated stored in a SSCD device and generated by
>> the User
>>
>> * Test Websites:
>> ** Chambers of Commerce Root – 2008:
>> https://server1.camerfirma.com:8081/
>> ** Global Chambersign Root – 2008: https://server2.camerfirma.com:8082/
The sites are off-line, doesn't work.
>>
>> * OCSP: http://ocsp.camerfirma.com
>> ** CP Server EV section 4.5.10 This service will be updated at least
>> every 4 days. The OCSP responses to this service should have a valid
>> period of 10 days.
I couldn't test OCSP because the above sites don't work.
Ramiro Muñoz Muñoz
> On 02/22/2010 11:32 PM, Kathleen Wilson:
>
> > All,
>
> > Would at least two people please review and comment on this request?
>
> Just a few thoughts:
>
> >> *** To secure server certificates, the subscriber identity is verified
> >> through access to databases of Internet domains and the certificates are
> >> delivered to the authorities who appear in those databases. In the case
> >> of secure server certificates AC Camerfirma only receives request in
> >> PKCS # 10 format of the applicant.
>
> I'm missing how the domain validation is performed? Please be specific...
>
> >> *** Be assured that the domain exists and is linked with the
> >> organization previously verified consulting the Internet Domain Data
> >> Bases:http://www.networksolutions.com,http://www.gandi.net,
> >>http://www.nominalia.com
>
> Why is this not disclosed in the CP/CPS? This is a core requirement of
> the Mozilla CA policy and can't be assumed, it must be disclosed
> properly (and audited).
>
OK, I will develop the domain validation process in our CPS. but in a
few worlds :
We get the information from the request doc where the requestors
provide us with the Companie VAT number among other information. We
check that the company exists consulting the Spanish Companies
registration data base matching the VAT number and names.
Then we use the Domain registration services Data Bases and check if
the domain exists and is linked with the requestor company.
This process is expained in an internal document
> >> * EV Policy OID:
> >> ** Chambers of Commerce Root – 2008: 1.3.6.1.4.1.17326.10.14.2.*.*
> >> ** Global Chambersign Root – 2008: 1.3.6.1.4.1.17326.10.8.12.*.*
> >> *** The last 2 digits are used for identify the Private Key management,
> >> and can be 1.2 or 2.2:
>
> I suspect that there might be a technical problem. I suggest to check
> with Kai Engert if multiple EV OID entries for the same CA roots are
> possible. It might be not possible with the current implementation.
>
We use diferent OID to provide information about how and who generate
the keys. If only one OID is allowed we can choose one for each
hierarchy.
> >> **** 1.2 Private key generated stored in a software device and generated
> >> by the User
> >> **** 2.2 Private key generated stored in a SSCD device and generated by
> >> the User
>
> >> * Test Websites:
> >> ** Chambers of Commerce Root – 2008:
> >>https://server1.camerfirma.com:8081/
> >> ** Global Chambersign Root – 2008:https://server2.camerfirma.com:8082/
>
> The sites are off-line, doesn't work.
>
OK, I will have a look on it
>
>
> >> * OCSP:http://ocsp.camerfirma.com
> >> ** CP Server EV section 4.5.10 This service will be updated at least
> >> every 4 days. The OCSP responses to this service should have a valid
> >> period of 10 days.
>
> I couldn't test OCSP because the above sites don't work.
>
I hope these links are working today
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: start...@startcom.org
Kai Engert
> On 1 mar, 04:23, Eddy Nigg <eddy_n...@startcom.org> wrote:
>
> > >> * EV Policy OID:
> > >> ** Chambers of Commerce Root – 2008: 1.3.6.1.4.1.17326.10.14.2.*.*
> > >> ** Global Chambersign Root – 2008: 1.3.6.1.4.1.17326.10.8.12.*.*
> > >> *** The last 2 digits are used for identify the Private Key management,
> > >> and can be 1.2 or 2.2:
>
> > I suspect that there might be a technical problem. I suggest to check
> > with Kai Engert if multiple EV OID entries for the same CA roots are
> > possible. It might be not possible with the current implementation.
I can't speak for the policy point of view, but technically, given a
cert-A, it should work to enable both {cert-A, OID 1} and {cert-A, OID
2} for EV.
If we find that the current code doesn't support it when testing, we
can fix it. However, after having a first look at the code, I think it
will work as is.
We already have scenarios where the same OID is used for multiple
certs, as in: {cert-A, OID 1} and {cert-B, OID 1}.
If I understand correctly, in order to support what you have
described, we would have to add 4 entries, {cert-A, OID-1}, {cert-A,
OID-2}, {cert-B, OID-1}, {cert-B, OID-2}.
It would be preferable to have only one OID for each root. It would
avoid having to bloat our lookup table with multiple entries of your
cert.
Regarding the limitations: If set O is the unified set of all EV OIDs
used by all CAs, we require that any cert contains AT MOST one OID,
only one element of O.
> We use diferent OID to provide information about how and who generate
> the keys. If only one OID is allowed we can choose one for each
> hierarchy.
If you could restrict your environment to {cert-A, OID-1} and {cert-B,
OID-2}, that would be preferable.
Kai
Ramiro Muñoz Muñoz
It would be enough to include two OID for each root:
OID for Chambers of Commerce ROOT 200
1.3.6.1.4.1.17326.10.14.2.1.2 for non SSCD keys and
1.3.6.1.4.1.17326.10.14.2.2.2 for SSCD keys
And for Chambersign Global ROOT 2008
1.3.6.1.4.1.17326.10.8.12.1.2 for non SSCD keys and
1.3.6.1.4.1.17326.10.8.12.2.2 for SSCD keys
if this still is a problem, we would choose the non SSCD keys OID.
Regards
Kathleen Wilson
> in Spain) has applied to add two root certificates: �Chambers of
> Commerce Root � 2008� and �Global Chambersign Root � 2008�. The request
> is to enable all three trust bits for both roots. The request is to also
> enable EV for both roots.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=406968
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Camerfirma
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=426075
>
Thank you to those who have reviewed this root inclusion request from
Camerfirma and contributed to this discussion.
Here is a summary of the items that have been pointed out in this
discussion.
1) Updating 2048-SHA1 root to a 4096-SHA1 root
The point was made that the CA should consider using SHA2 in the new
root, rather than SHA1.
Camerfirma�s representative responded that they did consider this, but
that they still want to have the 4096 SHA1 root.
ACTION: None
2) Domain Validation
Clarification was requested in regards to the procedures for verifying
the ownship/control of the domain name to be included in the
certificate. This information is currently in an internal document. The
information needs to be in a public, audited document, such as the CP/CPS.
ACTION Camerfirma: Update the CP/CPS documents to provide more specific
information about how the domain registration services databases are
used to verify that the certificate subscriber owns/controls the domain
name to be included in the certificate.
3) Multiple EV OID entries for the same root
While this appears to be technically feasible, the recommendation is to
have only one EV OID for each root.
Camerfirma�s representative responded that they would like to use two
specific EV OIDs for each root, but that if actual testing shows that
only one can be supported that they would choose the non SSCD keys OID.
ACTION: None � testing will happen during the inclusion phase, and the
decision will be made based on the testing results.
4) Test sites were temporarily down
They are working now.
Please review this summary to ensure accuracy and completeness, and
respond here if further clarification is needed.
I would like to proceed with this request by asking Camerfirma to
respond to this discussion thread with their proposed changes to their
CP/CPS as per the action item. If no further discussion is needed, then
I will close this discussion and track the actual changes to the CP/CPS
in the bug, and then proceed with approval/inclusion without a second
round of public discussion.
Kathleen
Ramiro Muñoz Muñoz
> On 2/12/10 10:51 AM, Kathleen Wilson wrote:
>
> > Camerfirma (a Regional CA in Spain, and the CA for Chambers of Commerce
> > is to enable all three trust bits for both roots. The request is to also
> > enable EV for both roots.
>
> > The request is documented in the following bug:
> >https://bugzilla.mozilla.org/show_bug.cgi?id=406968
>
> > And in the pending certificates list here:
> >http://www.mozilla.org/projects/security/certs/pending/#Camerfirma
>
> > Summary of Information Gathered and Verified:
> >https://bugzilla.mozilla.org/attachment.cgi?id=426075
>
> Thank you to those who have reviewed this root inclusion request from
> Camerfirma and contributed to this discussion.
>
> Here is a summary of the items that have been pointed out in this
> discussion.
>
> 1) Updating 2048-SHA1 root to a 4096-SHA1 root
> The point was made that the CA should consider using SHA2 in the new
> root, rather than SHA1.
> that they still want to have the 4096 SHA1 root.
>
> ACTION: None
>
> 2) Domain Validation
> Clarification was requested in regards to the procedures for verifying
> the ownship/control of the domain name to be included in the
> certificate. This information is currently in an internal document. The
> information needs to be in a public, audited document, such as the CP/CPS.
>
> ACTION Camerfirma: Update the CP/CPS documents to provide more specific
> information about how the domain registration services databases are
> used to verify that the certificate subscriber owns/controls the domain
> name to be included in the certificate.
>
> 3) Multiple EV OID entries for the same root
> While this appears to be technically feasible, the recommendation is to
> have only one EV OID for each root.
> specific EV OIDs for each root, but that if actual testing shows that
> only one can be supported that they would choose the non SSCD keys OID.
>
> decision will be made based on the testing results.
>
> 4) Test sites were temporarily down
> They are working now.
>
> Please review this summary to ensure accuracy and completeness, and
> respond here if further clarification is needed.
>
> I would like to proceed with this request by asking Camerfirma to
> respond to this discussion thread with their proposed changes to their
> CP/CPS as per the action item. If no further discussion is needed, then
> I will close this discussion and track the actual changes to the CP/CPS
> in the bug, and then proceed with approval/inclusion without a second
> round of public discussion.
>
> Kathleen
Changes in the CPS v 3.2.1
Los certificados de servidor seguro (EV) “extended validation” siguen
las lineas marcadas por “CA/Browser Forum Gidelines for Issuance and
Management of extended validation certificates”. Se realizaran
siguiendo los mismos procedimientos que un certificado de vinculación
empresarial, es decir:
Secure Server Certificates (EV) "extended validation" follow the lines
marked by "CA / Browser Forum Guidelines for Issuance and Management
of extended validation certificates. A similar process for issuing an
AC Camerfirma business certificate will be follow, this means:
1. La personación física del firmante suscriptor, o de un
representante del solicitante en caso de que este sea una entidad
jurídica y la presentación de un documento identificactivo.
The applicant physical presence, or a representative of the applicant
if this is a legal entity and the presentation of an valid
identification will be required by the RA.
2. Identificación de la empresa, para los que la AR requerirá la
documentación pertinente dependiendo del tipo de entidad.
Identification of the company. A specific documentation will be
required by the RA depending on the type of entity.
3. Presentación de una autorización firmada por un representante de la
empresa que actuara como solicitante.
Presentation of an authorization signed by a company representative
who acts as the applicant.
Además de los procesos ya descritos anteriormente para este tipo de
certificados la RA deberá comprobar:
Besides the processes already described above, the RA shall ensure
that:
1. La existencia de la entidad en el registro mercantil.
The existence of the entity in the commercial register.
En caso de que el operador de RA necesite ampliar la información de la
organización incorporada en el certificado, dispondrá de un acceso a
una base de datos de gestión de riesgo empresarial como e-Informa
http://www.einforma.com. Esta base de datos ofrece información del
registro mercantil tanto de las empresas como de sus representantes
incorporando información de riesgo.
If the RA operator needs more information from the organization
incorporated in the certificate, access to a database of enterprise
risk management and e-Reports http://www.einforma.com will be used.
This database provides information from the commercial register about
Spanish companies and their representatives, incorporating risk
information.
La comprobación de que los datos o documentos aportados no tengan una
antigüedad superior a 1 año.
Documents provided will be not older than 1 year.
Consulta de la antigüedad mínima de existencia legal de la
organización de 1 año.
The minimum age of legal existence of the organization will be 1 year.
No emitir certificados a empresas erradicadas en países donde exista
una prohibición gubernamental para hacer negocios.
Not issue certificates to companies eradicated in countries where
governments ban to do business is established.
2. Que el registro del dominio para el que se va a emitir el
certificado existe.
That the registration of the domain for which to issue the certificate
exists
Se utilizaran los servicios de consulta de dominios de https://www.nic.es
cuando los servicios se contraten para un dominio bajo la gestión de
primer nivel “.ES”, y http://www.internic.net/ para el resto de los
dominios de primer nivel.
We used the consulting services domain https: / / www.nic.es when
services are contracted for a domain under the top level management.
"ES" and http://www.internic.net/ for other TLDs
3. Que la entidad controla el dominio de Internet para el cual se ha
emitido el certificado. Es decir que la entidad descrita en el
servicio de acceso a la base de datos de dominios Internet esta
claramente identificada y coincide con la entidad representada por el
solicitante del certificado, de otra forma el certificado no será
emitido.
That the identified entity controls the Internet domain for which the
certificate was issued. This means that the entity described in the
Internet domains database is clearly identified and matches with the
entity represented by the applicant, otherwise the certificate will
not be issued.
Kathleen Wilson
>> I would like to proceed with this request by asking Camerfirma to
>> respond to this discussion thread with their proposed changes to their
>> CP/CPS as per the action item. If no further discussion is needed, then
>> I will close this discussion and track the actual changes to the CP/CPS
>> in the bug, and then proceed with approval/inclusion without a second
>> round of public discussion.
>>
>> Kathleen
>
> Changes in the CPS v 3.2.1
>
> las lineas marcadas por �CA/Browser Forum Gidelines for Issuance and
> Management of extended validation certificates�. Se realizaran
> siguiendo los mismos procedimientos que un certificado de vinculaci�n
> empresarial, es decir:
>
> Secure Server Certificates (EV) "extended validation" follow the lines
> marked by "CA / Browser Forum Guidelines for Issuance and Management
> of extended validation certificates. A similar process for issuing an
> AC Camerfirma business certificate will be follow, this means:
>
> representante del solicitante en caso de que este sea una entidad
>
> The applicant physical presence, or a representative of the applicant
> if this is a legal entity and the presentation of an valid
> identification will be required by the RA.
>
> documentaci�n pertinente dependiendo del tipo de entidad.
>
> Identification of the company. A specific documentation will be
> required by the RA depending on the type of entity.
>
> empresa que actuara como solicitante.
>
> Presentation of an authorization signed by a company representative
> who acts as the applicant.
>
> certificados la RA deber� comprobar:
>
> Besides the processes already described above, the RA shall ensure
> that:
>
> 1. La existencia de la entidad en el registro mercantil.
>
> The existence of the entity in the commercial register.
>
> organizaci�n incorporada en el certificado, dispondr� de un acceso a
> una base de datos de gesti�n de riesgo empresarial como e-Informa
> http://www.einforma.com. Esta base de datos ofrece informaci�n del
> registro mercantil tanto de las empresas como de sus representantes
>
> If the RA operator needs more information from the organization
> incorporated in the certificate, access to a database of enterprise
> risk management and e-Reports http://www.einforma.com will be used.
> This database provides information from the commercial register about
> Spanish companies and their representatives, incorporating risk
> information.
>
> antig�edad superior a 1 a�o.
>
> Documents provided will be not older than 1 year.
>
> organizaci�n de 1 a�o.
>
> The minimum age of legal existence of the organization will be 1 year.
>
> una prohibici�n gubernamental para hacer negocios.
>
> Not issue certificates to companies eradicated in countries where
> governments ban to do business is established.
>
>
> 2. Que el registro del dominio para el que se va a emitir el
> certificado existe.
>
> That the registration of the domain for which to issue the certificate
> exists
>
> Se utilizaran los servicios de consulta de dominios de https://www.nic.es
> primer nivel �.ES�, y http://www.internic.net/ para el resto de los
> dominios de primer nivel.
>
> We used the consulting services domain https: / / www.nic.es when
> services are contracted for a domain under the top level management.
> "ES" and http://www.internic.net/ for other TLDs
>
> 3. Que la entidad controla el dominio de Internet para el cual se ha
> emitido el certificado. Es decir que la entidad descrita en el
> servicio de acceso a la base de datos de dominios Internet esta
> claramente identificada y coincide con la entidad representada por el
> emitido.
>
> That the identified entity controls the Internet domain for which the
> certificate was issued. This means that the entity described in the
> Internet domains database is clearly identified and matches with the
> entity represented by the applicant, otherwise the certificate will
> not be issued.
>
Ramiro, Thanks for providing the proposed changes and translations. I'm
not sure if I'm interpreting the changes correctly...
It looks like this text is proposed to be added to the section about EV
SSL certs?
What about the non-EV SSL certs?
Kathleen
ramirom
> On 3/7/10 5:30 AM, Ramiro Muñoz Muñoz wrote:
>
>
>
>
>
> >> I would like to proceed with this request by asking Camerfirma to
> >> respond to this discussion thread with their proposed changes to their
> >> CP/CPS as per the action item. If no further discussion is needed, then
> >> I will close this discussion and track the actual changes to the CP/CPS
> >> in the bug, and then proceed with approval/inclusion without a second
> >> round of public discussion.
>
> >> Kathleen
>
> > Changes in the CPS v 3.2.1
>
> > las lineas marcadas por “CA/Browser Forum Gidelines for Issuance and
> > Management of extended validation certificates”. Se realizaran
> > siguiendo los mismos procedimientos que un certificado de vinculación
> > empresarial, es decir:
>
> > Secure Server Certificates (EV) "extended validation" follow the lines
> > marked by "CA / Browser Forum Guidelines for Issuance and Management
> > of extended validation certificates. A similar process for issuing an
> > AC Camerfirma business certificate will be follow, this means:
>
> > representante del solicitante en caso de que este sea una entidad
>
> > The applicant physical presence, or a representative of the applicant
> > if this is a legal entity and the presentation of an valid
> > identification will be required by the RA.
>
> > documentación pertinente dependiendo del tipo de entidad.
>
> > Identification of the company. A specific documentation will be
> > required by the RA depending on the type of entity.
>
> > empresa que actuara como solicitante.
>
> > Presentation of an authorization signed by a company representative
> > who acts as the applicant.
>
> > certificados la RA deberá comprobar:
>
> > Besides the processes already described above, the RA shall ensure
> > that:
>
> > 1. La existencia de la entidad en el registro mercantil.
>
> > The existence of the entity in the commercial register.
>
> > una base de datos de gestión de riesgo empresarial como e-Informa
> >http://www.einforma.com. Esta base de datos ofrece información del
> > registro mercantil tanto de las empresas como de sus representantes
>
> > If the RA operator needs more information from the organization
> > incorporated in the certificate, access to a database of enterprise
> > This database provides information from the commercial register about
> > Spanish companies and their representatives, incorporating risk
> > information.
>
> > antigüedad superior a 1 año.
>
>
> > organización de 1 año.
>
> > The minimum age of legal existence of the organization will be 1 year.
>
>
> > Not issue certificates to companies eradicated in countries where
> > governments ban to do business is established.
>
> > 2. Que el registro del dominio para el que se va a emitir el
> > certificado existe.
>
> > That the registration of the domain for which to issue the certificate
> > exists
>
> > Se utilizaran los servicios de consulta de dominios de https://www.nic.es
> > dominios de primer nivel.
>
> > We used the consulting services domain https: / /www.nic.eswhen
> > services are contracted for a domain under the top level management.
>
> > 3. Que la entidad controla el dominio de Internet para el cual se ha
> > emitido el certificado. Es decir que la entidad descrita en el
> > servicio de acceso a la base de datos de dominios Internet esta
> > claramente identificada y coincide con la entidad representada por el
> > emitido.
>
> > That the identified entity controls the Internet domain for which the
> > certificate was issued. This means that the entity described in the
> > Internet domains database is clearly identified and matches with the
> > entity represented by the applicant, otherwise the certificate will
> > not be issued.
>
> Ramiro, Thanks for providing the proposed changes and translations. I'm
> not sure if I'm interpreting the changes correctly...
>
> It looks like this text is proposed to be added to the section about EV
> SSL certs?
Yes I will pubish the new CPS version in a few days.
>
> What about the non-EV SSL certs?
>
We issue OV certificates where no physical presence is needed. We make
the same validations about organization existence, domain existence
and the link among them. Once checked we send the certificate to the
technical and administration contacts from the domain data base.
> Kathleen
Jean-Marc Desperrier
> Here is a summary of the items that have been pointed out in this
> discussion.
Sorry, Kathleen but I'm afraid the identification used in the root
certificates of Camerfina rise some additional questions.
The already included root certs have exactly the same characteristics.
But as I now learn that you aim to phase out existing improper labeling
practices, I'd like to see those points better clarified.
One root refers to "Chambersign" in it's CN without further precision.
But if you check carefully you'll see that Camerfina is a *member* of
the European Chambersign association (which is hosted here
http://www.chambersign.com/about-us ).
Whilst I think Camerfina has received the right to use the name
Chambersign, it stays that Camerfina and the European Chambersign are
separate entities. It might be useful to see more details about who owns
the Chambersign trademark exactly and under which rules Camerfina is
using it.
Maybe here the fact that in this cert the O is "AC Camerfina" (so it's
listed under "AC Camerfina" in the cert manager) is sufficient.
The other root refers to chambersign.org in it's OU.
Here chambersign.org directly belongs to Camerfina opposite to
chambersign.com.
But that's still quite a bit confusing I think.
Also the practice of setting "C=EU" is a bit strange.
I think the value used there should be the civil legislation under which
rules the CA is operating. Which is spain here.
ramirom
> Kathleen Wilson wrote:
> > Here is a summary of the items that have been pointed out in this
> > discussion.
>
> Sorry, Kathleen but I'm afraid the identification used in the root
> certificates of Camerfina rise some additional questions.
>
> The already included root certs have exactly the same characteristics.
> But as I now learn that you aim to phase out existing improper labeling
> practices, I'd like to see those points better clarified.
>
> One root refers to "Chambersign" in it's CN without further precision.
>
> But if you check carefully you'll see that Camerfina is a *member* of
> the European Chambersign association (which is hosted herehttp://www.chambersign.com/about-us).
>
> Whilst I think Camerfina has received the right to use the name
> Chambersign, it stays that Camerfina and the European Chambersign are
> separate entities. It might be useful to see more details about who owns
> the Chambersign trademark exactly and under which rules Camerfina is
> using it.
>
> Maybe here the fact that in this cert the O is "AC Camerfina" (so it's
> listed under "AC Camerfina" in the cert manager) is sufficient.
>
> The other root refers to chambersign.org in it's OU.
> Here chambersign.org directly belongs to Camerfina opposite to
> chambersign.com.
> But that's still quite a bit confusing I think.
>
All members of Chambersign association have the right to use the
trademark, for example there is a Chabersign in France, in UK as well
among other.
> Also the practice of setting "C=EU" is a bit strange.
> I think the value used there should be the civil legislation under which
> rules the CA is operating. Which is spain here.
We issue the roots within an european scope so after some discusion we
decided to use .EU for the root certificate.
The rules under which we issue certificates are the European ones,
Directive 1999/93/EC
ramirom
> > Here is a summary of the items that have been pointed out in this
> > discussion.
>
> Sorry, Kathleen but I'm afraid the identification used in the root
> certificates of Camerfina rise some additional questions.
>
> The already included root certs have exactly the same characteristics.
> But as I now learn that you aim to phase out existing improper labeling
> practices, I'd like to see those points better clarified.
>
> One root refers to "Chambersign" in it's CN without further precision.
>
> But if you check carefully you'll see that Camerfina is a *member* of
> the European Chambersign association (which is hosted herehttp://www.chambersign.com/about-us).
>
> Whilst I think Camerfina has received the right to use the name
> Chambersign, it stays that Camerfina and the European Chambersign are
> separate entities. It might be useful to see more details about who owns
> the Chambersign trademark exactly and under which rules Camerfina is
> using it.
>
> Maybe here the fact that in this cert the O is "AC Camerfina" (so it's
> listed under "AC Camerfina" in the cert manager) is sufficient.
>
> The other root refers to chambersign.org in it's OU.
> Here chambersign.org directly belongs to Camerfina opposite to
> chambersign.com.
> But that's still quite a bit confusing I think.
>
Members of the Chambersign association have the right to use the
trademark "Chambersign", there is a Chambersign in France in UK among
other.
> Also the practice of setting "C=EU" is a bit strange.
> I think the value used there should be the civil legislation under which
> rules the CA is operating. Which is spain here.
Camerfirma issue certificates in an European scope under the Directive
1999/93/EC, so after some disscusions we decidad to use the .EU domine
for our root certificate.
Nelson Bolyard
> Also the practice of setting "C=EU" is a bit strange.
Doesn't EU expand to "Etats Unis" in French? :)
Erwann Abalea
> On 2010-03-15 08:29 PST, Jean-Marc Desperrier wrote:
>
>> Also the practice of setting "C=EU" is a bit strange.
>
> Doesn't EU expand to "Etats Unis" in French? :)
It does :)
But more than "strange", doesn't setting "C=EU" in a certificate disqualify it
as a X.509 or RFC5280 compliant certificate?
X.520 defines countryName as a digraph taken from ISO3166, and "EU" is not part
of this list (Europe is not a country).
--
Erwann
ramirom
Fo us in now really difficult to change this certificate.
There is a ".eu" domain for europe http://www.eurid.eu/en/eu-domain-names,
Regards
regards
Kathleen Wilson
> certificates of Camerfina rise some additional questions.
>
> The already included root certs have exactly the same characteristics.
> But as I now learn that you aim to phase out existing improper labeling
> practices, I'd like to see those points better clarified.
There seems to be a lot of focus on this now. That was not my intent.
The root cert that presented the problem has the issuer:
CN = Admin-Root-CA
OU = Certification Authorities
OU = Services
O = admin
C = ch
There is no information in this issuer that can be linked back to any
particular CA. There is no distinguishable company name or brand name.
All of the information in this issuer is too generic to do a search on
and hope to find the CA.
As for these Camerfirma roots, they have issuer:
CN = Chambers of Commerce Root - 2008
O = AC Camerfirma S.A.
Object Identifier (2 5 4 5) = A82743287
L = Madrid (see current address at www.camerfirma.com/address)
C = EU
and
CN = Global Chambersign Root - 2008
O = AC Camerfirma S.A.
Object Identifier (2 5 4 5) = A82743287
L = Madrid (see current address at www.camerfirma.com/address)
C = EU
There is clear information in the issuer linking these roots back to the CA.
As for the C=EU questions, I do not know. I haven't ever seen this
raised as a concern. I do not believe that it would block inclusion of
these roots.
Kathleen
Kathleen Wilson
> On 2/12/10 10:51 AM, Kathleen Wilson wrote:
>> Camerfirma (a Regional CA in Spain, and the CA for Chambers of Commerce
>> is to enable all three trust bits for both roots. The request is to also
>> enable EV for both roots.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=406968
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Camerfirma
>>
>> Summary of Information Gathered and Verified:
>> https://bugzilla.mozilla.org/attachment.cgi?id=426075
>>
Thanks again to all of you who have contributed to this discussion. Your
input is greatly appreciated!
There is one action item resulting from this discussion.
ACTION Camerfirma: Update the CP/CPS documents to provide more specific
information about how the domain registration services databases are
used to verify that the certificate subscriber owns/controls the domain
name to be included in the certificate.
In response, Camerfirma is planning to update section 3.1.8 of their CPS
as follows.
For reference, the current version of their CPS is here:
http://policy.camerfirma.com/politicas/CPS_V_3.1.4.pdf
-- Updated Text In Spanish –-
3.1.8 Autenticación de la identidad de un individuo, la organización y
su vinculación.
…
Para los certificados de servidor seguro OV (Organization Validation) se
comprueba:
1. la existencia de la empresa mediante el acceso a los registros
mercantiles www.registradores.org , Camerdata www.camerdata.es o a las
BBDD de la Agencia tributaria www.aeat.es.
2. La existencia del dominio y el derecho al uso de este por el
suscriptor se comprueba mediante el acceso a las bases de datos de
dominios Internet:
• http://reports.internic.net
• http://www.networksolutions.com
• http://en.gandi.net
• http://www.interdomain.es
• https://www.nic.es/ (.es)
• http://www.eurid.eu/ (.eu)
• http://www.nic.coop/whoissearch.aspx (.coop)
• http://www.nominalia.com/
• http://www.arsys.es/
3. El control del dominio por parte de la empresa suscriptora,
comprobando que los datos obtenidos en la consulta a las bases de datos
de los dominios Internet coincide claramente con los datos de la empresa
presentados en la solicitud.
Los certificados se entregan mediante correo electrónico a los
responsables administrativo y técnico que aparecen en las bases de datos
de dominios.
…
Los certificados de servidor seguro EV (extended validation) siguen
las lineas marcadas por “CA/Browser Forum Gidelines for Issuance and
Management of extended validation certificates”. Se realizaran siguiendo
los mismos procedimientos que un certificado reconocido de vinculación
empresarial, es decir:
1. La personación física del firmante suscriptor, o de un
representante del solicitante en caso de que este sea una entidad
jurídica y la presentación de un documento identificativo.
2. Identificación de la empresa, para los que la AR requerirá la
documentación pertinente dependiendo del tipo de entidad.
3. Presentación de una autorización firmada por un representante de
la empresa que actuara como solicitante.
Además de los procesos ya descritos anteriormente para este tipo de
certificados la RA deberá comprobar:
1. La existencia de la entidad en el registro mercantil.
• En caso de que el operador de RA necesite ampliar la información
de la organización incorporada en el certificado, dispondrá de un acceso
a una base de datos de gestión de riesgo empresarial como e-Informa
http://www.einforma.com. Esta base de datos ofrece información del
registro mercantil tanto de las empresas como de sus representantes
incorporando información de riesgo.
• La comprobación de que los datos o documentos aportados no
tengan una antigüedad superior a 1 año.
• Consulta de la antigüedad mínima de existencia legal de la
organización de 1 año.
• No emitir certificados a empresas erradicadas en países donde
exista una prohibición gubernamental para hacer negocios.
2. La existencia del dominio y el derecho al uso de este por el
suscriptor se comprueba mediante el acceso a las bases de datos de
dominios Internet:
• http://reports.internic.net
• http://www.networksolutions.com
• http://en.gandi.net
• http://www.interdomain.es
• https://www.nic.es/ (.es)
• http://www.eurid.eu/ (.eu)
• http://www.nic.coop/whoissearch.aspx (.coop)
• http://www.nominalia.com/
• http://www.arsys.es/
3. Que la entidad controla el dominio de Internet para el cual se
ha emitido el certificado. Es decir que la entidad descrita en el
servicio de acceso a la base de datos de dominios Internet esta
claramente identificada y coincide con la entidad representada por el
solicitante del certificado.
Las Guías de emisión de certificados EV exigen la diferenciación de
tipos de organización diferentes (Privadas, Gobierno, Negocio). En estos
casos el solicitante marca en el documento de solicitud el tipo de
entidad a la que pertenece. La autoridad de registro verificará su
conformidad y validara el certificado donde se incorporara dicha
información tal y como se define en las Guías de emisión de referencia.
Cada tipo de entidad debe presentar una documentación distinta para
demostrar su existencia y están descritas en la página Web de Camerfirma.
Los certificados marcados como EV son comprobados mensualmente por un
auditor interno que se asegurará de su correcta emisión y la existencia
de la documentación que ha servido de base a su emisión.
-- Google Translation of the Updated Text –-
3.1.8 Authentication of the identity of an individual, organization, and
their relationship.
…
To secure server certificates OV (Organization Validation) is checked:
1. the existence of the business through access to commercial registers
www.registradores.org, DB Camerdata www.camerdata.es or www.aeat.es. Tax
Agency
2. The existence of the domain and the right to use this by the
subscriber is verified by accessing databases of Internet domains:
• http://reports.internic.net
• http://www.networksolutions.com
• http://en.gandi.net
• http://www.interdomain.es
• https: / / www.nic.es/ (. En)
• http://www.eurid.eu/ (. Eu)
• http://www.nic.coop/whoissearch.aspx (. Coop)
• http://www.nominalia.com/
• http://www.arsys.es/
3. The control of the domain by the subscriber, verifying that the data
obtained in consultation with the databases of Internet domains
coincides neatly with the company data submitted in the application.
The certificates are delivered via email to the administrative and
technical responsibility that appear in the databases of domains.
…
Secure Server Certificates EV (extended validation) lines are marked by
"CA / Browser Forum Gidelines for Issuance and Management of extended
validation certificates. Were made following the same procedures as a
qualified certificate business linkage, ie:
1. The signer's physical Impartiality subscriber, or a representative of
the applicant if this is a legal entity and the presentation of an
identification.
2. Identification of the company, for which the AR require documentation
depending on the type of entity.
3. Presentation of an authorization signed by a company representative
to act as applicant.
Besides the processes already described above to such certificate the RA
shall ensure that:
1. The existence of the entity in the commercial register.
• If the RA operator needs more information from the organization
incorporated in the certificate, you will have access to a database of
enterprise risk management and e-Reports http://www.einforma.com. This
database provides information from the commercial register of both
companies and their representatives incorporating risk information.
• Verification that the data or documents provided are not older than 1
year.
• Consultation of the minimum age of legal existence of the organization
for 1 year.
• Do not issue certificates to companies eradicated in countries where
there is a government ban to do business.
2. The existence of the domain and the right to use this by the
subscriber is verified by accessing databases of Internet domains:
• http://reports.internic.net
• http://www.networksolutions.com
• http://en.gandi.net
• http://www.interdomain.es
• https: / / www.nic.es/ (. En)
• http://www.eurid.eu/ (. Eu)
• http://www.nic.coop/whoissearch.aspx (. Coop)
• http://www.nominalia.com/
• http://www.arsys.es/
3. The entity controls the Internet domain for which the certificate was
issued. This means that the entity described in the service of access to
the database of Internet domains is clearly identified and agreed with
the entity represented by the applicant.
Guides emission EV certificates require the differentiation of different
organizational types (Private, Government, Business). In these cases the
applicant checks in the application document the type of entity to which
it belongs. The registration authority will verify compliance and to
validate the certificate which incorporate that information as defined
in the Guidelines reference emission.
Each type of entity should submit separate documentation to prove their
existence and are described in the Camerfirma website.
Marked as EV certificates are checked monthly by an internal auditor to
ensure proper issuance and the existence of documentation that has
provided the basis for its issuance.
---
I believe that these modifications to their CPS will satisfy the action
item for Camerfirma to provide more specific information in their CPS
about their procedures for verifying the ownership/control of the domain
name.
I will wait for a couple more days to see if there is any feedback on
the added text.
Please note that the Google Translation is not perfect; it is just the
way that I use to check that the necessary text is being added to the
CPS. I don’t want to spend time correcting the English translation
above, unless further clarification is needed.
If these changes are sufficient, then I propose to track the action item
to update the CPS in the bug. I would recommend approving the request
after I have verified that the text has been added to the new version of
Camerfirma’s CPS and posted on their website.
Kathleen
Kathleen Wilson
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion was in regards to the request from Camerfirma to add two
root certificates (“Chambers of Commerce Root – 2008” and “Global
Chambersign Root – 2008”) and enable all three trust bits for both
roots. The request is to also enable EV for both roots.
The discussion resulted in the following action item.
ACTION Camerfirma: Update the CP/CPS documents to provide more specific
information about how the domain registration services databases are
used to verify that the certificate subscriber owns/controls the domain
name to be included in the certificate.
In response, Camerfirma is planning to update section 3.1.8 of their
CPS, as stated in this discussion.
I will post a summary of the action item in the bug, and track it there.
After Camerfirma updates the bug with a link to the updated CPS, I will
confirm that the clarifications were added as per this discussion. Then
I will post my recommendation for approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=406968
I am now closing this discussion. Any further follow-up on this request
should be added directly to the bug.
Thanks,
Kathleen