ipcorenetworks.blogspot.com/2...
___________________________________________________________________________________
CCNP Enterprise Playlist: • CCNP Security Training
___________________________________________________________________________________
This specification defines a protocol, Simple Certificate Enrolment Protocol (SCEP), for certificate management and certificate and CRL queries. While widely deployed (see the Background Notes section for more on the history behind SCEP and the nearly two decade-long progress of this standard), this protocol omits some certificate management features, e.g. certificate revocation transactions, which may enhance the security achieved in a PKI. The IETF protocol suite currently includes two further certificate management protocols with more comprehensive functionality, Certificate Management Protocol (CMP) and Certificate Management over CMS (CMC). Environments that do not require interoperability with SCEP implementations MAY consider using the above-mentioned certificate management protocols, however anyone considering this step should be aware that the high level of complexity of these two protocols has resulted in serious interoperability problems and corresponding lack of industry support. SCEP's simplicity, while being a drawback in terms of its slightly restricted functionality, also makes deployment relatively straightforward, so that it enjoys widespread support and ready interoperability across a range of platforms. While implementers are encouraged to investigate one of the more comprehensive alternative certificate management protocols in addition to the protocol defined in this specification, anyone wishing to deploy them should proceed with caution, and consider support and interoperability issues before committing to their use.
The SCEP protocol supports the following general operations:
CA public key distribution.
Certificate enrolment and issue.
Certificate renewal.
Certificate query.
CRL query.
SCEP makes extensive use of CMS and PKCS #10.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
2. SCEP Overview
This section provides a high level overview of the functionality of SCEP.
2.1. SCEP Entities
The entity types defined in SCEP are a client requesting a certificate and a Certificate Authority (CA) that issues the certificate. These are described in the following sections.
2.1.1. Client
A client MUST have the following information locally configured:
The CA fully qualified domain name or IP address.
The CA HTTP CGI script path (this usually has a default value, see Section 4.1).
The identifying information that is used for authentication of the CA in Section 4.2.1, typically a certificate fingerprint.
2.1.2. Certificate Authority
A SCEP CA is the entity that signs client certificates. A CA MAY enforce any arbitrary policies and apply them to certificate requests, and MAY reject a request for any reason.
Since the client is expected to perform signature verification and optionally encryption using the CA certificate, the keyUsage extension in the CA certificate MUST indicate that it is valid for digitalSignature and keyEncipherment (if available) alongside the usual CA usages of keyCertSign and/or cRLSign.
2.2. CA Certificate Distribution
If the CA certificate(s) have not previously been acquired by the client through some other means, the client MUST retrieve them before any PKI operation (Section 3) can be started. Since no public key has yet been exchanged between the client and the CA, the messages cannot be secured using CMS, and the data is instead transferred in the clear.
If an intermediate CA is in use, a certificates-only CMS Signed-Data message with a certificate chain consisting of all CA certificates is returned. Otherwise the CA certificate itself is returned.
The CA certificate MAY be provided out-of-band to the client. Alternatively, the CA certificate fingerprint MAY be used to authenticate a CA Certificate distributed by the GetCACert response (Section 4.2) or via HTTP certificate-store access. The fingerprint is created by calculating a SHA-256 hash over the whole CA certificate (for legacy reasons, a SHA-1 hash may be used by some implementations).
After the client gets the CA certificate, it SHOULD authenticate the certificate by comparing its fingerprint with the locally configured, out-of-band distributed, identifying information, or by some equivalent means such as a direct comparison with a locally-stored copy of the certificate.
tools.ietf.org/id/draft-gutma...
#oscp #scep #pki