-
Notifications
You must be signed in to change notification settings - Fork 13
NDNCERT Challenge PIN
PIN Challenge assumes the certificate requester and certificate authority can agree on a generated PIN in some out-of-band method. This document doesn't define any specific method how this agreement can be reached.
The operations of PIN Challenge can be summarized as follows:
- Challenge selection
- Reaching agreement out-of-band on PIN code
- Challenge confirmation
- Success or failure
An example of the overall process is shown in the following diagram:
requester CA
| NEW STEP |
| |
| Interest /ndn/edu/ucla/CA/_NEW/[digest] |
| Param = {"eddh-pub", CertRequest}, |
| Signed by Requester |
| ---------------------------------------------------------------------> |
| |
| Data, Content={"eddh-pub", "request-id", "status", |
| "challenges" (contain "PIN")} |
| Signed by CA |
| <----------------------------------------------------------------------|
| |
| CHALLENGE STEP |
| |
| Interest /ndn/edu/ucla/CA/_CHALLENGE/[request-id]/[digest] |
| Param = AES{"selected-challenge"}, |
| Signed by Requester |
| ---------------------------------------------------------------------> |
| |
| Generate PIN code
| |
| Data, |
| Content=AES{"status", "challenge-status", |
| "remaining-tries", "remaining-time"} |
| Signed by CA |
| <--------------------------------------------------------------------- |
| |
~ |
Discover PIN code |
~ |
| |
| Interest /ndn/edu/ucla/CA/_CHALLENGE/[request-id]/[digest] |
| Param = AES{"code"} |
| Signed by Requester |
| ---------------------------------------------------------------------> |
| |
| |
| Data |
| Content=AES{"status", "challenge-status", |
| "remaining-tries", "remaining-time"} |
| Signed by CA |
| <--------------------------------------------------------------------- |
| |
-
(Pre-knowledge) The requester build up the trust to CA (installed the CA's certificate).
-
(Pre-knowledge) The requester determines from which CA certificate should be requested.
/zhiyi/CA
-
(Pre-knowledge) The requester determines which type of CA (= how namespace is managed).
-
If CA type requires/provides
_PROBE
capabilities, determine the available/allowed namespace for the sub-identity, e.g.,/zhiyi/iphone
. -
Generate a key-pair and the certificate request.
/zhiyi/iphone/KEY/%01/cert-request/%00
- Send
_NEW
command to the CA.
/zhiyi/CA/_NEW/
-
Validate the signature of reply data. Get the request ID and available challenge list from data.
-
Send
_CHALLENGE
command, selectingPIN
as a challenge.
/zhiyi/CA/_CHALLENGE/[request-id]
-
Validate the signature of reply data.
-
(Out-of-band) Reach agreement on PIN.
-
Send
_CHALLENGE
command, confirming the PIN.
/zhiyi/CA/_VALIDATE/[request-id]
- Validate the signature of reply data. If response to
_CHALLENGE
is success, the requester can download the certificate using_DOWNLOAD
. If response is pending, periodically send_CHALLENGE
requests to update the status.