Skip to main content

3.6 Certificate Payload

3.6 Certificate Payload​

The Certificate payload, denoted CERT in this document, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender. The Hash and URL formats of the Certificate payloads should be used in case the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term "Certificate payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload.

The Certificate payload is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cert Encoding |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                       Certificate Data                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 12: Certificate Payload Format
  • Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values.
Certificate EncodingValueNote
PKCS #7 wrapped X.509 certificate1UNSPECIFIED
PGP Certificate2UNSPECIFIED
DNS Signed Key3UNSPECIFIED
X.509 Certificate - Signature4
Kerberos Token6UNSPECIFIED
Certificate Revocation List (CRL)7
Authority Revocation List (ARL)8UNSPECIFIED
SPKI Certificate9UNSPECIFIED
X.509 Certificate - Attribute10UNSPECIFIED
Deprecated (was Raw RSA Key)11DEPRECATED
Hash and URL of X.509 certificate12
Hash and URL of X.509 bundle13
  • Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.

The payload type for the Certificate payload is thirty-seven (37).

Specific syntax for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are:

  • "X.509 Certificate - Signature" contains a DER-encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload.

  • "Certificate Revocation List" contains a DER-encoded X.509 certificate revocation list.

  • Hash and URL encodings allow IKE messages to remain short by replacing long data structures with a 20-octet SHA-1 hash (see [FIPS.180-4.2012]) of the replaced value followed by a variable-length URL that resolves to the DER-encoded data structure itself. This improves efficiency when the endpoints have certificate data cached and makes IKE less subject to DoS attacks that become easier to mount when IKE messages are large enough to require IP fragmentation [DOSUDPPROT].

The "Hash and URL of a bundle" type uses the following ASN.1 definition for the X.509 bundle:

   CertBundle
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cert-bundle(34) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     Certificate, CertificateList
     FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-explicit(18) } ;

   CertificateOrCRL ::= CHOICE {
     cert [0] Certificate,
     crl  [1] CertificateList }

   CertificateBundle ::= SEQUENCE OF CertificateOrCRL

   END

Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the two Hash and URL formats (with HTTP URLs). If multiple certificates are sent, the first certificate MUST contain the public key associated with the private key used to sign the AUTH payload. The other certificates may be sent in any order.

Implementations MUST support the http: scheme for hash-and-URL lookup. The behavior of other URL schemes [URLS] is not currently specified, and such schemes SHOULD NOT be used in the absence of a document specifying them.

Last updated on