Re: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-keystore-02

["Mehmet Ersue" <[e-mail]>]

We actually asked Datatracker admin to remove [e-mail] from CC but seem
to need to ask again and again.

Cheers,
Mehmet

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, July 20, 2017 7:00 PM
> To: Kent Watsen <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Yangdoctors last call review of
draft-ietf-netconf-keystore-02
> 
> On Wed, Jul 19, 2017 at 09:06:59PM +0000, Kent Watsen wrote:
> > Hi Juergen,
> >
> > Thanks for your review.  Below are my responses to your comments.
> >
> > PS: why is [e-mail] in the CC?
> 
> I used the datatracker form and it does what it does.
> 
> > - There are a number of binary fields where you show explanatory text
> >   in the examples instead of encoded data. Is this always clear?
> >
> >   <private-key>...</private-key> <!-- elipsis placeholder for a base64
> > encoded key -->
> >
> > <KENT> This issue has been raised by others as well.  I used to have
> > full base64 values, but it made the examples very difficult to read.
> > Hmmm, I like your suggestion, but the resulting line is much longer
> > than allowed.  I could line-wrap, but the result looks worse.  Any
> > other suggestions?
> 
> Assuming people will figure out that ... is just a marker, what about
this?
> 
>    <private-key>...</private-key> <!-- base64 encoded key  -->
> 
> > - I am not sure I understand trusted-host-keys. On systems that have
> >   multiple user accounts, you usually have a per account list of
> >   trusted host keys in addition to a global system wide list. Perhaps
> >   make it clear that this models the global known hosts list only?
> >
> > <KENT> it's a list of lists, so there can be many different sets a
> > host-keys defined, with each application/use pointing to its own
> > entry.  The ietf-ssh-client module's grouping has a leafref to a
> > specific entry.  FWIW, this grouping is used by ietf-netconf-client
> > module.  At the moment, there no other uses of this grouping.  I think
> > that you may be getting confused between the key the server presents
> > (the
> > host-key) versus the key user presents.
> > .
> 
> I though these are the authorized host keys? Yes, I am confused. If these
are
> user public keys, they should not be called host keys. But yes, I am
confused
> (but I started to read the other documents).
> 
> > - Should the document title be aligned with other YANG module
> >   definitions, so it is easier to spot it?
> >
> > <KENT> I don't understand, what do you mean?
> 
> We often use "[A] YANG Data Model for ....".
> 
> https://en.wikipedia.org/wiki/YANG#Usage_in_Standards
> 
> The current name does not say YANG (sometimes I search for YANG in the
> RFC index) and Keystore is also pretty broad given the related work we
have.
> 
> > - Since crypto algorithms come and go, is it reasonable to have the
> >   identities defined in a rather static RFC? Would an IANA maintained
> >   identity module perhaps make more sense?
> >
> > <KENT> Unsure, but I wouldn't suspect needing to make that kind of
> > update for a long time.  If we were to define a module for algorithm
> > identities, it might lead to us wanting to define every algorithm (not
> > just public-key algs), which could take some time...
> 
> I think an IANA maintained registry can be as incomplete or complete as
the
> I-D. I understand that the mechanics of working out the proper registry
can
> be painful (there likely are already N registries) but clearly crypto
algorithm
> identities must be easily extensible.
> 
> > - Oh, I now see that the key length is embedded in the algorithm
> >   identity. Perhaps clarify this earlier, see my confused comments
> >   above. Anyway, I think this makes the need for an IANA maintained
> >   module even stronger.
> >
> > <KENT> yes, but your comment before was valid.  I don't see why this
> > makes a stronger case though...
> 
> Well, the notion of what is strong changes every N years.
> 
> > - Why do certificate names have to be unique across all keys?
> >
> > <KENT> because otherwise leafrefs might be ambiguous, right?
> 
> OK. Perhaps explain this detail so it is obvious to everybody.
> 
> > - Since the certs of a key do not contain a signature, where are signed
> >   certificates stored or are they outside the scope of the model?
> >
> > <KENT> I'm confused, certificates are signed structures already...
> 
> Well, the description of certificates/certificate/value says:
> 
>    An unsigned PKCS #7 SignedData structure, as specified
>    by Section 9.1 in RFC 2315, containing just certificates
>    (no content, signatures, or CRLs), encoded using ASN.1
>    distinguished encoding rules (DER), as specified in
>    ITU-T X.690.
> 
> Yes, I am confused how this works.
> 
> > - Is there any text needed to explain what happens if actions can't be
> >   carried out, e.g., the algorithm identity is not supported? Can a
> >   client actually learn which algorithm identities are supported or is
> >   the approach simply trial and error?
> >
> > <KENT> If an action fails, then standard NC/RC error is returned.
> > There is no support to learn which algorithms a server supports, but
> > by supporting this module, the server must support all of these
> > algorithms.
> 
> This may raise a red flag by the security people. They take crypto agility
> serious and there might be very valid reasons to not support some of the
> algorithms at a certain point in time. Actually, there is a difference
between
> supporting (in the sense of implemented) and enabled (in the sense can be
> used).
> 
> Anyway, this is usually regulated by protocol specifications, protocols
often
> define mandatory to implement algorithms etc. Is the keystore going to
> interfer with this? Or should it better be silent about what is mandatory?
> 
> > - I am not sure what 'trusted certificate' here really means. What you
> >   are modeling is a set of sets of certificates. What such a set means
> >   depends on where this list is used. I am not sure what it means for
> >   a certificate in such a set to be 'trusted'.
> >
> > <KENT> yes, the certs may be used by different modules for different
> > use-cases, but they'd always be trusted.  E.g., the certs preinstalled
> > by a browser...
> 
> If an application (i.e. a RESTCONF server) trusts some set of
certificates, the
> certificates in that set become trusted by that specific application. But
> without concrete context, isn't it unclear what is trusting a listed
certificate
> and why?
> 
> > - What about the // rename to 'data' comment? I like it, renaming to
> >   list certificate { key name; leaf name; leaf data; } seems less
> >   confusing (and it is even shorter). Perhaps something along this
> >   line would be better (not sure I like certificate-set)
> >
> > 	 +--rw certificate-set* [name]
> >          |  +--rw name                   string
> >          |  +--rw description?           string
> >          |  +--rw certificate* [name]
> >          |     +--rw name    string
> >          |     +--rw data?   binary
> >
> >
> > <KENT> "set" doesn't sound too bad - dunno.  Regarding moving "data",
> > see the tail-end of the email I sent on July 11.
> 
> Aha. Not sure this resolves this (or I looked at the wrong message).
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>