Re: [Anima-bootstrap] voucher yang

[Kent Watsen <[e-mail]>]

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

But it does.  Some pledges may be coded to only support 'verified' vouchers.


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

The DER itself works for me (the privacy concern seems minor).  It's also more
code (relative to just using an openssl command line option), but actually it's
one step less code than calculating the SHA256 fingerprint.


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

As discussed in another thread, I'm beginning to think that we should
do away with having a single voucher for many devices, because we'd
want revocations to be as granular as possible.


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

Okay, let's change the nonce to a binary type.


Kent