NDNCERT Protocol 0.3 Challenges

NDNCERT v0.3 Pre-defined Challenges

The identity verification challenge is a key component in NDNCERT. It helps the CA to verify the identity of the client (or optionally help the client to verify the CA at the same time).

For the sake for explanation, we define the notations as follows:

• In, the nth Interest packet sent by the requester. For example, I1 is the first CHALLENGE Interest.
• Dn, the nth Data packet sent by the CA. For example, D1 is the first CHALLENGE Data.
• selected-challenge, UTF-8 string of the challenge selected by the requester.
• challenge-status, the UTF-8 string representing the progress of the challenge.
• parameter-key, UTF-8 string representing the name of a parameter required by the selected challenge.
• parameter-value, binary value of the parameter.
• CSPRG, a Cryptographically Secure Pseudo Random Generator.

1. PIN Code Challenge

1.1 Overview

• Challenge ID: pin
• Description: The CA requires the requester to provide a secret PIN code that is generated by the CA.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: 3600 seconds
• Allowed number of attempts: 3

1.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=pin	The requester selects PIN code challenge.
D1	challenge-status=need-code	After receiving I1, the CA generates a 6 digit number, denoted by S, with CSPRG and reply D1.
I2	parameter-key=code, parameter-value=123456(UTF-8 String Value)	After receiving D1, the requester should obtain the secret PIN code through out-of-band means and then send an Interest packet carrying the secret.
D2	challenge-status=success or wrong-code	After receiving I2, the CA compares 123456 with S. If equal, the challenge succeeds; otherwise, reply wrong-code and allow the requester to repeat I2 until running out of tries or time.

• wrong-code will cause decrease of remaining-tries

2. Email Challenge

2.1 Overview

• Challenge ID: email
• Description: The CA requires the requester to provide a secret PIN code that is generated by the CA and sent to an email address.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: 300 seconds
• Allowed number of attempts: 3

2.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=email, parameter-key=email, parameter-value=alice@example.com	The requester selects email challenge and provide its email address.
D1	challenge-status=need-code or invalid-email	After receiving I1 and verifying the email address can be used for the requested certificate, the CA generates a 6 digit number, denoted by S with CSPRG, send an email containing S to alice@example.com, and reply D1. If the email format is wrong or cannot be used for the certificate applicatoin, CA replies invalid-email to ask the requester to resend I1.
I2	parameter-key=code, parameter-value=123456 (UTF-8 String Value)	After receiving D1, the requester should obtain the secret code by checking the email account and then send an Interest packet carrying the secret.
D2	challenge-status=success or wrong-code	After receiving I2, the CA compares 123456 with S. If equal, the challenge succeeds; otherwise, reply wrong-code and allow the requester to repeat I2 until running out of tries or time.

• invalid-email will cause decrease of remaining-tries
• wrong-code will cause decrease of remaining-tries

3. Proof Of Possession Challenge

3.1 Overview

• Challenge ID: possession
• Description: The CA requires the requester to prove their ownership of a certificate issued by the same or a different CA.
• Required round trips: 2
• Require out-of-band operations: no
• Mutual Verification: no
• Time limit: 60 seconds
• Allowed number of attempts: 1

3.2 Challenge Specification

1. The requester transmits a CHALLENGE request with the following payload:

   • selected-challenge: possession
   • parameter-key: issued-cert
   • parameter-value: TLV encoding of CertificateV2, which is an existing certificate issued by the same or a different CA

2. The CA generates a 128-bit random number, and then responds with a CHALLENGE response with payload:

   • status: 1 (challenge in progress)
   • challenge-status: need-proof
   • remaining-tries
   • remaining-time
   • parameter-key: nonce
   • parameter-value: the 128-bit random number, in 16OCTET format

3. The requester signs the 128-bit random number with the private key corresponding to the existing certificate, and then transmits a CHALLENGE request with the following payload:

   • selected-challenge: possession
   • parameter-key: proof
   • parameter-value: a signature over the 128-bit random number

4. The CA validates the provided certificate against its policy, and checks the proof signature against the public key enclosed in the provided certificate.

   The CA fails the challenge if any of these applies:

   • The provided certificate is malformed.
   • The provided certificate has expired.
   • The provided certificate has been revoked.
   • The provided certificate is not trusted according to the CA's trust schema.
   • The provided certificate is not authorized to obtain the requested certificate according to the CA's policy.
   • The proof signature cannot be validated against the enclosed public key.

   If the challenge fails, the CA responds with a CHALLENGE response with payload:

   • status: 4 (failed)

   Note that the CA cannot leak any information about why the challenge has failed. Even if some of these validations could have occurred in step 2, the CA cannot return an error at that step.

   If the challenge successes, the CA continues to certificate issuance step as defined in the main NDNCERT protocol.

4. DNS Challenge

4.1 Overview

• Challenge ID: dns
• Description: The CA requires the requester to prove domain ownership by creating a DNS TXT record containing a challenge token.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: CA defined (e.g., 300 seconds)
• Allowed number of attempts: CA defined (e.g., 3)

4.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=dns, parameter-key=domain, parameter-value=example.com	The requester selects the DNS challenge and provides the domain name they want to validate.
D1	challenge-status=need-record or error INVALID_PARAMETER	After receiving I1 and verifying the domain name format against standard RFC 1123 criteria, the CA generates a unique challenge token and replies D1. D1 includes parameter-key=record-name with parameter-value=_ndncert-challenge.example.com and parameter-key=expected-value with parameter-value=<challenge-token>. If the domain format is invalid, the CA responds with an INVALID_PARAMETER error to ask the requester to resend I1.
I2	parameter-key=confirmation, parameter-value=ready (UTF-8 String Value)	After receiving D1, the requester should create the DNS TXT record using the provided record name and challenge token through out-of-band means, and then send an Interest packet confirming it is ready.
D2	challenge-status=success or wrong-record	After receiving I2, the CA performs a DNS lookup to verify the TXT record. If the returned record matches the token, the challenge succeeds; otherwise, it replies wrong-record and allows the requester to repeat I2 until running out of tries or time.

• <challenge-token> is computed as SHA256(random-secret + "." + SHA256(requester-public-key)).
• The DNS TXT record can be set with any reasonable TTL (e.g., 300 seconds).
• INVALID_PARAMETER will cause the challenge to fail immediately.
• wrong-record will cause a decrease of remaining-tries.
• OUT_OF_TRIES and OUT_OF_TIME will result in challenge failure if the limits are exhausted.

5. DNS-01 Challenge

This challenge follows the guidance of RFC 8555 Sections 8.1 and 8.4.

5.1 Overview

• Challenge ID: dns-01
• Description: The CA requires the requester to prove domain ownership by creating a DNS TXT record whose value is derived from a CA-issued token and the requester's public key.
• Required round trips: 2
• Require out-of-band operations: yes
• Mutual Verification: no
• Time limit: 3600 seconds
• Allowed number of attempts: 5

5.2 Challenge Specification

Message	Payload	Description
I1	selected-challenge=dns-01, parameter-key=domain, parameter-value=<domain>	The requester selects the DNS-01 challenge and provides the domain name to validate.
D1	challenge-status=need-record	After receiving I1, the CA generates <token> and replies D1 with parameter-key=token and parameter-value=<token> (UTF-8 String Value).
I2	parameter-key=confirmation, parameter-value=ready (UTF-8 String Value)	After receiving D1, the requester computes <record-value>, creates the DNS TXT record at _ndncert-challenge.<domain>, and then sends I2 to confirm that the record is ready.
D2	challenge-status=success or wrong-record	After receiving I2, the CA queries the TXT records at _ndncert-challenge.<domain> and computes <record-value>. If one of the returned TXT records matches <record-value>, the challenge succeeds; otherwise, reply wrong-record and allow the requester to repeat I2 until they run out of tries or time.

• <token> must be unique per request; it must contain at least 128 bits of entropy and must not contain any characters outside the base64url alphabet, including padding characters (=).
• <key-authorization> = <token> || "." || base64url(SHA-256(requester-public-key)), where requester-public-key is extracted from the NEW step's cert-request.
• <record-value> = base64url(SHA-256(<key-authorization>)). base64url denotes the URL-safe base64 encoding of RFC 4648 Section 5, with all trailing = characters omitted.
• The DNS TXT record should have a short TTL (e.g., 60 seconds).
• After the challenge concludes, the requester should remove the DNS TXT record.
• wrong-record will cause a decrease of remaining-tries.