Subject: [Anima] getting the constrained MASA voucher signing public key to JRC

From: Michael Richardson <[email-masked]>
Date: Tue, 29 May 2018 16:00:10 -0400

In BRSKI and the constrained version described in
draft-ietf-6tisch-dtsecurity-zerotouch-join, the voucher is signed by
the MASA using a key that has been pre-installed into the pledge by
the manufacturer.    The pledge can validate the voucher because the
MASA knows (by constructin) which keys the pledge knows about.

The Registrar (JRC) that mediates the operation, and which is vouched
for by the voucher using the pinned-domain-cert.  The Registrar does not
*NEED* to validate the voucher, implementations might want to do this
because it's useful to know whether the voucher validates as part of
the audit-trail.

In the CMS case, there isn't any great constraint on the signed CMS
structure, and one can easily include any needed public keys for the MASA
as part of the unprotected SignedData.certificates.

When the signature mechanism is COSE however in the constrained-voucher
situation.  In such a situation, the RFC8152 provides four buckets:
    <https://tools.ietf.org/html/rfc8152#section-4.2>
    protected
    unprotected
    payload
    signature

We are using the CBOR SID mechanism to provide a keys for the mapping of the
YANG voucher model into the protected bucket.  It's unclear to me if we
should be including "alg" into that bucket as well.  

The question that arises is how (and if!!) to convey the MASA's public key to
the Registrar.  Secondary to this is in what format(s).

Options are:
1) use the COSE(8152, section 3.1) kid parameter.

2) actually say we are using CWT, and make use of the claims in
   RFC8392, and the x5c is listed in some other document I can't find right
   now.
   
3) use our own SID value(s) for some set of Raw-Public-Key or PKIX format key
   which would be placed in the unprotected bucket.
   The Registrar would be encouraged to *remove* those keys from the
   unprotected bucket to reduce space.

4) provide an entirely new BRSKI-MASA API call by which the Registrar can
   retrieve the right set of public keys to validate the voucher with.

5) use the existing /voucherrequest, but define the result (when an
   application/cbor+cose voucher request is presented) to be a multipart
   result, with the second piece being the public key "bag".

6) like (5), but instead of MIME multipart, return a CBOR array with
   the voucher as the first item, and the extra keys as additional entries.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [