Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

[Eliot Lear <[e-mail]>]

Hi Kent,

Thanks for the pointer.  The zeroconf draft is cool beans to be sure. 
That describes an enrollment mechanism for devices that make use of
802.1AR.  Very ANIMAesque.  What I'm suggesting, and perhaps it's a bit
late for this draft, is just a statement in this draft along the lines
that "signing and verifying happens at the JSON level; see [ref] for how
to do it", and for extra credit an example would be exceedingly cool. 
That way we as developers know what to do (again, I'm neither a JSON nor
netmod expert - just trying to make use of what's there for what I am
expert at (or so I think)).

Eliot




On 3/21/16 4:55 PM, Kent Watsen wrote:
>
> the zerotouch draft uses object signing.   XMLSIG was used in earlier
> draft, but was replaced with a binary type leaf called 'signature'
> having the following description:
>
>
>
> description "A PKCS #7 SignedData structure as specified by RFC
> <https://tools.ietf.org/html/rfc2315> 2315
> <https://tools.ietf.org/html/rfc2315>, Section 9.1
> <https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-07#section-9.1>
> encoded using the ASN.1 distinguished encoding rules (DER), as
> specified in ITU-T X.690. This signature is generated using the
> owner's private private key and an owner-selected digest algorithm
> over the redirect-information or the bootstrap-information nodes,
> which ever is present, and in whatever encoding they are presented in
> (e.g., XML, JSON, etc.)."; // is there a canonical format? reference
> "RFC 2315 <https://tools.ietf.org/html/rfc2315>: PKCS #7:
> Cryptographic Message Syntax Version 1.5 ITU-T X.690: Information
> technology - ASN.1 encoding rules: Specification of Basic Encoding
> Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
> Rules (DER)."; }
> Note a question regarding canonical format.  As the draft stands, no
> format is canonical format is required.  The data can be however the
> data is provided, by the server when pulling on the RESTCONF resource
> URL, or how it is encoded in a message buffer, or encoded to a file on
> disk.
>
> The use of PKCS #7 signing was selected to simplify implementations,
> especially on resource-constrained devices.  Use of DER encoded ASN.1
> structure was selected to be consistent with other parts of the draft
> as well as parts of the server-model draft (in the keychain section). 
>
> Thanks,
> Kent
>
> On Mar 21, 2016, at 11:30 AM, Eliot Lear <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>>
>>
>> On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote:
>>> Lada, I think Stephen asks about JSON encoded YANG-defined data that
>>> is signed, that is, the JSON serialization itself is signed. What
>>> happens to the signature if you convert the JSON to corresponding XML
>>> serialization. I think the answer is that the signature is broken in
>>> this case and I think this is quite natural.
>>>
>>> Object signatures so far never came up in the NETCONF/YANG context
>>> (well not quite correct, I think there is some related discussion
>>> aroud the zero-config draft) but even if they do, I think we will have
>>> to accept that signatures are encoding specific. And I think this is
>>> not a big deal; if I sign my HTML encoded email, then the signature
>>> likely won't apply to a text-only rendering of the same email.
>>>
>>
>> However this goes, it should be well documented somewhere.  This will
>> not be the first time this comes up (he says, knowingly).
>>
>> Eliot
>>