Certificate policy: Difference between revisions
cat:Key management |
VulcanSphere (talk | contribs) Adding local short description: "Document that describe different entities of public key infrastructure", overriding Wikidata description "document which aims to state what are the different entities of a public key infrastructure, their roles and their duties; published in the PKI perimeter" (Shortdesc helper) |
||
| (30 intermediate revisions by 25 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Document that describe different entities of public key infrastructure}} |
|||
'''''Certificate policies''''' are, in the [[X.509]] version 3 [[digital certificate]] standard, the applications which a certifying [[Certificate authority|CA]] declares a specific public/private key fit for. Typical certificate policies include: |
|||
A '''certificate policy''' (CP) is a document which aims to state what are the different entities of a [[public key infrastructure]] (PKI), their roles and their duties. This document is published in the PKI perimeter. |
|||
When in use with [[X.509]] [[public key certificate|certificates]], a specific field can be set to include a link to the associated certificate policy. Thus, during an exchange, any relying party has an access to the assurance level associated with the certificate, and can decide on the [[trust metric|level of trust]] to put in the certificate. |
|||
* [[digital signature]] of [[e-mail]], aka [[S/MIME]] |
|||
* [[encryption]] of data |
|||
* verification of Web site identity |
|||
* further issuance of certificates (delegation of authority) |
|||
== RFC 3647 == |
|||
The framework and intention of certificate policies are described in [[RFC]] [http://www.ietf.org/rfc/rfc2527.txt 2527], where [[Certification Practice Statements]] (CPS) are also described. |
|||
The reference document for writing a certificate policy is, {{as of|2010|12|lc=y}}, {{IETF RFC|3647}}. The RFC proposes a framework for the writing of certificate policies and [[Certification Practice Statement]]s (CPS). The points described below are based on the framework presented in the RFC. |
|||
== Main points == |
|||
== Critical vs. non-critical policies == |
|||
=== Architecture === |
|||
According to the RFC, policies may be marked as critical or non-critical. This distinction is largely to limit the [[liability]] of the CA. Policies which are marked as critical should be the only ones a digital certificate is used for. That is, if a critical certificate policy designates a certificate for use in digitally signing electronic communication, it should not be used for [[encryption]]. If it is in fact used for encryption and the confidentiality of the encrypted data is compromised, the CA has limited liability. |
|||
The document should describe the general architecture of the related PKI, present the different entities of the PKI and any exchange based on certificates issued by this very same PKI. |
|||
=== Certificate uses === |
|||
An important point of the certificate policy is the description of the authorized and prohibited certificate uses. When a certificate is issued, it can be stated in its attributes what use cases it is intended to fulfill. For example, a certificate can be issued for [[digital signature]] of [[email|e-mail]] (aka [[S/MIME]]), [[encryption]] of data, [[authentication]] (e.g. of a [[Web server]], as when one uses [[HTTP Secure|HTTPS]]) or further issuance of certificates (delegation of authority). Prohibited uses are specified in the same way. |
|||
=== Naming, identification and authentication === |
|||
The document also describes how certificates names are to be chosen, and besides, the associated needs for [[identity (philosophy)|identification]] and [[authentication]]. When a certification application is filled, the [[certification authority]] (or, by delegation, the [[registration authority]]) is in charge of checking the information provided by the applicant, such as his identity. This is to make sure that the CA does not take part in an [[identity theft]]. |
|||
=== Key generation === |
|||
The [[key generation|generation]] of the [[key (cryptography)|key]]s is also mentioned in a certificate policy. Users may be allowed to generate their own keys and submit them to the CA for generation of an associated certificate. The PKI may also choose to prohibit user-generated keys, and provide a separated and probably more secure way of generating the keys (for example, by using a [[hardware security module]]). |
|||
=== Procedures === |
|||
The different procedures for certificate application, issuance, acceptance, renewal, re-key, modification and revocation are a large part of the document. These procedures describe how each actor of the PKI has to act in order for the whole assurance level to be accepted. |
|||
=== Operational controls === |
|||
Then, a chapter is found regarding physical and procedural controls, [[audit]] and logging procedures involved in the PKI to ensure [[data integrity]], [[availability]] and [[confidentiality]]. |
|||
=== Technical controls === |
|||
This part describes what are the technical requirements regarding key sizes, protection of [[public-key cryptography|private keys]] (by use of [[key escrow]]) and various types of controls regarding the technical environment (computers, network). |
|||
=== Certificate revocation lists === |
|||
Those [[Certificate revocation list|lists]] are a vital part of any public key infrastructure, and as such, a specific chapter is dedicated to the description of the management associated with these lists, to ensure consistency between certificate status and the content of the list. |
|||
=== Audit and assessments === |
|||
The PKI needs to be audited to ensure it complies with the rules stated in its documents, such as the certificate policy. The procedures used to assess such [[regulatory compliance|compliance]] are described here. |
|||
=== Other === |
|||
This last chapter tackles all remaining points, by example all the PKI-associated legal matters. |
|||
== References == |
== References == |
||
* {{IETF RFC|3647}} |
|||
{{TLS/SSL}} |
|||
[http://www.ietf.org/rfc/rfc2527.txt RFC 2527] |
|||
[[Category:Key management]] |
[[Category:Key management]] |
||
[[Category:Public key infrastructure]] |
|||
Latest revision as of 05:51, 27 April 2022
A certificate policy (CP) is a document which aims to state what are the different entities of a public key infrastructure (PKI), their roles and their duties. This document is published in the PKI perimeter.
When in use with X.509 certificates, a specific field can be set to include a link to the associated certificate policy. Thus, during an exchange, any relying party has an access to the assurance level associated with the certificate, and can decide on the level of trust to put in the certificate.
RFC 3647[edit]
The reference document for writing a certificate policy is, as of December 2010[update], RFC 3647. The RFC proposes a framework for the writing of certificate policies and Certification Practice Statements (CPS). The points described below are based on the framework presented in the RFC.
Main points[edit]
Architecture[edit]
The document should describe the general architecture of the related PKI, present the different entities of the PKI and any exchange based on certificates issued by this very same PKI.
Certificate uses[edit]
An important point of the certificate policy is the description of the authorized and prohibited certificate uses. When a certificate is issued, it can be stated in its attributes what use cases it is intended to fulfill. For example, a certificate can be issued for digital signature of e-mail (aka S/MIME), encryption of data, authentication (e.g. of a Web server, as when one uses HTTPS) or further issuance of certificates (delegation of authority). Prohibited uses are specified in the same way.
Naming, identification and authentication[edit]
The document also describes how certificates names are to be chosen, and besides, the associated needs for identification and authentication. When a certification application is filled, the certification authority (or, by delegation, the registration authority) is in charge of checking the information provided by the applicant, such as his identity. This is to make sure that the CA does not take part in an identity theft.
Key generation[edit]
The generation of the keys is also mentioned in a certificate policy. Users may be allowed to generate their own keys and submit them to the CA for generation of an associated certificate. The PKI may also choose to prohibit user-generated keys, and provide a separated and probably more secure way of generating the keys (for example, by using a hardware security module).
Procedures[edit]
The different procedures for certificate application, issuance, acceptance, renewal, re-key, modification and revocation are a large part of the document. These procedures describe how each actor of the PKI has to act in order for the whole assurance level to be accepted.
Operational controls[edit]
Then, a chapter is found regarding physical and procedural controls, audit and logging procedures involved in the PKI to ensure data integrity, availability and confidentiality.
Technical controls[edit]
This part describes what are the technical requirements regarding key sizes, protection of private keys (by use of key escrow) and various types of controls regarding the technical environment (computers, network).
Certificate revocation lists[edit]
Those lists are a vital part of any public key infrastructure, and as such, a specific chapter is dedicated to the description of the management associated with these lists, to ensure consistency between certificate status and the content of the list.
Audit and assessments[edit]
The PKI needs to be audited to ensure it complies with the rules stated in its documents, such as the certificate policy. The procedures used to assess such compliance are described here.
Other[edit]
This last chapter tackles all remaining points, by example all the PKI-associated legal matters.