-
Notifications
You must be signed in to change notification settings - Fork 13
NDNCERT Protocol 0.3 PROBE Extensions
PROBE can be used for a root CA to redirect its requestors to sub CAs. This extension helps to reduce the workload of the root CA and reduce the out-of-band configuration on requesters side, thus improving system scalability and usability.
In PROBE redirection extension, the Interest packet is the same as the one shown in 2.2.2. However, the Data packet reply has a different content format.
Data format with PROBE redirection extension:
Field | Description |
---|---|
Name | /<CA-Prefix>/CA/PROBE/<ParameterSha256Digest> |
FreshnessPeriod | 4 seconds |
Content | A list of probe-response s or probe-redirect s and an optional max-suffix-length
|
Signature | Signed by CA's identity key |
Content = CONTENT-TYPE TLV-LENGTH
*probe-response
*probe-redirect
probe-response = PROBE-RESPONSE-TYPE TLV-LENGTH Name [max-suffix-length]
probe-redirect = PROBE-REDIRECT-TYPE TLV-LENGTH Name
max-suffix-length = MAX-SUFFIX-LENGTH-TYPE TLV-LENGTH NonNegativeInteger
To be more specific, the probe-redirect
carries following information.
-
Name
, bytes value, the full name of the certificate of the CA to redirect to. This full name includes both the certificate name and theImplicitSha256DigestComponent
which contains the SHA-256 hash value of the certificate.
NDNCERT protocol allows more than one probe-redirect
to be replied in the packet.
In this case, the requester can decide which sub CA to move on his/her certificate management operations.
With the probe extension, the No Available Name
error packet is only replied when there is neither probe response nor probe redirect from the CA.
Utilizing PROBE redirection extension, a CA can redirect its requesters to a sub CA.
Requester CA_1
| |
|---------PROBE-------->|
|<----------------------|
CA_2
|-----Obtain CA Profile (RDR)--->|
|<-------------------------------|
| |
| New Certificate Application |
After retrieving CA_2
's profile, the requester should
- use the certificate SHA256 digest obtained from the PROBE Data packet replied by
CA_1
to verify the certificate field in the INFO profile ofCA_2
. - use the public key in the
CA_2
profile'scertificate
field to verify the signature of the INFO Data packet replied byCA_2
.
CA_1
should be aware of the certificate update on CA_2
so that the SHA256 digest of CA_2
's certificate is always updated.
When privacy of the parameters is a concern, ECDH can be used to generate an symmetric key to encrypt the parameters used in PROBE. This requires an additional round trip before the normal PROBE round trip:
- Requester: generates a fresh ECC key pair for ECDH and send the PROBE Interest.
- CA: generate another fresh ECC key pair and reply the public key, salt, along with a request ID.
Both the requester and the CA will take self private key and received public key as input and execute ECDH along with HKDF to generate the symmetric key. The symmetric key will be used to encrypt the Interest ApplicationParameters and Data Content used in the second round trip.
In the first round trip the Interest and Data are in the same format as defined in 2.2.3. but with different Interest ApplicationParameters and Data Content.
Interest format:
Field | Description |
---|---|
Name | /<CA-Prefix>/CA/PROBE/<ParameterSha256Digest> |
ApplicationParameters | ecdh-pub |
Can Be Prefix | False |
Must Be Fresh | True |
Signature | Not required |
-
ecdh-pub
, bytes value, requester's ECC public key used for Elliptic-Curve Diffie-Hellman key agreement. The key should be encoded as its uncompressed format. Such a ECC public key should be generated with cryptographically secure pseudo random generator for every PROBE session. The ECC curve is prime256v1 (same as P-256 and secp256r1).
Data format:
Field | Description |
---|---|
Name | /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest> |
Content |
ecdh-pub , salt , request-id
|
Signature | Signed by CA's identity key |
-
ecdh-pub
, bytes value, the issuer's ECC public key used for Elliptic-Curve Diffie-Hellman key agreement. The key should be encoded as its raw format without compression. Such a ECC public key should be generated with cryptographically secure pseudo random generator for every NDNCERT session. -
salt
, bytes value, 64 bits or longer random number. This value will be used in HKDF (HMAC based Key Derivation Function) to generate the symmetric AES-GCM-128 key to encrypt the Interest ApplicationParameters and Data Content used in CHALLENGE step.
In the second round trip, the Interest/Data are in the format of:
Interest format:
Field | Description |
---|---|
Name | /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest> |
ApplicationParameters |
inital-vector , encrypted-payload
|
Can Be Prefix | False |
Must Be Fresh | True |
Signature | Not required |
-
initial-vector
, 12 bytes value, the IV for AES GCM encryption. -
encrypted-payload
, bytes value, the AES GCM ciphertext. The encrypted content contains the same TLVs as defined in 2.2.2-
probe-parameter
, string value, the same asprobe-parameter
specified in the CA profile. -
probe-parameter-value
, string value, the value of eachprobe-parameter
.
-
Data format:
Field | Description |
---|---|
Name | /<CA-Prefix>/CA/PROBE/<request-id>/<ParameterSha256Digest> |
Content |
inital-vector , encrypted-payload
|
Signature | Signed by CA's identity key |
-
initial-vector
, bytes value, the IV for AES GCM encryption. -
encrypted-payload
, bytes value, the AES GCM ciphertext. The encrypted content contains the same TLVs as defined in 2.2.2 or 2.2.3-
Name
, bytes value, this is defined in ndn packet format. -
ca-prefix
, bytes value, the name TLV of sub CA's prefix. -
digest-of-cert
, bytes value, the SHA256 digest of sub CA's certificate.
-