new protocol & setup scripts

1 files changed, 18 insertions, 16 deletions

diff --git a/doc/rvi_protocol.md b/doc/rvi_protocol.md
index ab1de75..e59c0ac 100644
--- a/doc/rvi_protocol.md
+++ b/doc/rvi_protocol.md
@@ -134,7 +134,7 @@ functions are (for now) outside the scope of the RVI Core protocol.
 ## Double connect resolution
 There is a risk that two parties try to initiate a connection to each
 other in a race condition, creating two connections between them, as
-shown below. 
+shown below.
 
 Connection 1 | Connection 2
 :------:|:------:
@@ -402,6 +402,8 @@ Parameter      | Required | Description
 --device\_cert | Yes      | The PEM-encoded device X.509 certificate to embed into the credential as the device_cert member.
 --invoke       | Yes      | Space separated list (within quotes) of RVI service prefixes that the owner of the credential has the right to invoke.
 --register     | Yes      | Space separated list (within quotes) of RVI service prefixes that the owner of the credential has the right to register for others to call (with the right credential).
+--start        | No       | The Unix timestamps when the credential becomes active.
+--stop         | No       | The Unix timestamps when the credential becomes inactive.
 
 The generated ```insecure_credential.json```
 and ```insecure_credential.jwt``` are checked into ```priv/sample_credentials```.
@@ -616,7 +618,7 @@ certificates with a private root key. Devices with the corresponding
 public root key will be able to authenticate signed device keys and
 authorize signed certificates.
 
-### Root key 
+### Root key
 A root key, a 4096+ bit RSA key pair, is generated once for an issuer
 of certificates.  The private key is stored in the certificate
 issuer's servers and is not shared.  The public key is manually
@@ -641,12 +643,12 @@ and is not shared. The public part of the key is used in two ways:
    Embdded in the authenticate packet are one or more certificates
    proving the sending RVI node's right to register and invoke
    services. The certificate, signed by the private root key of the
-   issuer, contains the public key of the sending device encoded as 
+   issuer, contains the public key of the sending device encoded as
    JWT structure. This public device key can be used by a
    receiver to verify the signature of a service invocation requests
    sent by the remote RVI node.
 
-### Certificate 
+### Certificate
 
 A certificate is a JSON Web Token, signed by the private root key of
 the certificate issuer, that proves that the RVI node with a given
@@ -782,7 +784,7 @@ private root key stored in ```my_root_key_priv.pem```, generated above.
 The RVI node itself is never aware of that file.
 
 The RVI node does need the public root key, stored in ```my_root_key_pub.pem```,
-is referenced from the RVI's configuration file stored 
+is referenced from the RVI's configuration file stored
 as ```{ rvi_core, { provisioning_key, "..../my_root_key_pub.pem" }}```.
 
 
@@ -812,20 +814,20 @@ Once executed, three files will be created:
 
 1. **```my_device_key_priv.pem```**<br>
    This file contains the private/public key pair that must never leave
-   the device's trusted environment. It will be used to sign 
+   the device's trusted environment. It will be used to sign
    outgoing service invocation request.
 
 2. **```my_device_key_pub.pem```**<br>
-   This file contains the public-only key that is to be added to 
+   This file contains the public-only key that is to be added to
    certificates issued for the device by a certificate issuer.
-   
+
 3. **```my_device_key_pub_sign.jwt```**<br>
    This file contains the public-only key, signed by the root key,
    that is to be provided as authentication when an RVI node identifies
    itself toward another. The file is stored in JSON Web Token format.
 
 
-#### Configuring RVI to use a device key 
+#### Configuring RVI to use a device key
 
 The RVI node needs the device private/public key root key, stored in
 ```my_device_key_priv.pem```, is referenced from the RVI's configuration
@@ -901,9 +903,9 @@ Once executed, one mandatory and one optional file will be created:
    This file contains the generated certificate, signed by the
    private root key specified by ```--root_key=```. The content
    of this file will be provided by an RVI node to prove its righ
-   to register and invoke services toward remote RVI nodes 
+   to register and invoke services toward remote RVI nodes
+
 
-	
 2. **```my_cert.json```**<br>
    Only created if ```--cert_out=``` has been give. Contains a human
    readable JSON form of the generated root key.
@@ -931,10 +933,10 @@ the control of the provisioning server.
 An device-specific key pair is generated by device and stored locally.
 
 The app has one pre-provisioned certificate, signed by the
-root server, allowing it to invoke ```jlr.com/provisioning/init_setup``` 
+root server, allowing it to invoke ```jlr.com/provisioning/init_setup```
 and ```jlr.com/provisioning/request_provisioning```. The certificate also
-provides the right to register ```jlr.com/mobile/*/dm/cert_provision``` 
-and ```jlr.com/mobile/*/dm/signed_pub_key_provision``` 
+provides the right to register ```jlr.com/mobile/*/dm/cert_provision```
+and ```jlr.com/mobile/*/dm/signed_pub_key_provision```
 The certificate keys section, normally holding public device
 keys, is empty.
 
@@ -954,7 +956,7 @@ setup an initial contact.
    The command contains no key, only a single pre-provisioned node certificate giving
    the device the right to invoke and register the functions listed in
    above.<br>
-                        
+
 3. Server sends authenticate to device<br>
    The server's public device key, signed by the root private key, is
    sent together with no node certificates, thus giving the server no
@@ -1116,7 +1118,7 @@ state through a invocation to ```jlr.com/mobile/1234/confirm_unlock```
 
 ### Thwarting self-provisioning process - Replay TBD.
 
-The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device. 
+The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device.
 
 Given that the side band network has not been compromised, I can't see how a MITM / replay attack can give a remote remote attacker the ability to gain access of the root-signed public device key and/or use a certificate.