Выпуск 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

13. Certificate Revocation and Status Checking

13.1 Revocation

13.1.1 Revocation Request

As specified in BR Section 4.9.3.

13.1.2 Certificate Problem Reporting

The CA MUST provide Anti-Malware Organizations, Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions on how they can report suspected Private Key Compromise, Certificate misuse, Certificates used to sign Suspect Code, Takeover Attacks, or other types of possible fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA MUST publicly disclose the instructions on its website.

13.1.3 Investigation

The CA MUST begin investigating Certificate Problem Reports within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:

1. The nature of the alleged problem (adware, spyware, malware, software bug, etc.),

2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber,

3. The entity making the report (for example, a notification from an Anti-Malware Organization or law enforcement agency carries more weight than an anonymous complaint), and

4. Relevant legislation.

13.1.4 Response

The CA MUST maintain a continuous 24x7 ability to communicate with Anti-Malware Organizations, Application Software Suppliers, and law enforcement agencies and respond to high- priority Certificate Problem Reports, such as reports requesting revocation of Certificates used to sign malicious code, fraud, or other illegal conduct.

The CA MUST acknowledge receipt of plausible notices about Suspect Code signed with a certificate issued by the CA or a Subordinate CA.

13.1.5 Reasons for Revoking a Subscriber Certificate

A CA MUST revoke a Code Signing Certificate in any of the four circumstances: (1) the Application Software Supplier requests revocation, (2) the subscriber requests revocation, , (3) a third party provides information that leads the CA to believe that the certificate is compromised or is being used for Suspect Code, or (4) the CA otherwise decides that the certificate should be revoked. This section describes the CA’s obligations for each scenario. Revocation Based on an Application Software Supplier’s Request

If the Application Software Supplier requests the CA revoke because the Application Software Supplier believes that a Certificate attribute is deceptive, or that the Certificate is being used for malware, bundle ware, unwanted software, or some other illicit purpose, then the Application Software Supplier may request that the CA revoke the certificate.

Within two (2) business days of receipt of the request, the CA MUST either revoke the certificate or inform the Application Software Supplier that it is conducting an investigation.

If the CA decides to conduct an investigation, it MUST inform the Application Software Supplier whether or not it will revoke the Certificate, within two (2) business days.

If the CA decides that the revocation will have an unreasonable impact on its customer, then the CA MUST propose an alternative course of action to the Application Software Supplier based on its investigation. Revocation Based on the Subscriber’s Request

The CA MUST revoke a Code Signing Certificate within one (1) business day if the Subscriber requests in writing that the CA revoke the Certificate or notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization. Revocation Based on Reported or Detected Compromise or Use in Malware

For all incidents involving malware, CAs SHALL revoke the Code Signing Certificate in accordance with and within the following maximum timeframes. Nothing herein prohibits a CA from revoking a Code Signing Certificate prior to these timeframes.

1)The CA MUST contact the software publisher within one (1) business day after the CA is made aware of the incident.

2)The CA MUST determine the volume of relying parties that are impacted (e.g., based on OCSP logs) within 72 hours after being made aware of the incident. 3)The CA MUST request the software publisher send an acknowledgement to the CA within 72 hours of receipt of the request.
a.If the publisher responds within 72 hours, the CA and publisher MUST determine a “reasonable date” to revoke the certificate based on discussions with the CA.
b.If CA does not receive a response, the CA must notify the publisher that the CA will revoke in 7 days if no further response is received.
i.If the publisher responds within 7 days, the CA and the publisher will determine a “reasonable date” to revoke the certificate based on discussion with the CA.
ii.If no response is received after 7 days, the CA must revoke the certificate except if the CA has documented proof (e.g., OCSP logs) that this will cause significant impact to the general public.

A CA revoking a Certificate because the Certificate was associated with signed Suspect Code or other fraudulent or illegal conduct SHOULD provide all relevant information and risk indicators to other CAs or industry groups. The CA SHOULD indicate whether its investigation found that the Suspect Code was a false positive or an inadvertent signing.

13.1.6 Reasons for Revoking a Subordinate CA Certificate

As specified in BR Section

13.1.7 Certificate Revocation Date

When revoking a Certificate, the CA SHOULD work with the Subscriber to estimate a date of when the revocation should occur in order to mitigate the impact of revocation on validly signed Code. For key compromise events, this date SHOULD be the earliest date of suspected compromise.

13.2 Certificate Status Checking

13.2.1 Mechanisms

In addition to the requirements specified in BR Section 4.9.7 through 4.9.10, CAs MUST provide up- to-date revocation status information. CAs MUST provide OCSP responses for Code Signing Certificates and Timestamp Certificates for the time period specified in their CPS, which MUST be at least 10 years after the expiration of the certificate. If a CA issues CRLs, the serial number of a revoked certificate MUST remain on the CRL for at least 10 years after the expiration of the certificate. Application Software Suppliers MAY require the CA to support a longer life-time in its contract with the CA. If the CA wishes to stop supporting validation of Code Signing Certificates or Timestamp Certificates prior to the date specified in its Certificate Policy/Certificate Practice Statement, the CA MUST give 90 days’ prior notice to all Application Software Suppliers relying on the root certificate and permit the Application Software Suppliers sufficient time to take appropriate action as determined by the Application Software Supplier.

If a Code Signing Certificate contains the Lifetime Signing OID, the Signature becomes invalid when the Code Signing Certificate expires, even if the Signature is timestamped. Because the Lifetime Signing OID is intended to be used with test purposes only, a CA MAY cease maintaining revocation information for a Code Signing Certificate with the Lifetime Signing OID after the Code Signing Certificate expires.

Whenever practical, Platforms should check the revocation status of the Certificates that they rely upon. However, this is not always practical, such as when signed Code is loaded earlier in the boot sequence than the network communication stack.

In the timestamp model, the Platform should check the revocation status at the time the time-stamp was applied. In addition to checking revocation status, where practical, Platforms should consult blacklists for Suspect Code.

ACertificate MAY have a one-to-one relationship or one-to-many relationship with the signed Code. Regardless, revocation of a Certificate may invalidate the signatures on all those signed Objects, some of which could be perfectly sound. Because of this, the CA MAY specify a revocation date in a CRL or OCSP response to time-bind the set of software affected by the revocation, and software should continue to treat objects containing a time-stamp dated before the revocation date as valid.

Because some Application Software Suppliers utilize non-standard revocation mechanisms, CAs MUST, if requested by the Application Software Supplier and using a method of communication specified by the Application Software Vendor, notify the Application Software Supplier whenever the CA revokes a Code Signing Certificate because (i) the CA mis-issued the Certificate, (ii) the Certificate was used to sign Suspect Code, or (iii) there is a suspected or actual compromise of the Applicant’s or CA’s Private Key.

13.2.2 Repository

The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of Code Signing and Timestamp Certificates issued by the CA.

For the status of Code Signing Certificates:

1. If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field; and

2. The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.

For the status of Timestamp Certificates:

1. The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Timestamp Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field; and

2. The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate.

The CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements. 

 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-2023 adgrafics