certificate
Click on the red underlined text to get to the source
... PKI) components. For example, a
management protocol might be used between a Certification Authority
(CA) and a client system ...
... the entity to be named in the subject field of a certificate) and the
certification authority (i.e., the entity ...
... subject field of a certificate) and the
certification authority (i.e., the entity named in the issuer field
...
... entity named in the issuer field
of a certificate). A registration authority MAY also be involved in
PKI management ...
... entity named in the
subject field of a certificate; when we wish to distinguish the tools
and/or software used by the subject ...
... tools
and/or software used by the subject (e.g., a local certificate
management module) we will use the term "subject ...
... the PKI management operations use; for example, application software
is far more likely to know exactly which certificate extensions are
required than are human users. PKI management ...
... end
entities in the sense that they are sometimes named in the subject
field of a certificate or cross-certificate. Where appropriate, the
term "end-entity ...
... subject
field of a certificate or cross-certificate. Where appropriate, the
term "end-entity" will be used to refer to end entities ...
... available elsewhere). Implementations MAY use secure local storage
for more than this minimum (e.g., the end entity's own certificate or
application-specific information). The form of storage will also vary
...
... Though PSE formats are beyond the scope of this document (they are
very dependent on equipment, et cetera), a generic interchange format
for PSEs is defined here - a certification response message MAY be
used.
...
... Certification Authority ...
... entity named in the issuer
field of a certificate; when it is necessary to distinguish the
software or hardware tools ...
... Registration Authority (RA) separate from the
Certification Authority. The functions which the registration
authority may carry out will vary from case to case but MAY include
personal authentication ...
... RAs is an implementation issue (i.e., this
document specifies no special RA certification operation). We do not
mandate that the RA is certified by the CA ...
... RA is present. For example, for initial registration
and/or certification the subject may use its RA, but communicate
...
... PKI management must conform to the ISO 9594-8 standard and the
associated amendments (certificate extensions)
2. PKI management ...
... 7. PKI management protocols must support the publication of
certificates by the end-entity concerned, by an RA, or by a CA ...
... 8. PKI management protocols must support the production of
Certificate Revocation Lists (CRLs) by allowing certified end
entities to make requests for the revocation ...
... CRLs) by allowing certified end
entities to make requests for the revocation of certificates -
this must be done in such a way that the denial-of-service
attacks which are possible are not made simpler.
...
... no RA or end-entity equipment can assume that any certificate
issued by a CA will contain what was requested -- a CA ...
... CA will contain what was requested -- a CA may
alter certificate field values or may add, delete or alter
extensions according to its operating policy. In other words,
...
... RAs, and CAs) must be capable
of handling responses to requests for certificates in which
the actual certificate issued is different from that requested
...
... of handling responses to requests for certificates in which
the actual certificate issued is different from that requested
(for example, a CA may shorten the validity ...
... Note that policy may dictate that the CA must not publish or
otherwise distribute the certificate until the requesting
entity has reviewed and accepted the newly-created ...
... entity has reviewed and accepted the newly-created certificate
(typically through use of the PKIConfirm message).
...
... CA key update) must also be able to verify certificates
verifiable using the old public key. End entities ...
... trust the old CA key pair must also be able to verify
certificates signed using the new CA private key. (Required
for situations where the old CA public key ...
...
13. Where an end entity requests a certificate containing a given
public key value, the end entity ...
... private key value. This may be
accomplished in various ways, depending on the type of
certification request. See Section 2.3, "Proof of Possession
of Private Key", for details of the in-band ...
... 3 Certification: various operations result in the creation of new
certificates:
3.1 initial registration ...
...
3.1 initial registration/certification: This is the process
whereby an end entity first makes itself known to a CA ...
... RA, prior to the CA issuing a certificate or certificates
for that end entity. The end result of this process (when it
...
... end entity. The end result of this process (when it
is successful) is that a CA issues a certificate for an end
entity's public key, and returns that certificate ...
... certificate for an end
entity's public key, and returns that certificate to the end
entity and/or posts that certificate in a public repository.
...
... public key, and returns that certificate to the end
entity and/or posts that certificate in a public repository.
This process may, and typically will, involve multiple
"steps", possibly including an initialization ...
... public key of a CA, to
be used in validating certificate paths. Furthermore, an
end entity typically needs to be initialized with its own
...
... regularly (i.e., replaced with a new key pair), and a new
certificate needs to be issued.
3.3 certificate ...
... 3.3 certificate update: As certificates expire they may be
"refreshed" if nothing relevant in the environment has
changed.
...
... certification request: One CA requests issuance of a
cross-certificate from another CA. For the purposes of this
standard, the following terms are defined. A "cross-
...
... CA. For the purposes of this
standard, the following terms are defined. A "cross-
certificate" is a certificate in which the subject CA ...
... standard, the following terms are defined. A "cross-
certificate" is a certificate in which the subject CA and
...
... CA are distinct and SubjectPublicKeyInfo contains
a verification key (i.e., the certificate has been issued
for the subject CA ...
... signing key pair). When it is
necessary to distinguish more finely, the following terms
may be used: a cross-certificate is called an "inter-domain
cross-certificate ...
... cross-certificate is called an "inter-domain
cross-certificate" if the subject and issuer CAs ...
... Notes:
Note 1. The above definition of "cross-certificate" aligns with the
defined term "CA-certificate ...
... cross-certificate" aligns with the
defined term "CA-certificate" in X.509. Note that this term is not
to be confused with the X.500 ...
... is unrelated.
Note 2. In many environments the term "cross-certificate", unless
further qualified, will be understood to be synonymous with "inter-
domain ...
... further qualified, will be understood to be synonymous with "inter-
domain cross-certificate" as defined above.
Note 3. Issuance of cross-certificates ...
... cross-certificate" as defined above.
Note 3. Issuance of cross-certificates may be, but is not
necessarily, mutual; that is, two CAs may issue cross-certificates ...
... certificates may be, but is not
necessarily, mutual; that is, two CAs may issue cross-certificates
for each other.
...
... 3.6 cross-certificate update: Similar to a normal certificate
update but involving a cross-certificate ...
... CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs:
...
... CRLs:
4.1 certificate publication: Having gone to the trouble of
producing a certificate, some means for publishing it is
...
... 4.1 certificate publication: Having gone to the trouble of
producing a certificate, some means for publishing it is
needed. The "means" defined in PKIX MAY involve the
...
...
4.2 CRL publication: As for certificate publication.
5 Recovery operations: some PKI management ...
... revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
...
... Initial registration/certification ...
... There are many schemes that can be used to achieve initial
registration and certification of end entities. No one method is
...
...
We can however, classify the initial registration / certification
schemes that are supported by this specification. Note that the word
"initial", above, is crucial - we are dealing with the situation
...
... We will now describe the classification of initial registration /
certification schemes.
...
... Initiation of registration / certification ...
... PKI messages which are produced we can regard the
initiation of the initial registration / certification exchanges as
occurring wherever the first PKI message relating to the end entity ...
... is produced. Note that the real-world initiation of the registration
/ certification procedure may occur elsewhere (e.g., a personnel
department may telephone an RA ...
... on-line messages produced by the end entity that requires a
certificate may be authenticated or not. The requirement here is to
...
...
We can thus classify the initial registration/certification scheme
according to whether or not the on-line end entity ...
...
Note 2: An initial registration / certification procedure can be
secure where the messages from the end entity are authenticated ...
... Confirmation of successful certification ...
...
Following the creation of an initial certificate for an end entity,
additional assurance can be gained by having the end entity ...
... end entity
explicitly confirm successful receipt of the message containing (or
indicating the creation of) the certificate. Naturally, this
confirmation message must be protected (based on the initial
authentication key or other means).
...
... The criteria above allow for a large number of initial registration /
certification schemes. This specification mandates that conforming CA
equipment, RA ...
... Key generation
Creation of certification request
Protect request with IAK
-->>--certification ...
... certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
...
... RA/CA MUST
revoke the newly issued certificate if it has been published or
otherwise made available.)
...
... private key corresponding to the public key for which a
certificate is requested. A given CA/RA is free to choose how to
...
... out-of-band procedural means versus PKIX-CMP in-
band messages) in its certification exchanges (i.e., this may be a
policy issue). However, it is REQUIRED that CAs/RAs ...
... POP is accomplished in different ways depending upon the type of key
for which a certificate is requested. If a key can be used for
multiple purposes (e.g., an RSA key) then any appropriate method ...
... end entity (and have the end entity demonstrate its ability to
decrypt this certificate in the confirmation message). This allows a
CA to issue a certificate ...
... certificate in the confirmation message). This allows a
CA to issue a certificate in a form which can only be used by the
intended end entity.
...
... CA updates its key pair it must generate two extra
cACertificate attribute values if certificates are made available
using an X.500 directory (for a total of four: OldWithOld;
...
... out-of-band" mechanism). This will typically
be easily achieved when these end entities' certificates expire.
...
... data structure used to protect the new and old CA public keys is
a standard certificate (which may also contain extensions). There are
no new data structures required.
...
... extensions as it must be able to work even for version 1
certificates. The presence of the KeyIdentifier extension would make
for efficiency improvements.
...
... validity period
of one of its end entities' certificates, this generalization seems
of dubious value. Not having this generalization simply means that
the validity ...
... CA key pair must be greater than the
validity period of any certificate issued by that CA using that key
pair.
...
... forces end entities to acquire the new CA public
key on the expiry of the last certificate they owned that was signed
with the old CA private key (via the "out-of-band ...
... CA private key (via the "out-of-band" means).
Certificate and/or key update operations occurring at other times do
not necessarily require this (depending on the end entity ...
... CA public key signed
with the new private key (the "new with new" certificate);
5. Publish these new certificates ...
... certificate);
5. Publish these new certificates via the directory and/or other
means (perhaps using a CAKeyUpdAnn message);
...
... Verifying Certificates. ...
... signature, the verifier verifies (among
other things) the certificate containing the public key of the
signer ...
... can the value of verify the verification
directly the NEW certificate will FAIL
verify the public key directly -
...
... verify the public key directly -
certificate this is thus
without the same as
using the case 1.
...
... verifier can directly is the has not
using OLD must verify the situation of updated the
public access the certificate case 2 and directory the
key directory without will access verifier can
...
... verifier can
in order using the the verify the
to get the directory directory; certificate
value of however, the directly -
the OLD verification ...
... local copy of the CA public key
which can be used to verify the certificate directly. This is the
same as the situation where no key change has occurred.
...
... CA operator has issued both the signer's and verifier's certificates
during this "gap" (the CA operator SHOULD avoid this as it leads to
...
...
1. Look up the caCertificate attribute in the directory and pick
the OldWithNew certificate (determined based on validity
periods);
...
... CA operator has issued the signer's
certificate, then changed key and then issued the verifier's
certificate ...
... certificate, then changed key and then issued the verifier's
certificate, so it is quite a typical case.
...
...
1. Look up the CACertificate attribute in the directory and pick
the NewWithOld certificate (determined based on validity
periods);
...
... verifier has stored locally);
3. If correct, check the signer's certificate using the new CA
key.
...
... CA operator has issued the verifier's
certificate, then changed key and then issued the signer's
certificate ...
... certificate, then changed key and then issued the signer's
certificate, so it is also quite a typical case.
...
... In this case the CA has issued the signer's certificate protected
with the new key without updating the directory attributes. This
means that the verifier ...
...
As we saw above the verification of a certificate becomes more
complex once the CA is allowed to change its key. This is also true
...
...
The analysis of the alternatives is as for certificate verification.
...
... body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
...
... PKI
message.
The extraCerts field can contain certificates that may be useful to
the recipient. For example, this can be used by a CA or RA ...
... RA to present
an end entity with certificates that it needs to verify its own new
certificate (if, for example, the CA ...
... end entity with certificates that it needs to verify its own new
certificate (if, for example, the CA that issued the end entity's
...
... CA that issued the end entity's
certificate is not a root CA for the end entity). Note that this
...
... root CA for the end entity). Note that this
field does not necessarily contain a certification path - the
recipient may have to sort, select from, or otherwise process the
extra certificates ...
... certification path - the
recipient may have to sort, select from, or otherwise process the
extra certificates in order to use them.
...
... ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
...
... cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
-- the PKCS #10 certification ...
... Certification Response
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
-- the PKCS #10 certification request (see [PKCS10])
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
...
... CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
...
... such external mechanisms require that the end entity already
possesses a public-key certificate, and/or a unique Distinguished
Name, and/or other such infrastructure-related information. Thus,
they may not be appropriate for initial registration ...
... Where the sender and receiver possess Diffie-Hellman certificates
with compatible DH parameters, then in order to protect the message
...
... MAC or a signature, depending on the information and
certificates shared between the RA and the CA). This is accomplished
...
... Requested Certificate Contents ...
... PKI management messages require that the originator of the
message indicate some of the fields that are required to be present
in a certificate. The CertTemplate structure allows an end entity or
...
... end entity or
RA to specify as much as it wishes about the certificate it requires.
CertTemplate is identical to a Certificate ...
... certificate it requires.
CertTemplate is identical to a Certificate but with all fields
optional.
...
...
Note that even if the originator completely specifies the contents of
a certificate it requires, a CA is free to modify fields within the
certificate ...
... certificate it requires, a CA is free to modify fields within the
certificate actually issued. If the modified certificate is
unacceptable to the requester, the Confirmation message may be
...
... CA is free to modify fields within the
certificate actually issued. If the modified certificate is
unacceptable to the requester, the Confirmation message may be
withheld, or an Error Message ...
... encrypted values (restricted, in this specification, to be
either private keys or certificates) are sent in PKI messages the
EncryptedValue data structure ...
... -- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
...
... Certificate Identification ...
...
In order to identify particular certificates the CertId data
structure is used.
...
... methods available: either the CA directly
publishes its self-signed certificate; or this information is
available via the Directory (or equivalent) and the CA publishes a
...
... certificate are restricted as follows:
- The certificate MUST be self-signed (i.e., the signature must be
verifiable using the SubjectPublicKeyInfo field);
...
... value;
- The values of all other extensions must be suitable for a self-
signed certificate (e.g., key identifiers for subject and issuer ...
... BIT STRING
-- hashVal is calculated over the self-signed
-- certificate with the identifier certID.
}
...
... Requesters may indicate that they wish the PKI to publish a
certificate using the PKIPublicationInfo structure.
...
... signing key pair (i.e., a
request for a verification certificate), then the proof of possession
of the private signing key is demonstrated through use of the
...
... DN from a
-- previously-issued and currently-valid certificate))
publicKeyMAC [1] PKMACValue
-- used if no authenticated ...
... }
On the other hand, if the certification request is for an encryption
key pair (i.e., a request for an encryption certificate ...
... certification request is for an encryption
key pair (i.e., a request for an encryption certificate), then the
proof of possession of the private decryption key may be demonstrated
...
... certificate, but an encrypted
certificate (i.e., the certificate encrypted under a randomly-
...
... encrypted
certificate (i.e., the certificate encrypted under a randomly-
generated symmetric key ...
... encrypted under
the public key for which the certification request is being
made) -- this is the "indirect" method mentioned previously in
...
... RA verifies POP and then
makes a certification request to the CA on behalf of the end
entity. In such a scenario, the CA ...
... POP correctly before the RA requests a certificate for the end
entity.] The complete protocol then looks as follows (note
that req' does not necessarily encapsulate ...
... in choice (2) above, but allows a local Registration Authority to be
involved and has the property that the certificate itself is not
actually created until the proof of possession is complete.
...
... key pairs,
with the following changes: (1) the parenthetical text of bullet 2)
is replaced with "(i.e., the certificate encrypted under the
symmetric key ...
... CA's private KAK and the public key
for which the certification request is being made)"; (2) the first
parenthetical text of the challenge field of "Challenge" below is
replaced with "(using PreferredSymmAlg (see Appendix B6) and a
...
... CA's private KAK and the public key
for which the certification request is being made)". Alternatively,
the POP can use the POPOSigningKey structure given in [CRMF ...
... POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
...
... -- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER ...
... CertReqMessages data structure which specifies the requested
certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity
are the template fields which may be supplied for each certificate ...
... certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity
are the template fields which may be supplied for each certificate
requested (see Appendix B profiles for further information). This
...
... response message contains as the PKIBody an
CertRepMessage data structure which has for each certificate
requested a PKIStatusInfo field, a subject certificate ...
... certificate
requested a PKIStatusInfo field, a subject certificate, and possibly
a private key (normally encrypted ...
... PKI
Message Protection is "shared secret information" (see Section
3.1.3), then any certificate transported in the caPubs field may be
directly trusted as a root CA certificate ...
... certificate transported in the caPubs field may be
directly trusted as a root CA certificate by the initiator.
...
... Registration/Certification Request ...
...
A Registration/Certification request message contains as the PKIBody
a CertReqMessages data structure ...
... a CertReqMessages data structure which specifies the requested
certificates. This message is intended to be used for existing PKI
entities who wish to obtain additional certificates.
...
... certificates. This message is intended to be used for existing PKI
entities who wish to obtain additional certificates.
See [CRMF ...
... CertificationRequest given in [PKCS10]). This structure may be
required for certificate requests for signing key pairs when
...
... Registration/Certification Response ...
... CertRepMessage data structure which has a status value for each
certificate requested, and optionally has a CA public key, failure
information, a subject ...
...
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
...
...
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
...
... CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
...
... }
Only one of the failInfo (in PKIStatusInfo) and certificate (in
CertifiedKeyPair) fields can be present in each CertResponse
(depending on the status). For some status values (e.g., waiting)
...
... Given an EncryptedCert and the relevant decryption key the
certificate may be obtained. The purpose of this is to allow a CA to
return the value of a certificate ...
... certificate may be obtained. The purpose of this is to allow a CA to
return the value of a certificate, but with the constraint that only
the intended recipient can obtain the actual certificate ...
... certificate, but with the constraint that only
the intended recipient can obtain the actual certificate. The benefit
of this approach is that a CA may reply with a certificate ...
... certificate. The benefit
of this approach is that a CA may reply with a certificate even in
the absence of a proof that the requester is the end entity which can
...
... CA). Thus the CA will
not have to revoke that certificate in the event that something goes
wrong with the proof of possession.
...
... fields which may be supplied for each key to be updated. This
message is intended to be used to request updates to existing (non-
revoked and non-expired) certificates.
See [CRMF ...
... used to supply a signature public key for which a certificate is
required (see Appendix B profiles for further information).
...
... KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate ...
... Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
...
...
When requesting revocation of a certificate (or several certificates)
the following data structure ...
... When requesting revocation of a certificate (or several certificates)
the following data structure is used. The name of the requester is
...
... revocation announcement
message MAY be sent to the subject of the certificate for which
revocation was requested.)
...
... Cross certification request content ...
...
Cross certification requests use the same syntax (CertReqMessages) as
for normal certification requests with the restriction that the key
pair ...
... Cross certification requests use the same syntax (CertReqMessages) as
for normal certification requests with the restriction that the key
pair MUST have been generated by the requesting CA and the private
key ...
... Cross certification response content ...
...
Cross certification responses use the same syntax (CertRepMessage) as
for normal certification responses with the restriction that no
...
... Cross certification responses use the same syntax (CertRepMessage) as
for normal certification responses with the restriction that no
encrypted private key ...
...
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
...
... oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
...
... newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
...
... Certificate Announcement ...
...
This structure MAY be used to announce the existence of certificates.
Note that this message is intended to be used for those cases (if
...
... any) where there is no pre-existing method for publication of
certificates; it is not intended to be used where, for example, X.500
is the method ...
... certificates.
CertAnnContent ::= Certificate
...
... When a CA has revoked, or is about to revoke, a particular
certificate it MAY issue an announcement of this (possibly upcoming)
event.
...
... CA MAY use such an announcement to warn (or notify) a subject that
its certificate is about to be (or has been) revoked. This would
typically be used where the request for revocation did not come from
...
... }
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
...
... -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response ...
...
A newly created root CA must produce a "self-certificate" which is a
Certificate structure with the profile ...
... created root CA must produce a "self-certificate" which is a
Certificate structure with the profile defined for the "newWithNew"
certificate ...
... Certificate structure with the profile defined for the "newWithNew"
certificate issued following a root CA key update.
...
...
In order to make the CA's self certificate useful to end entities
that do not acquire the self certificate ...
... certificate useful to end entities
that do not acquire the self certificate via "out-of-band" means, the
CA ...
... out-of-band" means
can then verify the CA's self-certificate and hence the other
attributes contained therein.
...
... CA keys (as all other keys) have a finite lifetime and will have to
be updated on a periodic basis. The certificates NewWithNew,
NewWithOld, and OldWithNew (see Section 2.4.1) are issued by the CA
...
... end entities who hold the current self-signed CA
certificate (OldWithOld) to transition securely to the new self-
signed CA certificate ...
... certificate (OldWithOld) to transition securely to the new self-
signed CA certificate (NewWithNew), and to aid new end entities who
will hold NewWithNew to acquire OldWithOld securely for verification ...
... (i.e., PasswordBasedMAC) or any other authenticated means (if the end
entity has an existing certificate).
...
... Cross certification ...
... CA that will become the subject of the
cross-certificate; the responder CA will become the issuer ...
... The requester CA must be "up and running" before initiating the
cross-certification operation.
...
...
The cross-certification scheme is essentially a one way operation;
that is, when successful, this operation results in the creation of
one new cross-certificate ...
... certification scheme is essentially a one way operation;
that is, when successful, this operation results in the creation of
one new cross-certificate. If the requirement is that cross-
certificates ...
... cross-certificate. If the requirement is that cross-
certificates be created in "both directions" then each CA in turn
...
... created in "both directions" then each CA in turn
must initiate a cross-certification operation (or use another
scheme).
...
... trust) or where there is an out-of-band verification of the origin of
the certification request.
...
... responder CA the cross certification request (ccr) message. The
fields in this message are protected from modification with a MAC
...
... MAC. It then
generates (and archives, if desired) a new requester certificate that
contains the requester CA public key and is signed with the responder ...
... private key. The responder CA responds with the cross
certification response (ccp) message. The fields in this message are
protected from modification with a MAC based on the authorization ...
...
1. The ccr message must contain a "complete" certification request,
that is, all fields (including, e.g., a BasicConstraints
extension) must be specified by the requester CA ...
... CA - if present, the requester CA must then verify this
certificate (for example, via the "out-of-band" mechanism).
...
... Additional information could be required (e.g., supported extensions
or CA policy information) in order to produce a certification request
which will be successful. However, for simplicity we do not mandate
that the end entity ...
... end entity acquires this information via the PKI messages.
The end result is simply that some certification requests may fail
(e.g., if the end entity wants to generate its own encryption key ...
... end entity with the CA's
self-certificate fingerprint via some secure "out-of-band" means. The
...
... Certificate Request ...
...
An initialized end entity MAY request a certificate at any time (as
part of an update procedure, or for any other purpose). This request
...
... part of an update procedure, or for any other purpose). This request
will be made using the certification request (cr) message. If the
end entity already possesses a signing key pair ...
... signing key pair (with a corresponding
verification certificate), then this cr message will typically be
protected by the entity's digital signature ...
... digital signature. The CA returns the new
certificate (if the request is successful) in a CertRepMessage.
...
... key update - that is, it MAY request that the CA issue a new
certificate for a new key pair. The request is made using a key
update request (kur) message. If the end entity ...
... signing key pair (with a corresponding verification certificate),
then this message will typically be protected by the entity's digital
signature ...
... entity's digital
signature. The CA returns the new certificate (if the request is
successful) in a key update response (kup) message, which is
...
... prove possession of a decryption key, it is effectively challenged to
decrypt something (its own certificate). This scheme (and many
others!) could be vulnerable to an attack if the possessor of the
...
... Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate Request Message Format", RFC 2511(-> 4211prop), March 1999. ...
... ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996. ...
... -Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
...
... - information request/response
- cross-certification request/response (1-way)
- initial registration ...
... B3. "Self-signed" certificates ...
...
Profile of how a Certificate structure may be "self-signed". These
structures are used for distribution of "root" CA public keys ...
... Type Function
newWithNew a true "self-signed" certificate; the contained public
key MUST be usable to verify the signature (though this
...
... private key
<<Such certificates (including relevant extensions) must contain
"sensible" values for all fields. For example, when present
subjectAltName ...
... signing key which corresponds to a public verification key for which
a certificate has been requested.
Field Value Comment
...
... decryption key which corresponds
to a public encryption key for which a certificate has been requested
does not use this profile; instead the method ...
... PKIX-CMP in-band
certification request protocol (how POP is done MAY ultimately be a
policy issue which is made explicit for any given CA ...
... CA in its
publicized Policy OID and Certification Practice Statement).
However, this specification MANDATES that CA/RA ...
... RA entities MUST do POP
(by some means) as part of the certification process. All end
entities MUST be prepared to provide POP (i.e., these components of
...
... newWithNew present see Section B3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
...
... it will simply forward the equivalent message which it previously
received from the CA, with the possible addition of the certificates
to the extraCerts fields of the PKIMessage. A PKIConfirm message is
NOT REQUIRED from the end entity ...
... CA as contained in issuerAltName extensions or
-- issuer fields within certificates
protectionAlg MSG_MAC_ALG ...
... ALG
extraCerts optionally present
-- can be used to send some certificates to the end entity. An RA MAY
...
... B7. Cross certification request/response (1-way) ...
...
Creation of a single cross-certificate (i.e., not two at once). The
requesting CA MAY choose who is responsible for publication of the
...
... requesting CA MAY choose who is responsible for publication of the
cross-certificate created by the responding CA through use of the
...
... CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA ...
... only one CertReqMsg
allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
certTemplate present
...
... CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL- ...
... -- a requesting CA must propose values for all extensions which it
-- requires to be in the cross-certificate
POPOSigningKey present
...
... ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
...
... CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA ...
... body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
response present
...
...
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate ...
... certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
...
... ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
...
... CA. When the CA responds with a message containing a certificate, the
end entity replies with a confirmation. All messages are
...
...
This scheme allows the end entity to request certification of a
locally-generated public key (typically a signature key ...
... signature key). The end
entity MAY also choose to request the centralized generation and
certification of another key pair (typically an encryption key pair).
...
... encryption key pair).
Certification may only be requested for one locally generated public
key (for more, use separate PKIMessages).
...
... CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG ...
... only one or two CertReqMsg
are allowed
-- if more certificates are required requests MUST be packaged in
-- separate PKIMessages
CertReqMsg one or two present
...
... crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key ...
... in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
...
... crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "granted"
or "grantedWithMods"
certificate present
privateKey present
publicationInfo optionally present
...
... privateKey present
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
...
... extraCerts optionally present
-- the CA MAY provide additional certificates to the end entity
...
... CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
...
... initial authentication key if only a signing key
-- pair has been sent in ir for certification, or if POP is not
-- done in this in-band ...
... B9. Certificate Request ...
... reason). When the CA responds with a message containing a
certificate, the end entity replies with a confirmation. All messages
are authenticated ...
... POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification ...
... update the key pair and corresponding certificate that it already
possesses). When the CA responds with a message containing a
...
... possesses). When the CA responds with a message containing a
certificate, the end entity replies with a confirmation. All messages
are authenticated ...
... POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification ...
... IMPORTS
Certificate, CertificateList, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet ...
... body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
...
... ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
...
... cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [PKCS10]
popdecc [5] POPODecKeyChallContent, --pop Challenge
...
... CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
...
... -- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
...
... }
OOBCert ::= Certificate
OOBCertHash ::= SEQUENCE {
...
... POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
...
... -- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER ...
...
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
...
...
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
...
... CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
...
... KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate ...
... Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
...
...
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
...
... oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
...
... newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
...
... }
CertAnnContent ::= Certificate
RevAnnContent ::= SEQUENCE {
...
... }
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
...
... -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response ...
... Applications which use this media type:
Applications using certificate management, operational, or ancillary
protocols (as defined by the IETF ...