Difference between revisions of "Certificate Request"
From MgmtWiki
m (→Taxonomy) |
|||
| (9 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
| − | The Internet runs on [[Trust]] which is provided by [[Certificates]] which are provided by a [[Certificate Authority]] that is trusted by the [[User Agent]] which is typically a web [[Browser]]. | + | * The Internet runs on [[Trust]] which is provided by [[Certificates]] which are provided by a [[Certificate Authority]] that is trusted by the [[User Agent]] which is typically a web [[Browser]]. |
| + | * Client certificates where the primary reason for the create of the [[Public Key Infrastructure]] and the reason for Privacy Enhanced Mail ([[PEM]]). | ||
| + | * RPC 3280 and updates in RFC 9045 are the standards that created the [[Certificate Request]] as it is used today. | ||
| + | |||
| + | ===Taxonomy=== | ||
| + | |||
| + | * '''Version 1''' the original CSR spec which is still the only one supported by [[OpenSSL]]. It is not clear that it makes and difference as a V1 can be used to create a V3 certificate with extensions and uses. | ||
| + | * '''Version 3''' adds functionality for TPM attestation. | ||
==Solution== | ==Solution== | ||
| Line 13: | Line 20: | ||
*An IX509CertificateRequestPkcs7 must contain an IX509CertificateRequestPkcs10 object. The main advantage of wrapping a PKCS #10 request in a PKCS #7 message is the ability to add multiple signers. The PKCS #10 request is signed by the associated private key, and the PKCS #7 message that wraps the PKCS #10 request is also signed. This second signer uses the certificate being renewed (for a renewal request) or the enrollment agent certificate (for an enroll-on-behalf-of request). | *An IX509CertificateRequestPkcs7 must contain an IX509CertificateRequestPkcs10 object. The main advantage of wrapping a PKCS #10 request in a PKCS #7 message is the ability to add multiple signers. The PKCS #10 request is signed by the associated private key, and the PKCS #7 message that wraps the PKCS #10 request is also signed. This second signer uses the certificate being renewed (for a renewal request) or the enrollment agent certificate (for an enroll-on-behalf-of request). | ||
*You can create and enroll a stand-alone IX509CertificateRequestPkcs10 certificate request without wrapping it in an IX509CertificateRequestPkcs7 object. | *You can create and enroll a stand-alone IX509CertificateRequestPkcs10 certificate request without wrapping it in an IX509CertificateRequestPkcs7 object. | ||
| + | |||
==References== | ==References== | ||
===Other Material=== | ===Other Material=== | ||
| Line 21: | Line 29: | ||
[[Category: Trust]] | [[Category: Trust]] | ||
[[Category: Assurance]] | [[Category: Assurance]] | ||
| − | [[Category: | + | [[Category: Certificate]] |
| − | |||
Latest revision as of 11:48, 8 March 2023
Full Title
The first step for acquiring a certificate is to create a Certificate Request.
Context
- The Internet runs on Trust which is provided by Certificates which are provided by a Certificate Authority that is trusted by the User Agent which is typically a web Browser.
- Client certificates where the primary reason for the create of the Public Key Infrastructure and the reason for Privacy Enhanced Mail (PEM).
- RPC 3280 and updates in RFC 9045 are the standards that created the Certificate Request as it is used today.
Taxonomy
- Version 1 the original CSR spec which is still the only one supported by OpenSSL. It is not clear that it makes and difference as a V1 can be used to create a V3 certificate with extensions and uses.
- Version 3 adds functionality for TPM attestation.
Solution
Multiple Signers and the Microsoft IX509CertificateRequestPkcs7 interface
The IX509CertificateRequestPkcs7 interface represents a PKCS #7 certificate message syntax (CMS) object. PKCS #7 defines the format of messages sent to a certification or registration authority to request a public-key certificate. The IX509CertificateRequestPkcs7 interface can be confusing because its implementation does not perfectly mirror the way most security professionals think about the PKCS #7 standard. To avoid this confusion, keep the following points in mind:
- Although a PKCS #7 message is used to wrap a CMC request, an IX509CertificateRequestPkcs7 object cannot contain a IX509CertificateRequestCmc object. Instead, the IX509CertificateRequestCmc interface inherits and implements the IX509CertificateRequestPkcs7 interface. As implemented, a CMC request is therefore a PKCS #7 SignedData object that contains CMC content, a primary signature that is either null-signed or key-based, and zero or more certificate-based signatures. By contrast, a PKCS #7 request is a SignedData object that contains PKCS #10 content (see the next item in this list) and has exactly one certificate-based signature.
- An IX509CertificateRequestPkcs7 must contain an IX509CertificateRequestPkcs10 object. The main advantage of wrapping a PKCS #10 request in a PKCS #7 message is the ability to add multiple signers. The PKCS #10 request is signed by the associated private key, and the PKCS #7 message that wraps the PKCS #10 request is also signed. This second signer uses the certificate being renewed (for a renewal request) or the enrollment agent certificate (for an enroll-on-behalf-of request).
- You can create and enroll a stand-alone IX509CertificateRequestPkcs10 certificate request without wrapping it in an IX509CertificateRequestPkcs7 object.
References
Other Material
- The wiki page on Privacy Risk shares some content with this page as privacy risk is becoming a significant factor in Conduct Risk.
- The wiki page on Privacy Tolerance speaks to a particular area where Conduct Risk can help select an appropriate acceptance level for risk.
