Re: [Anima-bootstrap] voucher yang

[Kent Watsen <[e-mail]>]

Hi Michael,


> Kent, thanks for the updates to the YANG for the voucher.
> Some comments:
>
>      leaf assertion {
>        description
>          "The assertion is a statement from the MASA regarding how
>           the owner was verified.   This statement enables pledges
>           to support more detailed policy checks.  Pledges MUST
>           ensure that the assertion provided is acceptable before
>           processing the voucher.";
>
>I think that it's more about the registrar than the pledge activity.

While the registrar can inspect the voucher, it ultimately must pass
it to the pledge unmodified.  Also, note that there no "registrar" 
concept in the NETCONF zerotouch draft.


>        leaf subject-hash {
>          type binary;
>          description
>
> Will there be an update to RFC5280 that will unlock us from SHA-1?
> Are all of subject-hash/cn-id/dns-id required, or is it one of the above?

As the description statement explains, SHA-1 is used because it is
interoperable with OpenSSL.  We could hardcode SHA-256, or even allow
it be to parameterized, but that would put more code on the pledges,
do you want to go this route?


>      leaf-list device-identifier {
>        type string;
>        min-elements 1;
>        description
>          "A non-empty list of POSIX regular expressions, each
>           identifying one or more device identifiers (e.g., serial
>           numbers). For instance, the expression could match just
>           a single serial number, or it might match a range of
>           serial numbers.
>
>           When processing a vouchers, pledges MUST ensure that their
>           unique identifier matches at least one regular expression in
>           the list.  If no matching regular expression is found, the
>           pledge MUST NOT process this voucher.";
>
> Oh, wow. I'd really rather not have a regex here!
> I'm more worried about the possible Turing-completeness of the regex rather
> than the code space issue.  I think in IoT, if the device hasn't got a
> regex parser, then the vendor just won't issue vouchers with regex in them,
> so that is okay.
> If we have to, I guess I'd rather have a PCRE if we can find a specification
> for that.

I'm okay with PCRE in theory, but I've read that a compiled stripped 
library is large, do you know?


>      leaf nonce {
>        type string;  // unit64?
>
> I think it should be binary?

A 'binary' type would allow the nonce to be any length octet sequence,
which is converted to base64 encoded string for JSON.  Is this what 
you want?


Kent