On Mon, May 22, 2017 at 2:56 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> RFC 7952 says:
>
>    4.  Annotations sent by a server should not break clients that don't
>        support them.
>
> If the client is expected to understand which hash function has been
> used to generate a hash value, then I think the hash function should
> be communicated as proper YANG data and not as metadata.
>
>
Agreed.

Also, the annotation extension cannot constrain the usage of the XML
attribute.
It is supposed to apply to any data node (clearly hash-function does not
apply to
every data node.) Since it is data-node specific, it is not metadata; just
more data.



> /js
>

Andy


>
> On Mon, May 22, 2017 at 05:16:36PM +0000, Sterne, Jason (Nokia -
> CA/Ottawa) wrote:
> > Hi all,
> >
> > Does anyone see any reasons why RFC7952 annotations couldn't/shouldn't
> be used to identify the encryption/hashing format of an encrypted/hashed
> leaf ?
> >
> > There are a number of approaches out there for encrypted/hashed leafs
> (e.g. RFC7317 crypt-hash which encodes the hash function by prepending $x$
> to the password, using multiple leafs for the value/algorithm, etc).
> >
> > These are leafs that can be typically written in cleartext or
> encrypted/hashed format, but return only an encrypted/hashed format when
> retrieved from a device.
> >
> > I think RFC7952 annotation could also be used as an approach to this
> problem.
> >
> > Annotation definition:
> >
> >      md:annotation hash-format {
> >        type enumeration {
> >          enum md5l
> >          enum sha-256
> >          ...
> >        }
> >      }
> >
> > An 'auth-key' leaf that is hashed:
> >
> >     <auth-key hash-format="sha-256">
> >       QsdsEWfjKAowjjhQHHslJSHHll
> >     </auth-key>
> >
> >
> > Regards,
> > Jason
> >
> > Note - I don't believe this statement in section 9 would point anyone
> away from using annotations for encryption/hashing information (since the
> encrypted leafs are data nodes):  "It is RECOMMENDED that
> security-sensitive or privacy-sensitive data be modeled as regular YANG
> data nodes rather than annotations."
> >
> >
> >
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to