Выпуск Code Signing сертификата-Требования CAB Forum для верификации организации Украина купить сертификат 

Правила выпуска Code Signing сертификатов
для верификации автора и защиты кода от изменения

☎ +380672576220

Code Sign
Email Smime
PDF и Word

Правила CodeSign сертификатов
1. Scope
2. Purpose
3. References
4. Definitions
5. Abbreviations and Acronyms
6. Conventions
7. Certificate Warranties and Representations
7.1Certificate Beneficiaries
7.2 Certificate Warranties
7.3 Applicant Warranty
8. Community and Applicability
8.1 Compliance
8.2 Certificate Policies
8.2.1 Implementation
8.2.2 Disclosure
8.3 Commitment to Comply
8.4 Trust model
9. Certificate Content and Profile
9.1 Issuer Information
9.2 Subject Information
9.2.1 Subject Alternative Name Extension
9.2.2 Subject Common Name Field
9.2.3 Subject Domain Component Field
9.2.4 Subject Distinguished Name Fields
9.2.5 Reserved
9.2.6 Subject Organizational Unit Field
9.2.7 Reserved
9.2.8 Other Subject Attributes
9.3 Certificate Policy Identification
9.3.1 Certificate Policy Identifiers
9.3.2 Root CA Requirements
9.3.3 Subordinate CA Certificates
9.3.4 Subscriber Certificates
9.4 Maximum Validity Period
9.5 Subscriber Public Key
9.6 Certificate Serial Number
9.7 Reserved
9.8 Reserved
10. Certificate Request
10.1 Documentation Requirements
10.2 Certificate Request
10.2.1 General
10.2.2 Request and Certification
10.2.3 Information Requirements
10.2.4 Subscriber Private Key
10.3 Subscriber Agreement
10.3.1 General
10.3.2 Agreement Requirements
10.3.3 Service Agreement Requirements for Signing Authorities
11. Verification Practices
11.1 Verification of Organizational Applicants
11.1.1 Organization Identity and Address
11.1.2 DBA/Tradename
11.1.3 Requester Authority
11.2 Verification of Individual Applicants
11.2.1 Individual Identity
11.2.2 Authenticity of Identity
11.3 Age of Certificate Data
11.4 Denied List
11.5 High Risk Certificate Requests
11.6 Data Source Accuracy
11.7 Processing High Risk Applications
11.8 Due Diligence
12. Certificate Issuance by a Root CA
13. Certificate Revocation and Status Checking
13.1 Revocation
13.1.1 Revocation Request
13.1.2 Certificate Problem Reporting
13.1.3 Investigation
13.1.4 Response
13.1.5 Reasons for Revoking a Subscriber Certificate
13.1.6 Reasons for Revoking a Subordinate CA Certificate
13.1.7 Certificate Revocation Date
13.2 Certificate Status Checking
14. Employees and Third Parties
14.1 Trustworthiness and Competence
14.2 Delegation of Functions to Registration Authorities and Subcontractors
14.2.1 General
14.2.2 Compliance Obligation
14.2.3 Allocation of Liability
15. Data Records
16. Data Security and Private Key Protection
16.1 Timestamp Authority Key Protection
16.2 Signing Service Requirements
16.3 Subscriber Private Key Protection
17. Audit (39)
17.1 Eligible Audit Schemes
17.2 Audit Period
17.3 Audit Report
17.4 Pre-Issuance Readiness Audit
17.5 Audit of Delegated Functions
17.6 Auditor Qualifications
17.7 Key Generation Ceremony
18. Liability and Indemnification
Appendix A - Minimum Cryptographic Algorithm and Key Size Requirements
Appendix B - Certificate Extensions (Normative)
Appendix C - User Agent Verification (Normative)
Appendix D - High Risk Regions of Concern

10. Certificate Request

10.1 Documentation Requirements

As specified in BR Section 5.4.1.

10.2 Certificate Request

10.2.1 General

Prior to the issuance of a Certificate, the CA MUST obtain from the Applicant a request for a certificate in a form prescribed by the CA and that complies with these Requirements. One request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 11.3, provided that each Certificate is supported by a valid, current request signed by the appropriate Applicant Representative on behalf of the Applicant. The request MAY be made, submitted and/or signed electronically.

Prior to signing an Object, the Signing Authority MUST obtain from the Applicant a signing request in a form prescribed by the Signing Authority and that complies with these Requirements. One signing request MAY suffice for multiple signatures for the same Applicant, subject to the requirements specified herein. The signing request MAY be made, submitted and/or signed electronically.

10.2.2 Request and Certification

The certificate requestor signing request MUST contain a request from, or on behalf of, the Applicant and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.

10.2.3 Information Requirements

The certificate request or signing request MAY include all factual information about the Applicant necessary to issue the Certificate or sign the Object, and such additional information as is necessary for the CA or Signing Authority to obtain from the Applicant in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement. In cases where the certificate request or signing request does not contain all the necessary information about the Applicant, the CA or Signing Service MUST obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA or Signing Service MUST establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.

10.2.4 Subscriber Private Key

If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service’s secure infrastructure, then the entity generating the Private Key MUST either transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption or encrypt the Private Key with at least 128 bits of encryption strength. Allowed methods include using a 128-bit AES key to wrap the private key or storing the key in a PKCS 12 file encrypted with a randomly generated password of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols for transport.

For Certificates transported outside of a Signing Service’s secure infrastructure, the CA or Signing Service MUST require, by contract, each Subscriber to generate their own Private Key and protect the Private Key in accordance with Section 16.2 (“Private Key Protection”).

10.3 Subscriber Agreement

10.3.1 General

As specified in BR Section 9.6.3.

10.3.2 Agreement Requirements

The Applicant MUST make the following obligations and warranties through a Subscriber Agreement or Terms of Use:

1. Accuracy of Information: To provide accurate and complete information at all times in connection with the issuance of a Certificate, including in the Certificate Request and as otherwise requested by the CA.

2. Protection of Private Key: Where the key is available outside a Signing Service, to maintain sole control of, keep confidential, and properly protect, at all times in accordance with Section 16, the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement. The Subscriber MUST represent that it will generate and operate any device storing private keys in a secure manner, as described in a document of code signing best practices, which the CA MUST provide to the Subscriber during the ordering process. The CA MUST obligate the Subscriber to use passwords that are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols to transport private keys.

3. Private Key Reuse: To not apply for a Code Signing Certificate if the Public Key in the Certificate is or will be used with a non-Code Signing Certificate.

4. Use: To use the Certificate and associated Private Key only for authorized and legal purposes, including not using the Certificate to sign Suspect Code and to use the Certificate and Private Key solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use.

5. Compliance with Industry Standards: An acknowledgment and acceptance that the CA may modify the Subscriber Agreement or Terms of Use when necessary to comply with any changes in these Requirements or the Baseline Requirements.

6. Prevention of Misuse: To provide adequate network and other security controls to protect against misuse of the Private Key and that the CA will revoke the Certificate without requiring prior notification if there is unauthorized access to the Private Keys.

7. Acceptance of Certificate: Not to use the Certificate until after the Applicant, or an agent of Applicant, has reviewed and verified the Certificate contents for accuracy.

8. Reporting and Revocation: To promptly cease using a Certificate and its associated Private Key and promptly request that the CA revoke the Certificate if the Subscriber believes that (a) any information in the Certificate is, or becomes, incorrect or inaccurate,
(b) the Private Key associated with the Public Key contained in the Certificate was misused or compromised, or (c) there is evidence that the Certificate was used to sign Suspect Code.

9. Sharing of Information: An acknowledgment and acceptance that, if: (a) the Certificate or the Applicant is identified as a source of Suspect Code, (b) the authority to request the Certificate cannot be verified, or (c) the Certificate is revoked for reasons other than Subscriber request (e.g. as a result of private key compromise, discovery of malware, etc.), then the CA is authorized to share information about the Applicant, signed application, Certificate, and surrounding circumstances with other CAs or industry groups, including the CA/Browser Forum.

10. Termination of Use of Certificate: To promptly cease using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate.

11. Acknowledgment and Acceptance: An acknowledgement and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the Terms of Use or the Subscriber Agreement.

10.3.3 Service Agreement Requirements for Signing Authorities

The CA MUST contractually obligate each Signing Service to inform the CA if the Signing Service becomes aware (by whatever means) that the Signing Service has signed Suspect Code. The CA MUST require the Signing Service to request revocation of the affected Certificate and provide immediate notice to the CA if the Signing Service’s private key, or private key activation data, is compromised or believed to be compromised. The CA MUST revoke the affected Certificate upon request by the Signing Service or if the CA determines the Signing Service failed to notify the CA within 24 hours after identifying a private key compromise.

Signing Authorities MUST obtain the Subscriber’s commitment to:

1.Use such signing services solely for authorized purposes that comply with the Subscriber Agreement/Terms of Use, these Requirements, and all applicable laws,

2.Not knowingly submit software for signature that contains Suspect Code, and

3.Inform the Signing Service if it is discovered (by whatever means) that code submitted to the Signing Service for signature contained Suspect Code. 

 DV SSL OV Сертификаты подтверждающие только Домен OV SSL OV Сертификаты подтверждающие Домен и Организацию EV SSL EV Зеленые усиленные сертификаты с указанием названия Организации подтверждают Домен и Организацию WC SSL wildcard Сертификаты защищающие все субдомены. Класс DV OV и EV SAN SSL SAN Мульти доменные  сертификаты защищающие несколько FQDN Доменов. Класс DV OV и EV PRO SSL SGC PRO сертификаты с технологией  Server Gated Cryptography. Класс  OV и EV CodeSign Сертификаты для подписи приложений и програмного кода MS, Java. Класс  OV и EV Email Сертификаты для подписи емаил smime. Класс  DV OV PDF Сертификаты для подписи документов PDF. Класс  OV PV Wi-Fi Сертификаты DigiCert для IoT и Wi Fi IoT Сертификаты DigiCert для IIoT ALL Все сертификаты DigiCert Familie: thawte, GeoTrust, DigiCert Купить сертификат

NO russia - мы не осблуживаем резидентов из россии Copyright © 1997-2021 adgrafics