Re: [Anima-bootstrap] voucher yang

[Michael Richardson <[e-mail]>]

Kent Watsen <[e-mail]> wrote:

    > 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.

What I'm saying is that the pledge can't know how the owner was verified.
The pledge actually has to process the same as for "verified" as for
"logged".  It doesn't change the pledge's behaviour.

    >> 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?

If we have to pick something, let's pick SHA256 for now, or maybe, as I wrote
in the other message I CC to spasm, maybe we should just put the DER itself?

    >> 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?

I don't know. I don't want either :-)
If I have to pick a regex library (vs shell-style globbing...) then I'd
rather pick PCRE if we can find a stable reference.

    >> 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?

I want as much entropy in as small a space as possible.
string seems to waste 2-bits per byte if it's base64 encoded in a binary
format (CBOR).  If JSON has to base64 encode things, I'm okay with that.

I would assume that integers get network-byte order considerations which
might lead to implementation bugs, where as binary[8] (if such a thing
exists) would not.  I think uint64 might be too small.

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