[Anima] underspecification in handling of unsigned voucher requests

[Michael Richardson <[e-mail]>]

Max, one of the hurdles that the Fairhair Alliance interop experienced was
due to under-specification of the unsigned pledge request.  Most implemented
unsigned pledge requests because it was simpler.

In the past two weeks I was trying to implement unsigned pledge requests, and
I had a number of assumptions challenged in the process.
I am seriously of the opinion that unsigned voucher requests (whether
constrained or not) may have no value at all and should be removed.
(At least, I would like to write that they are unwelcome in the ACP
applicability section)

Assumptions I had which were not verified by our text:

1) that the unsigned voucher request should be placed into
   prior-signed-voucher-request in (parboiled: Registrar->MASA)
   voucher-request.
   The MASA can distinguish between a signed object (which may be a voucher
   request, or a prior signed voucher for renewals[%1]).

2) that the unsigned voucher request should even be copied to the MASA *AT ALL*
   We don't say anything about that.  We hardly even talk about the
   processing.
   I enclose text/diff at the bottom to change that.

3) I assumed that the proximity-registrar-cert has meaning in the unsigned
   voucher-request.  One might claim that it's presence provides no value at
   all since the request is not signed.
   The only piece that has any value would seem to be the nonce.
   So if the pledge has a clock and does not need freshness in it's voucher,
   it could use a time-limited voucher (expiry-on set), then it would
   essentially send an empty voucher-request.  This surprised me to realize.

4) If the unsigned voucher-request has no value/content, why send it on to
   the MASA at all.  I pondered this for awhile, and then remembered that
   this is a channel from the Pledge to the MASA, and that we wanted to
   permit this channel to be extensible and available for proprietary uses if
   desired.  We have this for signed voucher-requests as is.
   If we want to maintain this for unsigned voucher-requests, then we need
   to mandate that it be passed upwards.

Putting unsigned (JSON) into prior-signed-voucher-request seems wrong from a
YANG point of view: see next message on that.

[%1] - can vouchers with nonces be renewed by the MASA?  I think we will need
     clarifying text once someone has implemented this.

diff --git a/dtbootstrap-anima-keyinfra.txt b/dtbootstrap-anima-keyinfra.txt
index a5c4163..8ac806b 100644
--- a/dtbootstrap-anima-keyinfra.txt
+++ b/dtbootstrap-anima-keyinfra.txt
@@ -2062,17 +2118,30 @@ Internet-Draft                    BRSKI                    November 2018
    Example 1.

    The registrar validates the client identity as described in EST
-   [RFC7030] section 3.3.2.  If the request is signed the registrar
-   confirms that the 'proximity' asserion and associated 'proximity-
-   registrar-cert' are correct.

+   [RFC7030] section 3.3.2.  This involves validating the signatory of
+   the TLS Client Certificate.  As described in the next section, there
+   are different models for authorizing accepted devices.

+
+
+   If the request is signed the registrar confirms that the voucher-
+   request is signed by the same key as terminates the TLS connection.

+   The Registrar extracts the serial-number of the pledge from the TLS
+   Client Certificate.  It uses this serial-number to form it's voucher-
+   request.
+
+   The Registrar examines the pledge's voucher-request (verifying the
+   signature, if the request is signed) and extracts any nonce present
+   to include in it's voucher-request.  In addition, any 'proximity'
+   assertion and associated 'proximity-registrar-cert' need to be
+   verified to be correct.




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-