Certification Policy for TLS Server and Client certificate · Certification Policy for TLS Server and Client certificate OID: 1.3.6.1.4.1.30051.2.3.2.7 Edicom Capital, S.L. Calle

Certification Policy for TLSServer and Client certificate

Date: 03/04/2019 Version: V1.7Status: VALID Pages: 36OID: 1.3.6.1.4.1.30051.2.3.2.7 Classification: PUBLICFile: CAEDICOM TLSCertificatePolicy.odtRedacted by: CAEDICOM

Certification Policy for TLS Server and Client certificate OID: 1.3.6.1.4.1.30051.2.3.2.7Edicom Capital, S.L.Calle Charles Robert Darwin, 846980 Parque Tecnológico (Valencia) SpainTel.: +34 902 11 92 28 Fax: +34 961 36 71 17http://acedicom.edicomgroup.com

Changes record

Version Date Action description Pages / Sections

1.0 29/06/2015 initial document 39

1.1 05/02/2016 The Key Usage features Data Encipherment andKeyAgreement are removed for compatibility with Mozilla.

28/7.1.2.12

1.2 01/03/2017 The certificate validity period is extended to 3 years. The uses Data Encipherment and KeyAgreement are added for TLS Client certificates

8 / 1.125 / 6.3.227 / 7.1.2.528 / 7.1.2.12

1.3 19/09/2017 Review in accordance with CAB Browser Forum Baseline Requirements 1.4.9:- Reduction of validity period to 825 days.- We specify annual reviews of the policy on CAB Browser Forum BR.- Correction of errata in key generation parameters and in SignatureAlgorithm.

8 / 1.111 / 2.325 / 6.3.223 / 6.1.627 / 7.127 / 7.1.2.327 / 7.1.2.5

1.4 11/06/18 Key Usage updated to critical 28 / 7.1.2.12

1.5 02/08/18 New identity validation methods added 15 / 3.2.2

1.6 23/11/18 Verified CAA records specified 15 / 3.2.2

1.7 03/04/19 Review in accordance with CAB Browser ForumBaseline Requirements 1.6.4:- The section Standard compliance is updated.- Inclusion of the CAA record policy indicatingissue and issuewild for CAEDICOM.

11 / 1.617 / 4.2

Page 2 of 36


Table of content1 INTRODUCTION 8

1.1 PRESENTATION 81.2 IDENTIFICATION 81.3 USER COMUNITY AND APPLICATION SCOPE 9

1.3.1 Certification Authorities 91.3.2 Registration Authorities 91.3.3 End Users 9

1.4 USE OF CERTIFICATES 91.4.1 Allowed uses 91.4.2 Prohibited uses 9

1.5 ADMINISTRATION OF THE POLICY 101.5.1 Entity responsible 101.5.2 Contact person 101.5.3 Competence to determine the CPS compliance with the Policy 10

1.6 Compliance with standards 101.7 DEFINITIONS AND ACRONYMS 10

1.7.1 Definitions 101.7.2 Acronyms 10

2 INFORMATION PUBLICATION AND CERTIFICATE REPOSITORY 112.1 CERTIFICATES REPOSITORY 112.2 PUBLICATION 112.3 UPDATE FREQUENCY 112.4 CERTIFICATE REPOSITORY ACCESS CONTROLS 11

3 CERTIFICATE HOLDER IDENTIFICATION AND AUTHENTICATION 123.1 NAME REGISTRATION. 12

3.1.1 Name types 123.1.2 Meaning of names 123.1.3 Name format interpretation 123.1.4 Uniqueness of names 133.1.5 Resolution of name-related conflicts 133.1.6 Recognition, authentication and function of registered trade names. 133.1.7 Using Wildcard characters in names 13

3.2 INITIAL IDENTITY VALIDATION 133.2.1 Private key possession proof methods 133.2.2 Identity accreditation 13

3.2.2.1 CAEDICOM certificates for internal use 143.3 KEY RENEWAL REQUEST IDENTIFICATION AND AUTHENTICATION 14

3.3.1 Identification and authentication of routine renewal requests 143.3.2 Key renewal request identification and authentication after a revocation – Key not compromised 14

3.4 KEY REVOCATION REQUEST IDENTIFICATION AND AUTHENTICATION 144 LIFE CYCLE OF CERTIFICATES 16

4.1 APPLYING FOR CERTIFICATES 164.2 CERTIFICATE REQUEST FORMALITIES 164.3 ISSUING CERTIFICATES 16

Page 3 of 36


4.4 ACCEPTING CERTIFICATES 164.5 USE OF THE PAIR OF KEYS AND THE CERTIFICATE 164.6 CERTIFICATE RENEWAL 174.7 KEY RENEWAL 174.8 CERTIFICATE MODIFICATION. 174.9 CERTIFICATE REVOCATION AND SUSPENSION. 17

4.9.1 Circumstances for revocation 174.9.2 Entity that may apply for revocation 174.9.3 Revocation request procedure 174.9.4 Revocation request grace period 174.9.5 Circumstances for suspension 174.9.6 Entity that may apply for suspension 174.9.7 Suspension request procedure 174.9.8 Suspension period limits 174.9.9 Frequency of issue of CRLs 174.9.10 Certificate status verification requirements 184.9.11 Other revoked certificate notification methods 184.9.12 Special renewal requirements for compromised keys 18

4.10 CERTIFICATE STATUS CHECKING SERVICES. 184.11 CONCLUSION OF SUBSCRIPTION. 184.12 KEY DEPOSIT AND RECOVERY. 18

5 PHYSICAL SECURITY, MANAGEMENT AND OPERATIONAL CONTROLS 195.1 PHYSICAL SECURITY CONTROLS 19

5.1.1 Location and construction 195.1.2 Physical access 195.1.3 Power supply and air conditioning 195.1.4 Exposure to water 195.1.5 Fire protection and prevention 195.1.6 Storage system 195.1.7 Waste disposal 195.1.8 Remote backup 19

5.2 PROCEDURAL CONTROLS 195.2.1 Trusted roles 195.2.2 Number of people required per task 205.2.3 Identification and authentication for each role 20

5.3 PERSONNEL SECURITY CONTROLS 205.3.1 Background, qualification, experience, and accreditation requirements 205.3.2 Background vetting procedures 205.3.3 Training requirements 205.3.4 Training update requirements and frequency 205.3.5 Task rotation frequency and sequence 205.3.6 Sanctions for unauthorized actions 205.3.7 Staff hiring requirements 205.3.8 Documentation provided to personnel 205.3.9 Periodic compliance checks 205.3.10 Termination of contracts 20

5.4 SECURITY PROCEDURE CONTROLS 215.4.1 Event types recorded 215.4.2 Log processing frequency 215.4.3 Audit logs retention period 215.4.4 Audit log protection 215.4.5 Audit log backup procedures 21

Page 4 of 36


5.4.6 Audit information collection System (internal vs. external) 215.4.7 Notification to the subject cause of the event 215.4.8 Vulnerability analysis 21

5.5 INFORMATION AND RECORDS FILE 215.5.1 Type of information and events recorded 215.5.2 Archive retention term 215.5.3 Archive protection 215.5.4 Archive backup procedures 225.5.5 Record time stamping requirements 225.5.6 Audit information compilation system (internal vs. external) 225.5.7 Procedures to obtain and verify archived information 22

5.6 CA KEY CHANGE 225.7 RECOVERY IN CASE OF KEY COMPROMISE OR DISASTER 22

5.7.1 Alteration of hardware, software and/or data resources 225.7.2 The public key of an entity is revoked 225.7.3 The key of an entity is compromised 225.7.4 Security installation following natural disaster or other types of disaster 22

5.8 CESSATION OF A CA 226 TECHNICAL SECURITY CONTROLS 23

6.1 KEY PAIR GENERATION AND INSTALLATION 236.1.1 Key pair generation 236.1.2 Delivery of private key to end entity 236.1.3 Delivery of public key to certificate issuer 236.1.4 CA public key delivery to the users 236.1.5 Key size 236.1.6 Public key generation parameters 236.1.7 Parameter quality check 246.1.8 Key generation hardware/software 246.1.9 Key usage purposes 24

6.2 PRIVATE KEY PROTECTION 246.2.1 Standards for cryptographic modules 246.2.2 Multi-person private key control 246.2.3 Private key custody 246.2.4 Private key security copy 246.2.5 Private key archive 256.2.6 Private key activation method 256.2.7 Private key deactivation method 256.2.8 Private key destruction method 25

6.3 OTHER KEY PAIR MANAGEMENT ASPECTS 256.3.1 Public key archive 256.3.2 Public and private key usage periods 25

6.4 ACTIVATION DATA 256.4.1 Activation data generation and activation 256.4.2 Activation data protection 256.4.3 Other activation data aspects 25

6.5 IT SECURITY CONTROLS 266.6 SERVICE LIFE SECURITY CONTROLS 266.7 NETWORK SECURITY CONTROLS 266.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS 26

7 CERTIFICATE PROFILES AND REVOKED CERTIFICATE LIST 277.1 CERTIFICATE PROFILE 27

7.1.1 Version number 27

Page 5 of 36


7.1.2 Certificate extensions and structure 277.1.2.1 Version 277.1.2.2 Serial Number 277.1.2.3 Signature Algorithm 277.1.2.4 Issuer Distinguished Name 277.1.2.5 Validity (not before / not after) 277.1.2.6 Subject Public Key Info 277.1.2.7 Subject Distinguished Name 27

7.1.2.7.1 TLS Server Certificate 287.1.2.7.2 TLS Client Certificate 28

7.1.2.8 Subject Alternative Names 287.1.2.8.1 TLS Server certificate: 287.1.2.8.2 TLS Client certificate: 28

7.1.2.9 Subject Key Identifier 287.1.2.10 Authority Key Identifier 287.1.2.11 Basic Constraints 287.1.2.12 Key Usage 287.1.2.13 Certificate Policies 297.1.2.14 Extended Key Usage 297.1.2.15 CRL Distribution Points 297.1.2.16 Authority Information Access 29

7.1.3 Object identifiers (OID) of algorithms 297.1.4 Name formats 297.1.5 Name constraints 297.1.6 Certification Policy Object Identifier (OID) 297.1.7 “Policy Constraints” extension use 297.1.8 Policy qualifier syntax and semantics 29

7.2 CRL PROFILE 307.2.1 Version number 307.2.2 CRL and extensions 30

7.3 REVOKED CERTIFICATE LIST 307.3.1 Time limit of certificates in CRLs 30

7.4 OCSP PROFILE 308 CONFORMITY AUDIT 31

8.1 FREQUENCY OF CONFORMITY CHECKS FOR EACH ENTITY 318.2 AUDITOR IDENTIFICATION/QUALIFICATION 318.3 RELATION BETWEEN AUDITOR AND ENTITY AUDITED 318.4 TOPICS COVERED BY CONFORMITY AUDIT 318.5 ACTIONS TO BE TAKEN AS A RESULT OF A DEFICIENCY 318.6 COMMUNICATION OF RESULTS 31

9 COMMERCIAL AND LEGAL REQUIREMENTS 329.1 TARIFFS 32

9.1.1 Certificate issue or renewal fees 329.1.2 Certificate access fees 329.1.3 Fees for access to status or revocation information 329.1.4 Fees for other services such as information on policies 329.1.5 Refund policy 32

9.2 FINANCIAL STANDING 329.2.1 Indemnification to third parties trusting certificates issued by CAEDICOM 329.2.2 Fiduciary relations 329.2.3 Administrative processes 32

Page 6 of 36


9.3 CONFIDENTIALITY POLICY 339.3.1 Confidential information 339.3.2 Non-confidential information 339.3.3 Disclosure of certificate revocation /suspension information 33

9.4 PERSONAL DATA PROTECTION 339.4.1 Personal Data Protection Plan 339.4.2 Information deemed private 339.4.3 Information not deemed private 339.4.4 Responsibilities 339.4.5 Consent given for personal data use 339.4.6 Communication of information to administrative and/or judicial authorities 339.4.7 Other information disclosure situations 33

9.5 INTELLECTUAL PROPERTY RIGHTS 349.6 OBLIGATIONS AND CIVIL RESPONSIBILITY 34

9.6.1 Obligations of the Certification Entity 349.6.2 Registration Authority Obligations 349.6.3 Subscriber obligations. 349.6.4 Obligations of third parties trusting certificates issued by CAEDICOM 349.6.5 Repository obligations 34

9.7 GUARANTEE WAIVERS 349.8 RESPONSIBILITY LIMITATIONS 34

9.8.1 Guarantees and limitations of guarantees 349.8.2 Disclaimer 349.8.3 Loss limitations 34

9.9 TERM AND CONCLUSION 359.9.1 Term 359.9.2 Conclusion 359.9.3 Survival 35

9.10 NOTIFICATIONS 359.11 MODIFICATIONS 35

9.11.1 Change specification procedures 359.11.2 Publication and notification procedures 359.11.3 Certification Practice Statement approval procedures 35

9.12 RESOLUTION OF CONFLICTS 359.12.1 Extrajudicial resolution of conflicts 359.12.2 Competent jurisdiction. 35

9.13 APPLICABLE LEGISLATION 359.14 COMPLIANCE WITH APPLICABLE LAW 369.15 DIVERSE CLAUSES. 36

Annexe I: Certificate revocation request form 37

Page 7 of 36


1 INTRODUCTION

1.1 PRESENTATIONEDICOM is constituted as Certification Service Provider or Certification Authority by virtue of thedocument submitted to the Ministry of Industry, Trade and Tourism, in accordance with Law 59/2003 of December 19, on electronic signature, in article 30 of the same, transitory provisionnº 2 “Certification Service Providers must notify the Ministry of Industry, Trade and Tourism of the beginning of their activity, their identification details, including the tax and registry identification, and, where indicated, the data that enable communication to be established withthe provider, including the Internet domain name, customer service details, features of the services to be provided, the certificates obtained for said services and certificates of the devices used.”

This document is the Certification Policy associated with TLS client and server certificates, and contains the rules governing the use of certificates defined in this policy. The roles, responsibilities and relationships between the end user and the EDICOM Certification Authority (CAEDICOM), and the rules for application, procurement, management and use of the certificates, are described herein. This document clarifies and complements the CAEDICOM Certification Practice Statement (CPS).

These certificates are issued for a validity period of 825 days.

Said Certification Practice Statement is drafted according to the RFC 3647 specifications: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework” proposed by Network Working Group and completed with aspects demanded in ETSI TS 101 456 V1.2.1 “Policy Requirements for certification authorities issuing qualified certificates”, as well as the Certification Practice Statement, for easy reading or comparison with counterpart documents.

This Certification Policy assumes that the reader is aware of the basic concepts of Public Key Infrastructure, digital certificate and signature. Otherwise, the reader is advised to acquire knowledge of these concepts before continuing to peruse this document.

1.2 IDENTIFICATIONDocument name Certification policy for Client and Server TLS Certificates

Policy Qualification Certificate issued by CAEDICOM

Document version V1.0

OID (Object Identifier) 1.3.6.1.4.1.30051.2.3.2.7

Date of issue 29/06/2015

Expiry date Not Applicable

Related CPS CAEDICOM - Certification Practices Statement (CPS).Version 1.0+OID: 1.3.6.1.4.1.30051.2.3.1.1accessible on: http://acedicom.edicomgroup.com

Localization http://acedicom.edicomgroup.com

Page 8 of 36

http://acedicom.edicomgroup.com/


1.3 USER COMUNITY AND APPLICATION SCOPE

1.3.1 Certification AuthoritiesThe CA permitted to issue certificates in accordance with this policy is “CAEDICOM 01”.

1.3.2 Registration AuthoritiesAs specified in the CAEDICOM Certification Practices Statement (CPS)

1.3.3 End UsersAs specified in the CAEDICOM Certification Practices Statement (CPS)

1.4 USE OF CERTIFICATES

1.4.1 Allowed usesCertificates issued under the current policy may be used to provide security in communicationsby means of SSL or TLS encryption. Typical uses of these certificates may include mutual authentication by SSL/TLS protocol, data encryption, electronic signing of content, and for otherpurposes.

The uses allowed in the specific case of each certificate are deduced from the values of the keyUsage and extendedKeyUsage extensions of the certificate, as stipulated in RFC 3280 (http://tools.ietf.org/html/rfc5280), and this policy includes:

• CLIENT

◦ Client Authentication (web validation)

◦ Email Protection

• SERVER

◦ Server Authentication

Specifically, the certificates issued under this policy may contain the following values in the extendedKeyUsage extension:

• Server Authentication

• Client Authentication

• Email Protection

The certificate profile and extensions cited are described in greater detail in section 7.1.2

1.4.2 Prohibited usesCertificates issued by CAEDICOM will only be used for the function and purpose stipulated inthis Certification Practice Statement and in the corresponding Certification Policies, inaccordance with the regulation in force.

Page 9 of 36


1.5 ADMINISTRATION OF THE POLICY

1.5.1 Entity responsible

Name EDICOM Technical Management

E-mail address [email protected]

Address C/ Charles Robert Darwin,8 – Parque Tecnológico, 46980Paterna (Valencia) SPAIN

Telephone number +34·902 119 229

Fax number +34·96 348 16 88

1.5.2 Contact person

Name EDICOM Systems Department

E-mail address [email protected]

Address C/ Charles Robert Darwin,8 – Parque Tecnológico, 46980Paterna (Valencia) SPAIN

Telephone number +34·902 119 229

Fax number +34·96 348 16 88

1.5.3 Competence to determine the CPS compliance with the PolicyThe EDICOM Technical Management is the competent organ to determine the compliance ofthis Certification Policy (CP) with the Certification Practices Statement (CPS) from theCAEDICOM.

1.6 Compliance with standardsThis policy is drafted taking as RFC 3647 as reference. CRL certificate profiles and CRL profiles comply with RFC 5280.

CAEDICOM undertakes to comply with the guidelines indicated in the latest version of “BaselineRequirements for the Issuance and Management of Publicly-Trusted Certificates”, edited byCA/Browser Forum.In the event of any inconsistency between this document and thoseRequirements, those Requirements take precedence over this document.

1.7 DEFINITIONS AND ACRONYMS

1.7.1 DefinitionsNot stipulated

1.7.2 AcronymsNot stipulated

Page 10 of 36


2 INFORMATION PUBLICATION AND CERTIFICATE REPOSITORY

2.1 CERTIFICATES REPOSITORYAs specified in the CAEDICOM Certification Practices Statement (CPS)

2.2 PUBLICATIONAs specified in the CAEDICOM Certification Practices Statement (CPS)

This Certification Policy will be reviewed at least annually to comply with the latest versionof Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,published by the CA/Browser Forum.

2.3 UPDATE FREQUENCYAs specified in the CAEDICOM Certification Practices Statement (CPS)

2.4 CERTIFICATE REPOSITORY ACCESS CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 11 of 36


3 CERTIFICATE HOLDER IDENTIFICATION AND AUTHENTICATIONThe specifications contained in this section list the procedures to be followed to authenticate the identity of the certificate holder (subject) at the time of registration and for the life cycle of the certificate.

3.1 NAME REGISTRATION.

3.1.1 Name typesThe extensions Subject Distinguished Name, Subject Alternative Names and Subject DirectoryAttributes contain information on the holder of the certificate which is used to identify them.

The Subject Distinguished Name extension must always be present. The content will depend onthe type of subject for which certificate is issued:

• TLS Client certificate / email

◦ CN (commonName): Contains the name and surnames of the certificate holder, oncethese data have been properly accredited and verified. If there is no need to includethis information, or it cannot be properly verified, the content of this field will be “CAEDICOM email certificate”.

◦ E-mail: Certificate holder’s email address. Must be verified at all times.

• TLS Server certificate

◦ CN (commonName): DNS name assigned to the server for which it is issued. Checks must be made to ensure that the applicant is the owner or is duly authorized by the owner of the Internet name domain to which the server belongs.

◦ Checks on any attribute to be included in the certificates will be carried out as specified in section 3.2 of the CAEDICOM Certificate Practices.

Optionally, other values may be included within the extensions cited in this section, as long as they are properly verified.

Additionally, the following fields will be included in Subject Alternative Names, as they will havenecessarily been verified in any case:

• For TLS / e-mail certificates, the RFC822 Name field to indicate the e-mail address.

• For TLS server certificates, the DNS Name field contains information on the DNS name.

3.1.2 Meaning of namesAccording to RFC 3280 http://www.ietf.org/rfc/rfc3280.txt.

3.1.3 Name format interpretationAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 12 of 36

http://www.ietf.org/rfc/rfc3280.txt


3.1.4 Uniqueness of namesTwo Subject DNs that are the same may only coexist if they belong to the same holder.

3.1.5 Resolution of name-related conflictsAs specified in the CAEDICOM Certification Practices Statement (CPS)

3.1.6 Recognition, authentication and function of registered trade names.As specified in the CAEDICOM Certification Practices Statement (CPS)

3.1.7 Using Wildcard characters in namesSo-called wildcard characters in names are not permitted. So, even though a certificate whose CN may be, for example CN=*.domain.tld, may be commonly used and widely accepted on Internet, it cannot be issued under this policy because it contains a wildcard.

There is only one exception: Certificates issued for domains under control of the CAEDICOM administrating organization may contain wildcards, as CAEDICOM has control at all times of thedomains and subdomains belonging to the administrator organization.

3.2 INITIAL IDENTITY VALIDATION

3.2.1 Private key possession proof methodsThe pair of keys associated with this certificate policy are generated by a process under thecontrol of the applicant at all times, using a hardware or software device.

It is the holder who must ensure at all times that private keys are under control, by not usingshared computers and by the appropriate protection by username and password protection-based mechanisms.

This policy not contains guidelines on the type of device on which the keys are generated andstored, as it is the responsibility of the applicant.

3.2.2 Identity accreditationRegistration of any type of certificate must accredit the identity of the holder of the certificate to be registered. Specifically, the data appearing in the extensions that identify the subject mentioned in section 1.2 must be verified, otherwise their inclusion will not be possible.

Initial verification of the identity for the mandatory data to be included in the certificatedepends on the subject of the same and is as follows:

• TLS / e-mail client certificates: The e-mail address of the applicant is verified, so thatonce the certificate application process is initiated, the necessary instructions tocontinue with the same will be provided via the e-mail specified in the request and to beincluded in the certificate.

Page 13 of 36


• TLS server certificates: Checks will be made to ensure that the applicant person ororganization controls the Internet domain indicated in the CN. Once the certificateapplication process is underway, the necessary instructions to continue will be providedthrough the contact route (e-mail, telephone or physical address) specified in therequest and which must match the administrative contact listed in the Whois of thedomain.

For this verification, 1 of the following 2 methods will be applied:• The owner of the domain will create a record in the public DNS with a random value that

will be provided by the Registration Authority. CAEDICOM will save the evidence (screenshot) of the DNS query

• If the applier does not have DNS control, he/she must provide an URL https://domain/randomvalue to be able to issue the certificate. Such random value will be provided by the Registration Authority. We will store the evidence (screen capture) of access to said web from a browser.

CAEDICOM will also perform the verification of the CAA records in the event that the requested domain has such records configured. Both CAA records of type "issuer" and those of "issuewild"will be recognized. The latter only will be used for the case of the exception contemplated in this policy of certificates issued for EDICOM's own infrastructure.

Any other additional information to be included in the certificate must be appropriately verified.In any case, CAEDICOM reserves the right to require the physical presence of the applicant orperson authorized by the same at the Authorized Registration Points in order to providedocumentation and submit to the appropriate identity checks, as detailed in the CertificationPractices Declaration in points 3.2.2 and 3.2.3.

3.2.2.1 CAEDICOM certificates for internal useCertificates issued to CAEDICOM staff and the administrative organization, as well as those issued for the pertinent infrastructure (servers, e-mail, etc.) will not be required to save the documentation associated with identity validation.

3.3 KEY RENEWAL REQUEST IDENTIFICATION AND AUTHENTICATION

3.3.1 Identification and authentication of routine renewal requestsAs specified in the CAEDICOM Certification Practices Statement (CPS)

3.3.2 Key renewal request identification and authentication after a revocation – Key not compromisedThe identification and authentication policy for renewal of a certificate after a revocationwithout compromise of the key will be the same as for initial registration, as described in thisdocument in point 3.2.2., so that the identity of the applicant and the authenticity of therequest are guaranteed trustworthily and unequivocally.

3.4 KEY REVOCATION REQUEST IDENTIFICATION AND AUTHENTICATIONThe certificate holder may apply for revocation thereof, proving their identity by:

Page 14 of 36


• Sending a document or e-mail signed with the same certificate they wish to revoke.

• Use of the mechanism described in section 3.2.2

However, CAEDICOM or any of its component organizations may officially apply for certificate revocation if they have knowledge or suspect that the private key of the holder has been compromised, or any other fact that advises taking this action. Causes for certificate revocationshall include the holder’s loss of control of:

• The e-mail address included in TLS / e-Mail client certificates.

• The domain associated with the CN of the certificate in TLS server certificates.

Page 15 of 36


4 LIFE CYCLE OF CERTIFICATESThe specifications contained in this section complement the provisions set forth in the CAEDICOM Certification Practice Statement (CPS), where necessary.

4.1 APPLYING FOR CERTIFICATESThe person or entity applying for a certificate to be issued in accordance with this certification policy must do so using the document “DIGITAL CERTIFICATION SERVICES PROVISION CONTRACT”, available from the “Certificate Management” section of the CAEDICOM website, http://acedicom.edicomgroup.com

When submitting the application, applicants must prove their identity as described in section3.2.2 of this document and submit the “DIGITAL CERTIFICATION SERVICES PROVISION CONTRACT” by fax, e-mail or personally, duly signed and, where indicated, the pertinent documentation according to the type of organization and representation, as outlined in section3.2.2

The person in charge of receiving said documents in the Registration Authority shall check the applicant’s identity and, as necessary, verify the documents accrediting their representation aswell as their inscription in the corresponding public records, where indicated.

Once all these checks are carried out, the application is validated in the IT system and forwarded by secure electronic means to the CAEDICOM. In the event of denial of the application for certification by the Registration Authority operator, the applicant shall be informed of the reasons for rejection of the request.

Once the certificates have been issued, applicants will receive notification by email of theirdetails and attributes.

The list of authorized registration points can be found in the “Registration Points” section of thewebsite: http://acedicom.edicomgroup.com.

4.2 CERTIFICATE REQUEST FORMALITIESAs specified in the CAEDICOM Certification Practices Statement (CPS). Additionally, the CAArecords policy is implemented in CAEDICOM indicating those that CAEDICOM recognizes, whichare edicomgroup.com as an issue and issuewild.

4.3 ISSUING CERTIFICATESAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.4 ACCEPTING CERTIFICATESAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 16 of 36

http://acedicom.edicomgroup.com/


4.5 USE OF THE PAIR OF KEYS AND THE CERTIFICATERelying parties (trusting 3rd parties/end users) may only place their trust in the certificates forthe purposes set forth in this document and in accordance with the provisions of the ‘KeyUsage’ and 'Extended Key Usage' extensions of the certificate as specified in RFC 3280.http://www.ietf.org/rfc/rfc3280.txt.

4.6 CERTIFICATE RENEWALAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.7 KEY RENEWALAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.8 CERTIFICATE MODIFICATION.As specified in the CAEDICOM Certification Practices Statement (CPS)

4.9 CERTIFICATE REVOCATION AND SUSPENSION.

4.9.1 Circumstances for revocationAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.2 Entity that may apply for revocationAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.3 Revocation request procedureAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.4 Revocation request grace periodAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.5 Circumstances for suspensionAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.6 Entity that may apply for suspensionAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.7 Suspension request procedureAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 17 of 36

http://www.ietf.org/rfc/rfc3280.txt


4.9.8 Suspension period limitsAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.9 Frequency of issue of CRLsAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.10 Certificate status verification requirementsAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.11 Other revoked certificate notification methodsAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.9.12 Special renewal requirements for compromised keysAs specified in the CAEDICOM Certification Practices Statement (CPS)

4.10 CERTIFICATE STATUS CHECKING SERVICES.As specified in the CAEDICOM Certification Practices Statement (CPS)

4.11 CONCLUSION OF SUBSCRIPTION.As specified in the CAEDICOM Certification Practices Statement (CPS)

4.12 KEY DEPOSIT AND RECOVERY.CAEDICOM in this case does not deposit the signature keys; instead they are generated in the software or hardware device exclusively under the holder’s control.

It is the responsibility of the holder to protect the certificate's private key with all due care and attention to ensure it remains under their own exclusive control.

Page 18 of 36


5 PHYSICAL SECURITY, MANAGEMENT AND OPERATIONAL CONTROLS

5.1 PHYSICAL SECURITY CONTROLS

5.1.1 Location and constructionAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.2 Physical accessAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.3 Power supply and air conditioningAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.4 Exposure to waterAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.5 Fire protection and preventionAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.6 Storage systemAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.7 Waste disposalAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.1.8 Remote backupAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.2 PROCEDURAL CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.2.1 Trusted rolesAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 19 of 36


5.2.2 Number of people required per taskAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.2.3 Identification and authentication for each roleAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3 PERSONNEL SECURITY CONTROLS

5.3.1 Background, qualification, experience, and accreditation requirementsAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.2 Background vetting proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.3 Training requirementsAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.4 Training update requirements and frequencyAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.5 Task rotation frequency and sequenceAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.6 Sanctions for unauthorized actionsAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.7 Staff hiring requirementsAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.8 Documentation provided to personnelAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.9 Periodic compliance checksAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.3.10 Termination of contractsAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 20 of 36


5.4 SECURITY PROCEDURE CONTROLS

5.4.1 Event types recordedAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.2 Log processing frequencyAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.3 Audit logs retention periodAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.4 Audit log protectionAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.5 Audit log backup proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.6 Audit information collection System (internal vs. external)As specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.7 Notification to the subject cause of the eventAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.4.8 Vulnerability analysisAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.5 INFORMATION AND RECORDS FILE

5.5.1 Type of information and events recordedAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.5.2 Archive retention termAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.5.3 Archive protectionAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 21 of 36


5.5.4 Archive backup proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.5.5 Record time stamping requirementsAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.5.6 Audit information compilation system (internal vs. external)As specified in the CAEDICOM Certification Practices Statement (CPS)

5.5.7 Procedures to obtain and verify archived informationAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.6 CA KEY CHANGENot stipulated

5.7 RECOVERY IN CASE OF KEY COMPROMISE OR DISASTERAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.7.1 Alteration of hardware, software and/or data resourcesAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.7.2 The public key of an entity is revokedAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.7.3 The key of an entity is compromisedAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.7.4 Security installation following natural disaster or other types of disasterAs specified in the CAEDICOM Certification Practices Statement (CPS)

5.8 CESSATION OF A CAAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 22 of 36


6 TECHNICAL SECURITY CONTROLS

6.1 KEY PAIR GENERATION AND INSTALLATIONAt this point, we are always referring to the keys generated for certificates issued under the aegis of this Certification Policy. Information on the keys of the entities that make up the Certification Authority is in paragraph 6.1 of the CAEDICOM Certification Practice Statement (CPS).

6.1.1 Key pair generationThe key pairs for certificates issued under the scope of this Certification Policy software are generated in the device under control of the holder, usually a web browser. The only people who have access to the signature key are the owners of the same by possession and protectionof the machine making the request.

Private keys can be exportable and must be suitably protected by the end user.

6.1.2 Delivery of private key to end entityThe private key is generated by a process initiated by the owner per se in the software device in their possession. There is therefore no transfer of private key.

6.1.3 Delivery of public key to certificate issuerThe public key to be certified is generated inside the cryptographic software or hardware device belonging to the holder and forwarded to the CAEDICOM PKI, forming part of a request in PKCS#10 format, digitally signed with the private key corresponding to the public key for which certification is requested.

6.1.4 CA public key delivery to the usersAs specified in the CAEDICOM Certification Practices Statement (CPS)

6.1.5 Key sizeThe size of the keys to the certificates issued under the scope of this Certification Policy is at least 2048 bits.

6.1.6 Public key generation parametersThe parameters used are defined in cryptographic suite 001 specified in document

ETSI SR 002 176 “Electronic Signatures and Infrastructures (ESI); Algorithms and Parametersfor Secure Electronic Signature” v.2.1.1.

Signature algorithm parameters RSA MinModLen=2048

Key generation algorithm rsagen1

Cryptographic padding method emsa-pkcs1-v1_5

Hash function sha256

Page 23 of 36


6.1.7 Parameter quality checkThe parameters used are defined in cryptographic suite 001 specified in document ETSI SR 002176 “Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for SecureElectronic Signature”.

6.1.8 Key generation hardware/softwareThe key pair is generated in the software or hardware device which is in the sole possession of the holder. The only persons with access to the signature keys are the owners of the same by possession and protection of the equipment where they are kept.

6.1.9 Key usage purposesKeys defined by this policy shall be used for the purposes described in section 1.3 of this document.

The detailed definition of the certificate profile and uses of the keys is in section 7 of this document.

It must be taken into account that the efficacy of constraints based on extensions of certificatessometimes depends on the operativity of IT applications not manufactured or controlled by CAEDICOM.

6.2 PRIVATE KEY PROTECTIONAt this point, we are always referring to the keys generated for certificates issued under the aegis of this Certification Policy. Information on the keys of the entities that make up the Certification Authority is in paragraph 6.2 of the CAEDICOM Certification Practice Statement (CPS).

6.2.1 Standards for cryptographic modulesNot applicable.

6.2.2 Multi-person private key controlThe private keys for signature certificates issued under the scope of this Certification Policy are under the exclusive control of the holders of the same.

6.2.3 Private key custodyThe private keys for signature certificates issued under the scope of this Certification Policy areunder the exclusive control of the holders of the same, CAEDICOM therefore has no custodyover private keys associated with this policy.

6.2.4 Private key security copyPrivate keys can be exportable and must be properly protected by the holder.

Page 24 of 36


6.2.5 Private key archivePrivate keys for signature certificates issued under the scope of this Certification Policy are under the exclusive control of the holders of the same.

6.2.6 Private key activation methodNot applicable.

6.2.7 Private key deactivation methodNot applicable.

6.2.8 Private key destruction methodIn general terms, destruction must always be preceded by revocation of the certificate associated with the key, if this were still effective.

6.3 OTHER KEY PAIR MANAGEMENT ASPECTS

6.3.1 Public key archiveAs specified in the CAEDICOM Certification Practices Statement (CPS)

6.3.2 Public and private key usage periodsCertificates issued under this policy are valid for 825 days. The key pair used to issue certificates is created for each issuance, and hence is also valid for 825 days.

Expiry will automatically cause the invalidation of Certificates, originating the permanentcessation of its operability according to its usage and, consequently, of the certification serviceprovision.

6.4 ACTIVATION DATA

6.4.1 Activation data generation and activationThe key pair is generated by the holder himself in the software device. Control of the keys is the responsibility and obligation of the holder all times.

6.4.2 Activation data protectionThe certificate holder is responsible for protection of their own private key activation data

6.4.3 Other activation data aspectsNot stipulated.

Page 25 of 36


6.5 IT SECURITY CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

6.6 SERVICE LIFE SECURITY CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

6.7 NETWORK SECURITY CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

6.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLSAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 26 of 36


7 CERTIFICATE PROFILES AND REVOKED CERTIFICATE LIST

7.1 CERTIFICATE PROFILEThe outline of the TLS certificates cited in this policy was performed according to the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-TrustedCertificates specifications.

No information relating to the holder shall be included in the certificate without having been suitably verified.

7.1.1 Version numberThe public identity certificates issued by the Subordinate CA use the X.509 standard, version 3 (X.509 v3).

7.1.2 Certificate extensions and structureThe extensions that will be included in the certificate are listed below, describing the contents in each case.

7.1.2.1 VersionX.509 v3.

7.1.2.2 Serial NumberRandom serial number assigned by the Certification Authority with at least 8 bytes of entropy.

7.1.2.3 Signature AlgorithmSHA1withRSAEncryption.

7.1.2.4 Issuer Distinguished Name CN=CAEDICOM01, serialNumber=B96490867, O=EDICOM, L=Calle Charles Robert Darwin 8 -46980 - Paterna, C=ES

7.1.2.5 Validity (not before / not after)Certificates issued under this policy have a maximum validity period of 825 days.

7.1.2.6 Subject Public Key InfoKey type: RSA

Length: 2048 bits.

7.1.2.7 Subject Distinguished NameThis extension includes the certificate details on the holder, as well as the server domain whereindicated, e-mail, etc.

All attributes included as holder information must have been duly verified beforehand by the CAEDICOM Registration Authority.

No optional attribute may have a value indicating null or not applicable, for example a dash '-', blank space ' ', underscore '_', or others. If no value is verified, said attribute will simply not appear.

Page 27 of 36

https://cabforum.org/documents/#Baseline-Requirements

https://cabforum.org/documents/#Baseline-Requirements


7.1.2.7.1 TLS Server Certificate

Common Name (CN) OID 2.5.4.3 → FQDN (server.domain), example www.edicom.es. REQUIRED

Organization (O) OID 2.5.4.10 → Organization. Applicant organization or company. OPTIONAL

Organization Unit (OU) OID 2.5.4.11 → Organization Unit. Department within theapplicant/holder company. If the organization (O) appears, it is OPTIONAL, otherwise it isPROHIBITED.

Country (C) OID 2.5.4.6 → Subscriber country. If the organization (O) appears, it is REQUIRED, otherwise it is OPTIONAL.Locality (L) OID 2.5.4.7 → Subscriber locality. If the organization (O) appears, it is REQUIRED, otherwise it is PROHIBITED.

7.1.2.7.2 TLS Client Certificate

Common Name (CN) OID 2.5.4.3 → Name and surnames of the certificate owner/holder.Optionally, e-mail protection certificates for which no verification checks on the holder’sidentity are carried out may contain the text “CAEDICOM e-mail certificate”.

Organization (O) OID 2.5.4.10 → Organization. Applicant organization or company. it isOPTIONAL.

Organization Unit (OU) OID 2.5.4.11 → Department within the applicant/holder company. If theorganization (O) appears, it is OPTIONAL, otherwise it is PROHIBITED.

Country (C) OID 2.5.4.6 → Subscriber country. If the organization (O) appears, it is REQUIRED,otherwise it is PROHIBITED.

Locality (L) OID 2.5.4.7 → Subscriber locality. If the organization (O) appears, it is REQUIRED,otherwise it is PROHIBITED.

7.1.2.8 Subject Alternative NamesExtension always present, the content depends on the type of holder.

7.1.2.8.1 TLS Server certificate:

DNS Name → FQDN (server.domain), example www.edicom.es. REQUIRED.

7.1.2.8.2 TLS Client certificate:

RFC 822 Name → Certificate holder e-mail. REQUIRED.

7.1.2.9 Subject Key IdentifierCertificate public key identifier

7.1.2.10 Authority Key IdentifierIdentifier of the public key associated with the private key of the CA used to sign this certificate.

7.1.2.11 Basic ConstraintsExtension not present.

7.1.2.12 Key UsageCritical extension. The certificates issued under this policy will have the following valuesdepending on the certificate type:

• TLS Server Certificate: Digital Signature, Key Encipherment

• TLS Client Certificate: Digital Signature, Key Encipherment, Data Encipherment, KeyAgreement

Page 28 of 36

http://www.edicom.es/


7.1.2.13 Certificate PoliciesExtension always present, Non-critical extension. Content:

• PolicyIdentifier: 1.3.6.1.4.1.30051.2.3.2.7

• CPSUri: http://acedicom.edicomgroup.com

• UserNotice: Certificate Policy for TLS Client / Server.

7.1.2.14 Extended Key UsagePresent with the following values depending on the certificate type:

• TLS Server Certificate: TLS Client Authentication, TLS Server Authentication

• TLS Client Certificate: TLS Client Authentication, Email Protection

7.1.2.15 CRL Distribution PointsNon-critical extension, with the following content:

http://acedicom.edicomgroup.com/caedicom01.crl

7.1.2.16 Authority Information AccessNon-critical extension, with the following content:

CA Issuers → http://acedicom.edicomgroup.com/certs/caedicom01.cer

OCSP → http://ocsp.acedicom.edicomgroup.com/caedicom01

7.1.3 Object identifiers (OID) of algorithmsAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.1.4 Name formatsAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.1.5 Name constraintsAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.1.6 Certification Policy Object Identifier (OID)The Object Identifier (OID) defined by CAEDICOM to identify this policy is:1.3.6.1.4.1.30051.2.3.2.7

7.1.7 “Policy Constraints” extension useThe “Policy Constraints” extension is not used in the certificates issued under the present To Because Policy.

7.1.8 Policy qualifier syntax and semanticsNot stipulated.

Page 29 of 36


7.2 CRL PROFILE

7.2.1 Version numberAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.2.2 CRL and extensionsAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.3 REVOKED CERTIFICATE LIST

7.3.1 Time limit of certificates in CRLsAs specified in the CAEDICOM Certification Practices Statement (CPS)

7.4 OCSP PROFILEAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 30 of 36


8 CONFORMITY AUDIT

8.1 FREQUENCY OF CONFORMITY CHECKS FOR EACH ENTITYAs specified in the CAEDICOM Certification Practices Statement (CPS)

8.2 AUDITOR IDENTIFICATION/QUALIFICATIONAs specified in the CAEDICOM Certification Practices Statement (CPS)

8.3 RELATION BETWEEN AUDITOR AND ENTITY AUDITEDAs specified in the CAEDICOM Certification Practices Statement (CPS)

8.4 TOPICS COVERED BY CONFORMITY AUDITAs specified in the CAEDICOM Certification Practices Statement (CPS)

8.5 ACTIONS TO BE TAKEN AS A RESULT OF A DEFICIENCYAs specified in the CAEDICOM Certification Practices Statement (CPS)

8.6 COMMUNICATION OF RESULTSAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 31 of 36


9 COMMERCIAL AND LEGAL REQUIREMENTS

9.1 TARIFFS

9.1.1 Certificate issue or renewal feesThe issuing of digital certificates under this certification policy is subject to rates set byEDICOM.

The fees for issuance and renewal of each certificate are specified in the CAEDICOM websitehttp://acedicom.edicomgroup.com

9.1.2 Certificate access feesAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.1.3 Fees for access to status or revocation informationAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.1.4 Fees for other services such as information on policiesAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.1.5 Refund policyAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.2 FINANCIAL STANDING

9.2.1 Indemnification to third parties trusting certificates issued by CAEDICOMAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.2.2 Fiduciary relationsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.2.3 Administrative processesAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 32 of 36


9.3 CONFIDENTIALITY POLICY

9.3.1 Confidential informationAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.3.2 Non-confidential informationAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.3.3 Disclosure of certificate revocation /suspension informationAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4 PERSONAL DATA PROTECTIONAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.1 Personal Data Protection PlanAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.2 Information deemed privateAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.3 Information not deemed privateAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.4 ResponsibilitiesAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.5 Consent given for personal data useAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.6 Communication of information to administrative and/or judicial authoritiesAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.4.7 Other information disclosure situationsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.5 INTELLECTUAL PROPERTY RIGHTSAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 33 of 36


9.6 OBLIGATIONS AND CIVIL RESPONSIBILITY

9.6.1 Obligations of the Certification EntityAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.6.2 Registration Authority ObligationsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.6.3 Subscriber obligations.As specified in the CAEDICOM Certification Practices Statement (CPS)

9.6.4 Obligations of third parties trusting certificates issued by CAEDICOMAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.6.5 Repository obligationsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.7 GUARANTEE WAIVERSAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.8 RESPONSIBILITY LIMITATIONS

9.8.1 Guarantees and limitations of guaranteesAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.8.2 DisclaimerAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.8.3 Loss limitationsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.9 TERM AND CONCLUSION

9.9.1 TermAs specified in the CAEDICOM Certification Practices Statement (CPS)

Page 34 of 36


9.9.2 ConclusionAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.9.3 SurvivalAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.10 NOTIFICATIONSAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.11 MODIFICATIONSAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.11.1 Change specification proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.11.2 Publication and notification proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.11.3 Certification Practice Statement approval proceduresAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.12 RESOLUTION OF CONFLICTS

9.12.1 Extrajudicial resolution of conflictsAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.12.2 Competent jurisdiction.As specified in the CAEDICOM Certification Practices Statement (CPS)

9.13 APPLICABLE LEGISLATIONAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.14 COMPLIANCE WITH APPLICABLE LAWAs specified in the CAEDICOM Certification Practices Statement (CPS)

9.15 DIVERSE CLAUSES.As specified in the CAEDICOM Certification Practices Statement (CPS)

Page 35 of 36

Annexe I: Certificate revocation request form

Page 36 of 36

Certification Policy for TLS Server and Client certificate · Certification Policy for TLS Server and Client certificate OID: 1.3.6.1.4.1.30051.2.3.2.7 Edicom Capital, S.L. Calle

Documents