Skip to content

NDNCERT Protocol 0.2

Jump to bottom
Davide Pesavento edited this page Oct 26, 2021 · 13 revisions

NDN Certificate Management Protocol v0.2 (Obsolete)

1. Overview

In Named Data Networking (NDN), to generate Data packets with legitimate names and verifiable signatures, an application (producer) needs to obtain a name and a certificate for that name. With trust anchors, an entity could apply for a certificate from a trusted certificate signer, which can be processed either manually or through automated means. NDN certificate management protocol (NDNCERT) enables automatic certificate management in NDN, including

  • certificate application/issuance,
  • certificate renewal
  • certificate revocation
  • identity verification for certificate management operations.

Furthermore, NDNCERT enables an entity to easily manage its sub-namespaces and their corresponding certificates, allowing a namespace owner to manage its owned devices and services in a clearer and more secure way. For example, a entity who owns namespace /ucla/cs/zhiyi can derive sub-namespace /ucla/cs/zhiyi/mobile-phone to his phone and /ucla/cs/zhiyi/home to his smart home controller.

Note that NDNCERT does not impose any specific trust model or trust anchors. While the primary use case of the developed protocol is to manage NDN testbed certificates, it can be used with any other set of global and local trust anchors.

This specification provides details and packet formats to request certificates, create certificates after one of the validation mechanism, and how the issued certificate is retrieved by the original requester.

2. Certificate Issuance

2.1 Overview

In NDN any node can take a role of certificate issuer/signer, managing certificates in the designated namespace. There are mainly two kinds of an issuer:

  • A self-signed local trust anchor for the namespace.
  • A delegated certificate for the namespace.

The following diagram illustrates the main process for an issuer to perform new certificate issuance. There are mainly three processes in the certificate application.

  • PROBE Interest for Sub Namespace Assignment

    The certificate requester first sends an interest called PROBE to ask for an available namespace from the issuer. PROBE Interest can carry information that is used for the issuer to decide the namespace assignment. The issuer will reply an available namespace to certificate requester.

  • NEW Interest to Start a New Certificate Application

    The certificate requester first prepares a pair of asymmetric key (existing key pair or newly generated key pair) with the name obtained in the previous step and send a NEW interest to the issuer to start an application. When the issuer receives the NEW Interest, the issuer will collect all available out-of-band or in-band identity verification methods (called challenge) according to its own policy and reply the challenge list and a unique application ID to the requester.

    Notice that the issuer will start keeping requester's application instance at this time point.

  • CHALLENGE Interest to Select and Finish the Challenge

    The certificate requester then selects one challenge and send a CHALLENGE Interest to notice the issuer which challenge has been selected. After receiving the first CHALLENGE Interest, the issuer will perform the challenge for the requester.

    During the process or after finishing the selected challenge, the request would send more CHALLENGE Interests to pass the required information to the issuer and finish the identity verification. Once the challenge result is approved by the issuer, the issuer will sign the certificate.

  • DOWNLOAD Interest for New Certificate Download

    Once certificate requester knows the certificate has been signed by the issuer. The requester can fetch the certificate using DOWNLOAD Interest.

     certificate requester                        CA
             |               PROBE               |
             | --------------------------------> |
             |                                   |
             |                        Get an available namespace
             |               Data                |
             | <-------------------------------- |
             |                                   |
    Generate key pair                            |
Generate certificate request                     |
             |                NEW                |
             | --------------------------------> |
             |                                   |
             |                           Prepare challenge list
             |                            Generate request ID
             |               Data                |
             | <-------------------------------- |
             |                                   |
     select challenge                            |
             |            CHALLENGE              |
             | --------------------------------> |
             |                                   |
             |                            Perform Challenge
             |                                   |
Requester sends more CHALLENGE Interest to finish challenge if needed.
             |                                   |
             |                              Check Challenge .....+
             |                                   |               V
             |                                   |         Verify result
             |               Data                |               V
             | <-------------------------------- |<.... If valid, issue cert
             |                                   |    Otherwise, return status
             |              DOWNLOAD             |
             | --------------------------------> |
             |                Data               |
             | <-------------------------------- |

2.2 Warm Start and Cold Start

Warm Start

Warm start means that the requester trusts the issuer in advance, which means the requester has already installed the issuer's certificate. The use case of warm start is mainly where the issuer is well-known, e.g., NDN Testbed Certificate Authority, UCLA Official Certificate Authority. In warm start scenarios, the challenge is usually single-direction: the challenge is used to verify a requester's identity or legality.

Cold Start

Cold start means that the requester does not have issuer's certificate pre-installed. The use case of cold start is when there is no way for the requester to trust the issuer, e.g., in Internet of Things (IoT) scenarios, when a new device is bought, the device does not have pre-defined knowledge of its future home system. In code start scenarios, the challenge is supposed to be double-direction: the challenge is for the requester to verify the issuer and at the same time, the issuer can verify requester's identity.

2.3 Packet Format

2.3.1 PROBE Interest and Replied Data

Interest Format

Name: /<CA-Prefix>/CA/_PROBE/[ApplicationParameter_Digest|INFO]
ApplicationParameters: JSON text
Signature: Not required
Must Be Fresh: True

JSON format: The format depends on the probe of the configuration file. As an example, if we have "probe":"email:full-name", then the JSON text carried in the PROBE Interest will contains two attributes: email and full-name.

Data Format

Name: Same as PROBE Interest Name
Content: JSON text
Signature: Signed by CA's identity key

JSON format:

  • "name": assigned sub-namespace (appears when PROBE Interest carries Parameters).
  • "ca-config": ca configuration content (appears when PROBE Interest ends with CA/_PROBE/INFO).

Data Verification Process

  • The KeyLocator in Data Signature Info element must starts with the //KEY
  • The signature value must be verified using the public key pre-installed (in warm start scenarios) or obtained in the PROBE Data content (in cold start scenarios).

Notice that in cold start scenarios, using the public key extracted from the PROBE Data content to verify the PROBE Data signature does not provide any real authenticity and integrity until the requester and the issuer finish the challenge and successfully verify each other.

Instructions

In the warm start scenario, the last name component is the digest value of Interest Parameters Field and the required information for sub-namespace assignment is placed into the Interest Parameters Field.

Notice that the required information is different from issuer to issuer, and for a requester to properly give the information, human interaction is usually needed. For example, the command line user interface or graphical user interface can prompt please input your email address.

In cases where human interaction is impossible or hard, e.g., when a constrained IoT board is applying for a certificate, the sub-namespace assignment step can be omitted.

In a cold start scenario, given the requester has no idea how to perform the sub-namespace assignment, this step can be omitted.

One special case of PROBE Interest is /<CA-prefix>/CA/_PROBE/INFO (with no Interest Parameters Field). With this special PROBE Interest, a requester can fetch the information of the issuer, including the certificate, the requirement of certificate application, and so on. This Interest is recommended if the requester has not talked with the issuer before.

Another special case of PROBE Interest is /localhop/CA/_PROBE/INFO (with no Interest Parameters Field). This is used in the local area network, e.g., smart home WiFi network. This Interest is supposed to be a broadcast Interest and this Interest can discover the available issuer(s) in the local network.

Examples of PROBE Interest and Data Exchange

  • Issuer /ndn/edu/ucla requires user to use email address for sub-name assignment. Such requirement is enforced by having a "probe":"email" in CA and Client's configuration files.

    Interest:
Name: /ndn/edu/ucla/CA/_PROBE/9A39DC3...
ApplicationParameters:
{
  "email":"zhiyi@cs.ucla.edu"
}

Data:
Name: /ndn/edu/ucla/CA/_PROBE/9A39DC3...
Content:
{
  "name": "/ndn/edu/ucla/zhiyi",
  "email": "zhiyi@cs.ucla.edu"
}
Signature

  • The requester sends /ndn/_PROBE/INFO

    Interest:
Name: /ndn/CA/_PROBE/INFO

Data:
Name: /ndn/CA/_PROBE/INFO
Content:
{
  "ca-prefix": "/zhiyi-home/controller",
  "probe": "email",
  "certificate": "Bv0CJAcsCANuZG4IBXNpd..."
}
Signature

2.3.2 NEW Interest and Replied Data

NEW Interest Format

Name: /<CA-prefix>/CA/_NEW/[ApplicationParameters_Digest]
ApplicationParameters: JSON text
Signature: Signed by the private key associated with the public key in the cert
Must Be Fresh: True

JSON Format:

  • "ecdh-pub": ECDH_Requester_PubKey: the requester's public key used for Elliptic-Curve Diffie-Hellman key agreement.
  • "cert-request": Certificate Request (Self-signed Certificate).
  • "probe-token": the PROBE Data packet replied in the previous PROBE step. This field only appears when probe is not empty in the configuration file. The token helps to ensure that a client has already performed the PROBE step before the NEW step, helping CA to determine whether a client actually uses the identity name, and whether the information provided in the PROBE is actually used in later verifications (for example, the email address provided in PROBE should be the same as the one used in Email challenge).

Interest Verification Process:

  • The Interest must be in the correct signed Interest format as defined in NDN Packet Format.

    However, currently the format v0.3 is not fully supported by ndn-cxx. Therefore, the current implementation will follow the old format of signed Interest until format v0.3 is fully supported by ndn-cxx.

  • The signature value can be verified by the public key obtained in the certificate request.

  • The cert request must be a valid self-signed certificate

  • The probe token must be a valid Data packet signed by the CA.

Notice that using the public key extracted from Interest Parameters to verify the Interest signature does not provide any real authenticity and integrity until the requester finishes the challenge.

NEW Data Format

Name: Same as NEW Interest Name
Content: JSON text
Signature: Signed by CA's identity key

JSON format:

  • "ecdh-pub": ECDH_Issuer_PubKey: the issuer's public key used for Elliptic-Curve Diffie-Hellman key agreement. The value is supposed to be encoded into base64 format as specified in RFC 4648 section 3.1.

  • "salt": 64 bits or longer random number. The decimal string of this number in little endianness should be placed in the JSON text.

  • "request-id": Unique ID assignment for this request instance

  • "status": The application status code. The decimal string of the status number in little endianness should be placed in the JSON text.

    • STATUS_BEFORE_CHALLENGE = 0,
    • STATUS_CHALLENGE = 1,
    • STATUS_PENDING = 2,
    • STATUS_SUCCESS = 3,
    • STATUS_FAILURE = 4,
    • STATUS_NOT_STARTED = 5

  • "challenges": A challenge list from which the requester can select. The list is a JSON array object. The child attribute name is "challenge-id".

Data Verification Process

  • The KeyLocator in Data Signature Info element must starts with the //KEY
  • The signature value must be verified using the public key pre-installed (in warm start scenarios) or obtained in the PROBE Data content (in cold start scenarios).

Instructions

In the NEW Interest and Data exchange:

  • The requester and the issuer follow Elliptic-Curve Diffie-Hellman (ECDH) protocol and negotiate a shared secret key for future use.

  • The requester provides its self-signed certificate so that later if identity verification succeeds, the issuer can use issuer's key to sign the requester's public key and issue the certificate.

  • In the self-signed certificate, the requester can specify the validity period based on its needs; however, the validity period cannot exceed the maximum value pre-defined by the issuer. If exceeds, the issuer will modify the validity period to the maximum value. This enables requesters to get ephemeral certificates.

Regarding the public parameters used for ECDH process, there are two options:

  • Global default public parameters: Elliptic Curve NIST p-256 (providing 128 bits security)

  • Customized public parameters can be placed into issuer's configuration. The information is obtained by the issuer with PROBE Interest /<CA-Prefix>/CA/_PROBE/INFO or /ndn/CA/_PROBE/INFO if enabled. In cold start scenarios, the requester cannot verify the issuer's configuration, but this will not damage because when performing a double-direction challenge, if the issuer cannot prove its identity, the requester will abandon all the state related to this application.

The ECDH_Requester_PubKey and the ECDH_Issuer_PubKey are base64-encoded (as specified in RFC 4648 section 3.1) ECDH compressed public key bits. The default length of ECDH public key bits is defined per the ECDH public parameters.

After ECDH process, both the requester and the issuer get a shared secret (256 bits using ECDH NIST p-256). A Key Derivation Function (KDF) will be applied on the shared secret for better security. In NDNCERT, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) will be used to derive a 256-bit AES key from the shared secret from ECDH. The HKDF function will be invoked on the shared secret and also a salt. In HKDF, the salt value should be the "salt" value in the JSON text of the NEW Data. The info bytes used in HKDF is 0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9.

Examples of NEW Interest and Data Exchange

  • Example 1. If the configuration's "probe" is not empty. The NEW Interest must carry a probe token, which is literally the PROBE Data packet.

    Interest:
Name: /ndn/edu/ucla/CA/_NEW/06a49...
ApplicationParameters:
{
  "ecdh-pub": "9ik30...",
  "cert-request": "...",
  "probe-token": "..."
}
Signature

Data:
Name: /ndn/edu/ucla/CA/_NEW/06a49...
Content:
{
"ecdh-pub": "07d60...",
"request-id": "1209381203",
"status": 1,
"challenges": [
  {
  "challenge-id": "PIN"
  },
  {
  "challenge-id": "Email"
  },
  {
  "challenge-id": "Shared-Secret"
  }
]
}
Signature

2.3.3 CHALLENGE Interest and Replied Data

CHALLENGE Interest Format

Name: /<CA-prefix>/CA/_CHALLENGE/[Request_ID]/[ApplicationParameters_Digest]
ApplicationParameters: AES-CBC(JSON text)
InterestSignatureValue: Signed by the private key paired with the public key in Certificate Request
Must Be Fresh: True

JSON Format:

  • "selected-challenge": The challenge selected by the CHALLENGE Interest
  • other attributes specified by the implementation of the selected challenge

Interest Verification Process:

  • The JSON text encrypted with AES-CBC can be successfully decrypted using the shared secret obtained in the ECDH.

  • The Interest must be in the correct signed Interest format as defined in NDN Packet Format.

    However, currently the format v0.3 is not fully supported by ndn-cxx. Therefore, the current implementation will follow the old format of signed Interest until format v0.3 is fully supported by ndn-cxx.

  • The signature value can be verified by the public key obtained in NEW Interest's Interest Parameters.

CHALLENGE Data Format

Name: Same as CHALLENGE Interest Name
Content: AES-CBC(JSON text)
Signature: Signed by CA's identity key

JSON format:

  • "status": The application status code. The decimal string of the status number in little endianness should be placed in the JSON text.

    • STATUS_BEFORE_CHALLENGE = 0,
    • STATUS_CHALLENGE = 1,
    • STATUS_PENDING = 2,
    • STATUS_SUCCESS = 3,
    • STATUS_FAILURE = 4,
    • STATUS_NOT_STARTED = 5

  • "challenge-status": The challenge status code, specified by the selected challenge implementation.

  • "remaining-tries": The remaining times that the requester can send a challenge Interest. The decimal string of the number in little endianness should be placed in the JSON text.

  • "remaining-time": The remaining time for the requester to finish the challenge. The decimal string of the number in little endianness should be placed in the JSON text.

Data Verification Process

  • The JSON text encrypted with AES CBC can be successfully decrypted using the shared secret obtained in the ECDH.
  • The KeyLocator in Data Signature Info element must starts with the /<CA-Prefix>/KEY
  • The signature value must be verified using the public key pre-installed (in warm start scenarios) or obtained in the PROBE Data content (in cold start scenarios).

Examples of CHALLENGE Interest and Data Exchange

  • Example 1. If the configuration's "probe" is not empty. The NEW Interest must carry a probe token, which is literally the PROBE Data packet.

    Interest:
Name: /ndn/edu/ucla/CA/_CHALLANEG/1209381203/4fe9...
ApplicationParameters:
AES-CBC-Encrypt {
  "selected-challenge": "email",
  "email": "zhiyi@cs.ucla.edu"
}
Signature

Data:
Name: /ndn/edu/ucla/CA/_CHALLANEG/1209381203/4fe9...
Content:
AES-CBC-Encrypt {
"status": 1,
"challenge-status": "need-code",
"remaining-tries": 3,
"remaining-time": 3600
}
Signature

Instructions

In CHALLENGE Interest, the selected challenge name and the parameters provided by the requester will be encrypted with AES CBC. In CHALLENGE Data, the whole content will be encrypted with AES CBC. The AES key is the shared secret negotiated from the ECDH in NEW Interest and Data exchange.

After receiving the CHALLENGE Interest packet for the first time, the issuer is supposed to perform the specified challenge to verify the requester's legality.

One or more CHALLENGE Interest and Data exchange can be performed in order to finish the challenge.

Once the "status" JSON attribute is FINISHED in the replied CHALLENGE Data packet, the requester then knows the challenge result has been successfully approved. After that, the requester can send DOWNLOAD Interest to fetch the issued certificate back.

The remaining-tries and remaining-time attributes are used to ensure the freshness of the challenge. The value of the two attributes is supposed to be defined by the specific challenge implementation.

2.3.4 DOWNLOAD Interest and Replied Data

DOWNLOAD Interest Format

Name: /<CA-prefix>/CA/_DOWNLOAD/[Request_ID]
Must Be Fresh: True

DOWNLOAD Data Format

Name: Same as DOWNLOAD Interest Name
Content: Embedded issued certificate
Signature: Signed by CA's identity key

Data Verification Process

  • The KeyLocator in Data Signature Info element of the encapsulated Certificate must starts with the /<CA-Prefix>/KEY
  • The signature value of the encapsulated Certificate must be verified using the public key pre-installed (in warm start scenarios) or obtained in the PROBE Data content (in cold start scenarios).

2.4 AES-Encrypted TLV Format

In the above mentioned NDNCERT cert application/issuance packet exchange process, the JSON texts used after the NEW step are all encrypted with AES CBC. NDNCERT takes a similar format used by Named-based Access Control (NAC) and Named-based Access Control with Attribute-based Encryption (NAC-ABE).

EncryptedPayload = ENCRYPTED_PAYLOAD_TYPE (T) length (L)
                   Bytes+ (V)

InitialVector = INITIAL_VECTOR_TYPE (T) length (L)
                   Bytes+ (V)

Type Number Assignment:
ENCRYPTED_PAYLOAD_TYPE 630
INITIAL_VECTOR_TYPE 632

The above two TLV blocks should be embedded into Interest Parameters element and the Data Content element when used.

3. Certificate Renewal

TBD

4. Certificate Revocation and Revocation Status Query

4.1 Certificate Revocation

In cases when a certificate owner

  • no longer uses the certificate,
  • wants to change the detail of its certificate,
  • found its private key was compromised,

the certificate owner should use certificate revocation protocol to revoke its certificate from the certificate issuer,

In NDNCERT, a certificate owner can use REVOKE Interest packet to revoke its certificate. After receiving the REVOKE Interest, the issuer of the certificate will perform a challenge on the certificate owner to ensure that the requester has the authority to revoke the certificate.

As shown in the figure, the certificate revocation protocol in NDNCERT is like:

  • REVOKE Interest to Start a Revocation

    The requester first sends an interest called REVOKE to inform the issuer which certificate to revoke. The issuer should then return a list of challenges that can be used to verify the requester.

  • CHALLENGE Interest to Select and Finish the Challenge

    The certificate requester then selects one challenge and send a CHALLENGE Interest to notice the issuer which challenge has been selected. After receiving the first CHALLENGE Interest, the issuer will perform the challenge for the requester.

    During the process or after finishing the selected challenge, the request would send more CHALLENGE Interests to pass the required information to the issuer and finish the identity verification. Once the challenge result is approved by the issuer, the issuer will revoke the certificate.

  certificate requester                        CA
            |              REVOKE               |
            | --------------------------------> |
            |                                   |
            |                           Prepare challenge list
            |                            Generate request ID
            |               Data                |
            | <-------------------------------- |
            |                                   |
     select challenge                           |
            |            CHALLENGE              |
            | --------------------------------> |
            |                                   |
            |                            Perform Challenge
            |                                   |
Requester sends more CHALLENGE to finish challenge if needed.
            |                                   |
            |                              Check Challenge .....+
            |                                   |               V
            |                                   |         Verify result
            |               Data                |               V
            | <-------------------------------- |<... If valid, revoke cert
            |                                   |    Otherwise, return status

4.2 Revocation Status Query

Trusting signature signed by a revoked certificate will cause severe security problems. To prevent users from accepting revoked certificates, NDNCERT provides different methods of revocation status query for different scenarios.

4.2.1 Passive Certificate Revocation / No Revocation

This method does not require any certificate revocation operations nor certificate revocation status query. When issuing a certificate at the first place, the issuer should make the certificate validity period short enough so that even the private key is compromised, the damage of the certificate is limited.

4.2.2 Revocation Announcement Query

This method requires certificate revocation operations. When a certificate owner successfully revokes a certificate, the issuer will issue a certificate revocation announcement following the pre-defined naming convention in NDNCERT: the revocation announcement is a Data packet with Data name: /<NDN Certificate Name>/_REVOKE. By querying the announcement, a user can learn whether a certificate has been revoked or not.

With revocation announcement query, an issuer or the revocation requester should make the revocation announcement as available as possible. For example, the announcement can be replicated in many different repositories or stored in a distributed ledger system (e.g., a blockchain-based ledger).

This method does not require the issuer to be online when users want to check the revocation status but this method is considered to be best-effort only since this method subjects to the availability of the announcement Data.

4.2.3 Time-stamped Certificate Status Query

This method mimics the OCSP Stapling extension of TLS Certificate Status Request and realizes the notion of stapling in a named-data style. This method requires the issuer or a separate process/thread to be online regularly (e.g., every one hour, every day, etc.) and issue the certificate status Data packet for all the unrevoked certificates. A certificate status Data serves as a guarantee that a certificate is still valid in the defined time period (e.g., from the current time to the next issuer's online time).

For a producer to offer better consumer experience, a producer can obtain the certificate status Data packets in advance and utilize certificate bundle to bundle the certificates and the certificate status together so that the consumer does not need to fetch the certificate status in real time at the cost of additional latency.

4.3 Certificate Revocation Packet Formats

2.3.1 REVOKE Interest and Replied Data

Interest Format

Name: /<CA-Prefix>/CA/_REVOKE/[ParametersSha256DigestComponent]
ApplicationParameters: JSON text
Signature: Not required
Must Be Fresh: True

JSON Format:

* "ecdh-pub": ECDH_Requester_PubKey: the requester's public key used for Elliptic-Curve Diffie-Hellman key agreement.
* "cert-revoke": The name of the certificate that is to be revoked.

Data Format

Name: Same as REVOKE Interest Name
Content: JSON text
Signature: Signed by CA's identity key

JSON format:

  • "ecdh-pub": ECDH_Issuer_PubKey: the issuer's public key used for Elliptic-Curve Diffie-Hellman key agreement.

  • "salt": 64 bits or longer random number. The decimal string of this number in little endianness should be placed in the JSON text.

  • "request-id": Unique ID assignment for this request instance

  • "status": The application status code. The decimal string of the status number in little endianness should be placed in the JSON text.

    • STATUS_BEFORE_CHALLENGE = 0,
    • STATUS_CHALLENGE = 1,
    • STATUS_PENDING = 2,
    • STATUS_SUCCESS = 3,
    • STATUS_FAILURE = 4,
    • STATUS_NOT_STARTED = 5

  • "challenges": A challenge list from which the requester can select. The list is a JSON array object. The child attribute name is "challenge-id".

Data Verification Process

  • The KeyLocator in Data Signature Info element must starts with the //KEY

  • The signature value must be verified using the public key pre-installed.

    Notice that there is no cold start scenarios in certificate revocation.

Instructions

In the NEW Interest and Data exchange:

  • The requester and the issuer follow Elliptic-Curve Diffie-Hellman (ECDH) protocol and negotiate a shared secret key for future use.

Regarding the public parameters used for ECDH process, there are two options:

  • Global default public parameters: Elliptic Curve NIST p-256 (providing 128 bits security)

  • Customized public parameters can be placed into issuer's configuration. The information is obtained by the issuer with PROBE Interest /<CA-Prefix>/CA/_PROBE/INFO or /ndn/CA/_PROBE/INFO if enabled. In cold start scenarios, the requester cannot verify the issuer's configuration, but this will not damage because when performing a double-direction challenge, if the issuer cannot prove its identity, the requester will abandon all the state related to this application.

The ECDH_Requester_PubKey and the ECDH_Issuer_PubKey are base64-encoded (as specified in RFC 4648 section 3.1) ECDH compressed public key bits. The default length of ECDH public key bits is defined per the ECDH public parameters.

After ECDH process, both the requester and the issuer get a shared secret (256 bits using ECDH NIST p-256). A Key Derivation Function (KDF) will be applied to the shared secret for better security. In NDNCERT, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) will be used to derive a 256-bit AES key from the shared secret from ECDH. The HKDF function will be invoked on the shared secret and also salt. In HKDF, the salt value should be the "salt" value in the JSON text of the REVOKE Data. The info bytes used in HKDF is 0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9.

4.4 Revocation Status Query Packet Formats

4.4.1 Revocation Announcement Packet Format

Interest Format

Name: /<Certificate-Name>/_REVOKE
Signature: Not required

Data Format

Name: Same as REVOKE Interest Name
Content: JSON text
Signature: Signed by CA's identity key

JSON format:

  • "revoke-time": The timestamp when the certificate is revoked.

Data Verification Process

  • The KeyLocator in Data Signature Info element must be the same as the KeyLocator of the revoked Certificate.
  • The signature value must be verified using the public key of the issuer.

4.4.2 Time-stamped Certificate Status Packet Format

Interest Format

Name: /<Certificate-Name>/STATUS
Signature: Not required

Data Format

Name: Same as REVOKE Interest Name
Content: JSON text
Signature: Signed by CA's identity key

JSON format:

  • "cert-status": The status of the certificate

    • 1: VALID
    • 2: REVOKED
    • 0: UNKNOWN

  • "issue-time": The timestamp when the status packet is generated.

  • "valid-before": The timestamp before which the status of the certificate will not be changed.

Data Verification Process

  • The KeyLocator in Data Signature Info element must be the same as the KeyLocator of the revoked Certificate.
  • The signature value must be verified using the public key of the issuer.
Clone this wiki locally