ACEDICOM Root Inclusion Request
Kathleen Wilson
ACEDICOM is the next request in the queue for public discussion.
The Edicom Certification Authority (ACEDICOM) provides companies,
communities and physical persons with secure electronic identification
mechanisms that enable them to engage in activities where the digital
signature replaces the handwritten with identical legal guarantees. To
this end, ACEDICOM issues certificates in accordance with the
stipulations of Directive 1999/93/EC of 13th December 1999 and Law
59/2003 of 19th December, on electronic signature, and so has
sufficient recognition to operate in all countries of the European
Union. The Edicom CA is responsible for obtaining the corresponding
official authorisation in those places outside the Union where it
operates commercially.
ACEDICOM has applied to add the “ACEDICOM Root” root certificate and
enable all three trust bits.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=471045
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#ACEDICOM
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=417996
Noteworthy points:
* This root has three internally-operated subordinate CAs. The
ACEDICOM 01 subordinate CA issues Qualified certificates for
identification and advanced electronic signature, for the use of
physical persons or legal organizations. The ACEDICOM 02 subordinate
CA issues certificates for purposes other than Qualified electronic
signature. The ACEDICOM Servidores subordinate CA issues server/client
certificates and code signing certificates.
* The Certification Practices Declaration (CPS) has been translated
into English. There are 6 Certification Policies (CP) documents
according to certificate type; they are all in Spanish. English
translations of certain sections of the CP for SSL/TLS certs have been
provided and verified using Google Translate, and have been included
in the Summary of Information Gathered and Verified document.
** CPS in English:
http://acedicom.edicomgroup.com/en/archivos/politicas/ACEDICOM_CertificationPractice.pdf
** CP documents according to cert type:
http://acedicom.edicomgroup.com/en/contenidos/practicasyPoliticas/punto1.htm
The ACEDICOM 01 and ACEDICOM 02 sub-CAs are covered by the CP
documents for Qualified certs.
** CP for the ACEDICOM Servidores sub-CA:
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf
* The request is to enable all three trust bits (websites, email, code
signing).
** Translation of Servidores CP, Section 3.2.2. Proof of identity
*** Is required for the registration of the certificate prove the
identity of the certificate to be registered. Specifically, the data
in the extensions that identify the subject, referred to in paragraph
3.1.1, must be verified or will not included.
*** The initial verification of the identity of the data required for
inclusion in the certificate depends on the subject and the same is as
follows:
*** TLS client certificate / email: it will be verified the email
address of the applicant, so that once the certificate application
process starts, the applicant will get the necessary instructions to
continue the same through e-mail address specified in the application
and intended to be included in the certificate.
*** TLS server certificates: It is verified that the person or entity
controls the Internet domain specified in the CN. Once the certificate
application process starts, it will be provided the necessary
instructions to continue the same path through the contact (email,
phone or physical address) specified in the request and must match the
administrative contact list whois the domain.
*** Any other additional information to include in the certificate
must be appropriately verified. In any case ACEDICOM reserves the
right to require the physical presence of the applicant or person
authorized by it in points allowed for registration in order to
provide documentation and perform the appropriate checks on identity,
as detailed in the Statement of Practice Certification in points 3.2.2
and 3.2.3.
* Test Website: https://cartero.edicom.es/RootCertificatePrograms/test.htm
* CRL:
** ACEDICOM 01: http://acedicom.edicomgroup.com/acedicom01.crl
** ACEDICOM 02: http://acedicom.edicomgroup.com/acedicom02.crl
** ACEDICOM Servidores: http://acedicom.edicomgroup.com/servidoresca.crl
** NextUpdate is 24 hours. CPS section 4.9.9: ACEDICOM will publish a
new CRL in the repository at 24 hour intervals maximum.
* OCSP is available under all the sub-CAs.
** ACEDICOM 01: http://ocsp.acedicom.edicomgroup.com/acedicom01
** ACEDICOM 02: http://ocsp.acedicom.edicomgroup.com/acedicom02
** ACEDICOM Servidores: http://ocsp.acedicom.edicomgroup.com/servidores
* Audit: ACEDICOM is currently being audited by Ernst & Young
according to the WebTrust CA audit criteria. ACEDICOM was audited in
2008 according to the ETSI 101 456 criteria by S21 (http://
www.s21sec.com/). The auditor’s statement was confirmed via an email
exchange with the auditor. ACEDICOM has also been accredited by the
"Asociación Multisectorial de Empresas Españolas de Electrónica y
Comunicaciones" (ASIMELEC, http://www.asimelec.es), according to the
European Electronic Signature Directive (http://ec.europa.eu/
information_society/policy/esignature/index_en.htm).
This begins the 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.
Note #1: Due to the holidays, I may not be online regularly, so this
request may end up being in discussion longer than needed.
Note #2: For the time being, Google Groups is not working for Mozilla
discussions. Please either use a newsreader like Thunderbird, and/or
subscribe to this group by email.
Kathleen
Eddy Nigg
> ** CPS in English:
> http://acedicom.edicomgroup.com/en/archivos/politicas/ACEDICOM_CertificationPractice.pdf
>
Unfortunately the practice statement doesn't cover the bits which
interest me most. In particular domain and email control validation!
> ** CP for the ACEDICOM Servidores sub-CA:
> http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf
>
It's not clear to me what this policy covers. Is it about how their
three internally-operated subordinate CAs? Or something else?
> * The request is to enable all three trust bits (websites, email, code
> signing).
>
Where exactly is code signing covered? I've not find a lot of
information about that...actually none so far. :-)
> ** Translation of Servidores CP, Section 3.2.2. Proof of identity
> *** Is required for the registration of the certificate prove the
> identity of the certificate to be registered. Specifically, the data
> in the extensions that identify the subject, referred to in paragraph
> 3.1.1, must be verified or will not included.
>
OK, but under 3.2.2. Authentication of identity of an entity it says:
When the authentication is done remotely, in general no methods of
identification other than the digital signature with certificates issued
by ACEDICOM or some other Services of Certification Service Provider that
issues recognized certificates will be used.
What kind of certificates are issued in this way and what are those
other Services of Certification Service Provider? Other public CAs for
example?
> *** TLS client certificate / email: it will be verified the email
> address of the applicant
>
I would like to receive more information about that, in particular the
disclosed policy and practice.
> *** TLS server certificates: It is verified that the person or entity
> controls the Internet domain specified in the CN. Once the certificate
> application process starts, it will be provided the necessary
> instructions to continue the same path through the contact (email,
> phone or physical address) specified in the request and must match the
> administrative contact list whois the domain.
>
Also here I would like to receive more information on that, in
particular the disclosed policy and practice. Additionally how is this
done in case of authentication is done remotely as per section 3.2.2.
That's all for now - happy holidays to whoever celebrates them!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Varga Viktor
----
Certificates referencing hostnames or private IP addresses
o Special IP addresses (RFC 3330) are not allowed as a domain name on server certificates, as
described on the section 3.1.1 of the TLS Certificate Policy.
----
Is this block means, that only the IP was denie, when somebody request it, but the hostname is possible?
Or this simply left from this document???
I have checked the english CPS and didn't found anything about the domain checking.
searched the keywords: validation, domain int he main cps.
Now I have checked the spnaish version too, and found, that there will be validaton of the domain names.
I have checked the RCF 3300 but it only includes the internal IPs, and doesnot includes the
external IPs.
So my question:
Whats the source of this bloc kin the gathering document?
The CPS describes, that domain is validated only. This could mean of course that only domain names can used, but you can found nowhere exactly, that i por hostname is not allowed.
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Raul
-------
QUESTION
-------
** CPS in English:
http://acedicom.edicomgroup.com/en/archivos/politicas/ACEDICOM_CertificationPractice.pdf
Unfortunately the practice statement doesn't cover the bits which interest me most. In particular domain and email control validation!
-------
ANSWER
-------
In the practice statement, at section 3.2.2 you can read:
"In the event that a Certification Policy deems necessary another authentication procedure for the identity of an entity, the policy will establish the methods needed for the verification of said identity."
Then at the policy "Pol�tica de Certificados TLS para cliente y servidor", http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf,
and at the same section 3.2.2 it is specified the validation of the domain de e-mail atirbutes.
-------
QUESTION
-------
** CP for the ACEDICOM Servidores sub-CA:
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf
"It's not clear to me what this policy covers. Is it about how their three internally-operated subordinate CAs? Or something else? "
-------
ANSWER
-------
ACEDICOM Root has nowadays three sub-CAs.They are "ACEDICOM01", "ACEDICOM02" and "ACEDICOM Servidores". The two first are focused on qualified certificates.
"ACEDICOM Servidores" is focused on client/server certificates and the related policy is "Pol�tica de Certificados TLS para cliente y servidor", http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf,
-------
QUESTION
-------
* The request is to enable all three trust bits (websites, email, code signing).
Where exactly is code signing covered? I've not find a lot of information about that...actually none so far.
-------
ANSWER
-------
For the Code signing validation process all the validations specified at CPS 3.2.2 are aplied
---------
QUESTION
---------
> ** Translation of Servidores CP, Section 3.2.2. Proof of identity
> *** Is required for the registration of the certificate prove the
> identity of the certificate to be registered. Specifically, the data
> in the extensions that identify the subject, referred to in paragraph
> 3.1.1, must be verified or will not included.
>
OK, but under 3.2.2. Authentication of identity of an entity it says:
When the authentication is done remotely, in general no methods of identification other than the digital signature with certificates issued by ACEDICOM or some other Services of Certification Service Provider that issues recognized certificates will be used.
What kind of certificates are issued in this way and what are those other Services of Certification Service Provider? Other public CAs for example?
-------
ANSWER
-------
On qualified certificates , those not concerning to this process, physical authentication is required first time. For renew process ACEDICOM accepts renew aplication digitally signed by the certificate issued before it expires.
On certificates issued under policy "Pol�tica de Certificados TLS para cliente y servidor", not only what the CPS says must be followed, bu also what the policy states. So, the posibility of "remote authentication" does not aply on this case.
---------
QUESTION
---------
*** TLS client certificate / email: it will be verified the email address of the applicant
I would like to receive more information about that, in particular the disclosed policy and practice.
-------
ANSWER
-------
Policy statement:
It will be verified the email address of the applicant, so that once the process of certificate request has started, the requester will be given instructions on how to continue through the email address specified in the request and intended to be included in the certificate.
So, once the request process has been started it will be send to e-mail address instructions on how to go on with the process. Once the requester follows the instructions, ACEDICOM considers that the e-mail is owned by the person who followed the process. The issued certificate will be always sent to such e-mail adress.
---------
QUESTION
---------
*** TLS server certificates: It is verified that the person or entity controls the Internet domain specified in the CN. Once the certificate application process starts, it will be provided the necessary instructions to continue the same path through the contact (email, phone or physical address) specified in the request and must match the administrative contact list whois the domain.
Also here I would like to receive more information on that, in particular the disclosed policy and practice. Additionally how is this done in case of authentication is done remotely as per section 3.2.2.
-------
ANSWER
-------
The policy states that whois serice will be used by the register operator in order to validate the domain ownership. The operator will find the ownership e-mail, phone and address. Usally the e-mail address of the administrative contact of the domain will be used as the contact information. Once the operator gets that information, will send an e-mail to the administrative contact telling that a certificate issue process has been started for a domain for which he is the administrative contact. In that e-mail, the necesary instructions to go on with the process will be sent. So, just the administrative contact has the posibility to finish the aplication process. In case there is some problem with the e-mail address, phone or physical address can be used in order to go on , or not, with the process.
Remotely process validation doesn't apply here as explained before.
Raul
Just domain names are considered. Validation process at the policy (3.2.2) specifies that whois validation is necessary. Since whois contains information related to domain names (e.g. "www.example.com") and not to hostmanes (e.g. "hostname"), ACEDICOM just consider domain names.
We will consider it clarify it still more at policy reviews.
Eddy Nigg
> I'll answer all of tour questions. If at any point you need additional information please ask for it.
>
Hi Raul,
Thank you for your answers. Here another few questions.
> ---------
> QUESTION
> ---------
>
>> ** Translation of Servidores CP, Section 3.2.2. Proof of identity
>> *** Is required for the registration of the certificate prove the
>> identity of the certificate to be registered. Specifically, the data
>> in the extensions that identify the subject, referred to in paragraph
>> 3.1.1, must be verified or will not included.
>>
>>
> OK, but under 3.2.2. Authentication of identity of an entity it says:
>
> When the authentication is done remotely, in general no methods of identification other than the digital signature with certificates issued by ACEDICOM or some other Services of Certification Service Provider that issues recognized certificates will be used.
>
This is still not clear to me...you rely in that case on a previous
validation? For how long? How do you validate domain and email control?
> What kind of certificates are issued in this way and what are those other Services of Certification Service Provider? Other public CAs for example?
> -------
> ANSWER
> -------
> On qualified certificates , those not concerning to this process, physical authentication is required first time. For renew process ACEDICOM accepts renew aplication digitally signed by the certificate issued before it expires.
>
So you skip re-validation?!
> On certificates issued under policy "Política de Certificados TLS para cliente y servidor", not only what the CPS says must be followed, bu also what the policy states. So, the posibility of "remote authentication" does not aply on this case.
>
Does your CP/CPS actually say that?
> ---------
> QUESTION
> ---------
> *** TLS client certificate / email: it will be verified the email address of the applicant
>
> I would like to receive more information about that, in particular the disclosed policy and practice.
> -------
> ANSWER
> -------
> Policy statement:
> It will be verified the email address of the applicant, so that once the process of certificate request has started, the requester will be given instructions on how to continue through the email address specified in the request and intended to be included in the certificate.
>
OK, but once I've gone through you process I know already how to
continue, I probably can reuse it next time. This doesn't sound robust
enough in my opinion and wouldn't qualify as a means for email control
validation.
> So, once the request process has been started it will be send to e-mail address instructions on how to go on with the process. Once the requester follows the instructions, ACEDICOM considers that the e-mail is owned by the person who followed the process. The issued certificate will be always sent to such e-mail adress.
>
No, that's not sufficient. It would be naive to consider this a
sufficient verification for control validation.
> ---------
> QUESTION
> ---------
> *** TLS server certificates: It is verified that the person or entity controls the Internet domain specified in the CN. Once the certificate application process starts, it will be provided the necessary instructions to continue the same path through the contact (email, phone or physical address) specified in the request and must match the administrative contact list whois the domain.
>
> Also here I would like to receive more information on that, in particular the disclosed policy and practice. Additionally how is this done in case of authentication is done remotely as per section 3.2.2.
> -------
> ANSWER
> -------
> The policy states that whois serice will be used by the register operator in order to validate the domain ownership. The operator will find the ownership e-mail, phone and address. Usally the e-mail address of the administrative contact of the domain will be used as the contact information. Once the operator gets that information, will send an e-mail to the administrative contact telling that a certificate issue process has been started for a domain for which he is the administrative contact. In that e-mail, the necesary instructions to go on with the process will be sent. So, just the administrative contact has the posibility to finish the aplication process. In case there is some problem with the e-mail address, phone or physical address can be used in order to go on , or not, with the process.
> Remotely process validation doesn't apply here as explained before.
>
Also here, if you have further information please advise. This doesn't
sound sufficient for qualifying for domain control validation.
Raul Santisteban
As all your doubts are related to validation process, I'll explain the process in depth, according to CP/CPS and ACEDICOM internal procedures.
Also, and taking into account your questions I'll describe the parts of ACEDICOM internal procedure that we will try to translate into CP/CPS so no subscriber has the same doubts.
ACEDICOM issues several kinds of certificate, all this kind of certificates are explained on its corresponding policy statement. The policy "Pol�tica de Certificados TLS para cliente y servidor" considers:
- client/server certificates
- e-mail validation certificates
The rest of policies (5 more) considers just qualified certificates. On Qualified certificates as CPS/CPs (3.2.2) and "ETSI TS 101 456" states, ACEDICOM validates the identity of the subscriber and all the attributes to be included on the certificate physically and with the necessary documentation.
When qualified certificates are issued on a SSCD device, then as European Directive 1999/93/CE states, digital signatures under that certificates are considered qualified signatures, and they has the same validation as handwrite sign.
For the process of renovation of a certificate,
For the "Authentication of identity of an entity", CP at 3.2.2 states the general process for qualified certificates, which is really hard since it enforce physical meet of the subscriber and the Registration operator and all the necessary documentation to validate each attribute to be included.
Regarding to certificates issued under policy "Pol�tica de Certificados TLS para cliente y servidor"
CPS, at 3.2.2 says:
"In the event that a Certification Policy deems necessary another authentication procedure for the identity of an entity, the policy will establish the methods needed for the verification of said identity."
On this case, as process as e-mail or domain ownership must be considered, the policy "Pol�tica de Certificados TLS para cliente y servidor" extends the validation process. To clarify your doubts, on the validation process ACEDICOM generates a challenge , which includes a random number. This challenge is associated internally with the request.
The challenge chain is send to the subscriber e-mail address. The subscriber must response to the challenge chain, following the link with the challenge , which is of course different for each request and unpredictable . When the Register operator receives the response to the challenge, the ownership of the e-mail is proved.
For the server certificates, the process is similar, the diference is that the e-mail address used for the challenge is the e-mail of the administrative contact.
This process is detailed on internal ACEDICOM procedures, and will be included on the policy "Pol�tica de Certificados TLS para cliente y servidor" on next review in order to avoid any doubt.
At Policy Draft revision we have included (Spanish yet):
"En los procesos de comprobaci�n de la propiedad de una direcci�n de correo electr�nico, ACEIDCOM incluir� en el e-mail una cadena aleatoria e irrepetible , que conformar� un desaf�o. El receptor del correo electr�nico responder� al desaf�o siguiendo las instrucciones indicadas en el propio correo. Dicho desaf�o es asociado de forma inequ�voca con la solicitud de emisi�n de certificado. Cuando el operador de registro compruebe que la respuesta al desaf�o es correcta, quedar� demostrada la propiedad de la direcci�n de correo electr�nico, y podr� continuar con el proceso de validaci�n y emisi�n del certificado."
When the Seccuritty officer approves the modification we will update the policy at the web site.
Regarding to "Remote authentication", CPS states at 3.2.3:
"It is also possible to do without the physical presence if the signature contained in the request for issue of a certificate has been legitimized by notary, and in the cases anticipated by article13.4 of Law 59/2003, of 19th December."
Also at 3.3.1, it says:
"Likewise, and in accordance with that stipulated in art. 13.4 b) of Law 59/2003, of 19th December, on Electronic Signature, the renewal of the certificate by means of digitally signed requests will demand that a period of time of less than five years has passed since the personal identification."
So, the period is 5 years. ACEDICOM doesn't skip revalidation, it only means that the digital signature of the request with a qualified certificate is enough to accept the request, and the subscriber hasn't to handwrite sign the contract.
Anyway, for e-mail , client/server certificates, the policy extends the requirements for the validation process, so it "overwrites" 3.2.3 and e-mail and domain control process are mandatories always, as you can see at 3.2.3 of the policy "Pol�tica de Certificados TLS para cliente y servidor". So, challenge/response methods are always necessary to go on with the process.
Again here, in order to clarify it for all subscriber, at the policy review Draft (Spanish) we have included:
"Dichos procesos de validaci�n de control o propiedad de la direcci�n de correo electr�nico son obligatorios en cada petici�n de emisi�n de certificados o renovaci�n", which can be translated into "The e-mail control or ownership process validation are mandatory for each certificate issue request or renovation request"
>> On certificates issued under policy "Pol�tica de Certificados TLS para
Eddy Nigg
On 01/12/2010 02:42 PM, Raul Santisteban:
> At Policy Draft revision we have included (Spanish yet):
>
> "En los procesos de comprobación de la propiedad de una dirección de correo electrónico, ACEIDCOM incluirá en el e-mail una cadena aleatoria e irrepetible , que conformará un desafío. El receptor del correo electrónico responderá al desafío siguiendo las instrucciones indicadas en el propio correo. Dicho desafío es asociado de forma inequívoca con la solicitud de emisión de certificado. Cuando el operador de registro compruebe que la respuesta al desafío es correcta, quedará demostrada la propiedad de la dirección de correo electrónico, y podrá continuar con el proceso de validación y emisión del certificado."
>
> When the Seccuritty officer approves the modification we will update the policy at the web site.
>
I think this answers most of my questions I think. I suggest to follow
up on the changes to the CP/CPS and perhaps clarify when the last audit
was performed and when the next audit is due. Perhaps the CP/CPS could
be confirmed before final approval as a last action item. <= That's for
Kathleen to consider as a suggestion.
Thank you for your cooperation and good luck!
Kathleen Wilson
Below is a Google Translation of section 3.2 of the TLS CP located at
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf
Note the paragraph describing the challenge-response email.
3.2 INITIAL IDENTITY VERIFICATION
3.2.1 Methods of proof of possession of private key
Key pairs associated with this policy certificates are generated by a
process controlled at all times by the applicant using a software or
hardware device.
It is the user who must at all times ensure that private keys are
controlled not by using shared computers and the corresponding
protection of material by mechanisms based on username and password.
This policy does not contain guidelines on the type of device on which
the keys generated and stored as it is the responsibility of the applicant.
3.2.2 Accreditation of identity
It is a requirement for registration certificate irrespective of the
type to prove the identity of the certificate subject to be registered.
Specifically, the data displayed on the extensions that identify the
subject, mentioned in paragraph 3.1.1, must be verified or otherwise not
be possible inclusion.
The initial verification of identity data required for inclusion in the
certificate depends on the subject of same and is as follows:
• Client certificates TLS / email: checks the email address of the
applicant, so that once the license application process, you will be
given instructions on how to continue with it through the email address
specified in the application and intended to be placed on the license.
• TLS Server Certificates: checks that the person or entity requesting
control the Internet domain specified in the CN. Once the license
application process, you will be given the necessary instructions to
continue the same path through the contact (email, phone or physical
address) specified in the request and shall coincide with the
administrative contact list in the domain whois.
In the process of verifying the ownership of an email address, ACEDICOM
included in the email and unique random string, which will form a
challenge. The email recipient will respond to the challenge by
following the instructions in the email itself. This challenge is
unambiguously associated with the application for issue of certificate.
When the operator of record establishes that challenge response is
correct, will be demonstrated ownership of the email address and you can
continue the process of validation and certificate issuance.
These validation processes of control or ownership of the email address
are required for each request on issue or renewal.
Any additional data to include in the certificate must be appropriately
verified. In any case ACEDICOM reserves the right to require physical
presence of the applicant or person authorized by him in the record
points allowed in order to provide documentation and perform the
appropriate identity checks, as detailed in the Practice Statement
Certification in sections 3.2.2 and 3.2.3.
Kathleen Wilson
your feedback in this discussion. Your participation in this process is
greatly appreciated.
Here is a summary of the discussion.
CPS/CP documents: There were questions about what is covered in the CPS
and the 6 CP documents.
ACEDICOM clarified that the ACEDICOM root currently has three sub-CAs,
two of which issue qualified certificates, and the other issues
client/server certificates. The CPS is a general compendium of rules
applicable to all certifying activities of the EDICOM CA. However, the
different specialties applicable to each of the different types of
certificates that are issued are stipulated in the different
Certification Policies. The TLS CP covers client/server certificates and
email validation certificates. The other CP documents are only for the
qualified certificates.
Verification of Email Address Ownership/Control: Concern was raised that
the procedures that were documented in the TLS CP were insufficient
because the email from the RA to the subscriber appeared to be
predictable and repeated instructions.
ACEDICOM clarified their procedures, which include a challenge-response
mechanism, and updated the TLS CP to make this more apparent.
Verification of Domain Ownership/Control: Similar concerns were raised
about the predictability of the process for verifying ownership/control
of the domain name.
ACEDICOM clarified their procedures, which include a challenge-response
mechanism, and updated the TLS CP to make this more apparent.
Re-validation during Renewal: Concern was raised that it sounded like
re-validation of ownership/control of email address and domain name were
not performed during renewal.
ACEDICOM clarified that the validation processes are required for each
request on issue and renewal, and updated the TLS CP to make this more
apparent.
Code Signing: A question was raised about where exactly code signing
certificates are documented.
ACEDICOM stated that for Code Signing validation process all the
validations specified at CPS 3.2.2 are applied.
Precedence has been made that the Code Signing trust bit is not enabled
for roots if the CP/CPS documentation does not contain specific
information about code signing certificates. Due to the translations
required for the TLS CP, I have not found the specific reference to Code
Signing certificates.
Request to ACEDICOM: Please point me to the text where code/object
signing certificates are described in one of the CP/CPS documents. If it
is not there, I recommend proceeding without enabling the code signing
trust bit.
Audit: ACEDICOM has recently completed their annual audit, and will
provide the audit statement as soon as it is available.
Please let me know if I have missed anything.
Thanks,
Kathleen
Raul Santisteban
So, once Policy has been reviewed by Security officer and published into acedicom web site (http://acedicom.edicomgroup.com) , Here is the summary of the points reviewed on the policy document:
"1.4.1 Usos Permitidos" -> "Permitted Uses"
Explicit "Code signing" extendedKeyUsage is referenced
"3.1.1 Tipos de nombres"
Certificados para firma de código
CN (commonName): Contendrá el nombre y apellidos del titular del certificado o de la empresa que lo solicita, cuando estos datos hayan sido convenientemente acreditados y verificados
Las comprobaciones de cualquier atributo a incluir en estos certificados serán llevadas a cabo tal y como especifica el punto 3.2 de las Prácticas de Certificación de ACEDICOM.
This is the part that covers what i explained in previous post. We have decided to explain it better.
-> Google translation:
"3.1.1 Types of names"
Code Signing Certificates
CN (commonName): contain the name of the license holder or company that requests it, when these data have been properly certified and verified
The findings of any attributes to include in such certificate shall be carried out as specified in item 3.2 of the Certification Practice ACEDICOM.
e-mail validation procedures are of course applied to this type of certificates when applied to include that information.
"7.1.2 Extensiones del certificado" -> "7.1.2 Certificate extensions"
Explicit reference to extendedKeyUsage "code signing"
About the audit, should We provide the result through this news security group or is it enough with the publication at the website?
Kathleen Wilson
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf
3.1.1 Types of names
Extensions Subject Distinguished Name, Subject or Subject Alternative
Names Directory Attributes contain information regarding the certificate
subject and is used to identify you. Subject Name Distinguised extension
must always be present. Its contents depend on the type of subject to
which the certificate is issued:
* Client certificates TLS / email
** CN (commonName): contain the name of the holder, when these data have
been properly certified and verified. Should not need to include this
information or can not verify correctly, the content of this field is
"email ACEDICOM certificate".
** Email: The email address
the certificate holder. Must be verified in all cases.
* TLS Server Certificates
** CN (commonName) DNS name assigned to the server that is issued.
Should be verified that the applicant is the owner or is properly
authorized by the owner of Internet domain names that owns the server.
* Code Signing Certificates
** CN (commonName): contain the name of the license holder or company
that requests it, when these data have been properly certified and verified
** The findings of any attributes to include in such certificate shall
be carried out as specified in item 3.2 of the Certification Practice
ACEDICOM.
Optionally may include other values within the extensions mentioned in
this section provided they are checked promptly.
Additionally, it may include the following fields in Subject Alternative
Names that have been verified as mandatory in all cases:
* If TLS client certificate / email, RFC822 Name field to indicate the
direción email.
* If TLS server certificates, DNS Name field contains the DNS name
information.
Kathleen Wilson
your feedback in this discussion. Your participation in this process is
greatly appreciated.
The results of this discussion are as follows.
ACEDICOM has added text to the TLS CP to clarify procedures that are
already in place and were documented in a combination of the CP/CPS
documents and internal documents. The clarifications to the TLS CPS
included:
* Information about the challenge-response mechanism used for
confirming that the certificate subscriber owns/controls the domain name
and email address.
* Clarification that the verification procedures are followed for
certificate renewals.
* Clarification about Code Signing certificates.
There are two remaining action items:
ACTION ACEDICOM: When the new audit statement is available, update the
bug to either attach the document or to provide a link to it.
ACTION Kathleen: Review the new audit statement, and follow Mozilla
procedures to confirm the authenticity of the audit statement.
I will track these two action items in the bug. I do not see the need
for another round of public discussion about this request. Therefore,
after I have reviewed the new audit statement and confirmed the
authenticity as per Mozilla procedures, I plan to post my recommendation
for approval in the bug.
This concludes the public discussion about ACEDICOM’s request to add one
new root CA certificate to the Mozilla root store, as documented in the
following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=471045
All follow-ups on this request should be posted directly in the bug.
Thanks,
Kathleen