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

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Jul 28, 2017 at 02:12:33AM +0000, Kent Watsen wrote:
> > Assuming people will figure out that ... is just a marker, what about
> > this?
> > 
> >   <private-key>...</private-key> <!-- base64 encoded key  -->
> 
> For this case, it works out nicely.  But, still, there are other
> cases where the string is longer the net result doesn't work out
> great.
> 
> Rob had an idea of using a footnote to keep the line lengths within
> limit.  I'm hoping to not do this, though, as it would be hard to
> automate the compilation of the draft, while maintaining validate-
> able files.
> 
> Here's another idea, it turns out that the string "base64encoded==="
> is itself a valid base64 string.  This could be used everywhere.
> We would lose information about the structure encoded, but maybe
> that's okay, since the examples are in the same section where the
> YANG module is located.  Maybe we only need to worry if 1) is it 
> readable enough? and 2) are folks still going to copy/paste it 
> into examples without thought?
> 
> Recap: we're trying to avoid having real base64 encoded data
> examples because the net-result is a whole lot of unintelligible
> text.  
> 
> Not that it has bearing, but I never seriously tried to encode 
> the binary structures used in the action statements.  If we 
> decided to have real base64 encoded data examples, we'd have
> to write custom code for them, which would be a good proof 
> point of sorts. That said, it'd be even better if the entire
> keystore module were implemented.  Running code, right?

Using

  <private-key>base64encoded===</private-key>

sounds like an interesting option since this should allow tools to
validate the instance documents (and this is what I am really looking
for).
 
> >> - 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).
> 
> This leaf encodes an SSH public key (RFC4253, 6.6), same as used in 
> /ietf-system/system/user/authorized-key/key-data (and I have changed
> this leaf's type to match it in my local copy already), but the uses
> are different.  In ietf-system, the authorized-key is configured on
> a server in order to authenticate subsequent SSH-client connections.
> Here, we're taking about the key that that SSH-server presents to
> the client.  These are the host keys that OpenSSL often puts into the 
> ~/.ssh/known-hosts file.

I understand what you are modeling is /etc/ssh/ssh_host_rsa_key.pub
and friends. Make sure it is described clearly. Or do you actually
mean the clients cache of authenticated keys that goes into an
account's known-hosts file? In this case, the keystore may be the
wrong place.
 
> >> - 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.
> 
> Gotcha, how about "YANG Data Model for Keystores"?

Yes, except that 'keystores' leaves readers unclear about the scope. I
commented several times that the names of this module and the other
module for symmetric keys are unfortunate. Concerning the SSH keys, I
am still concerned that we would be better off to have a separate SSH
module that takes care about managing an SSH server's host keys and
then this module would be X509 certificate specific, i.e., a 'YANG
Data Model for Managing X.509 Keys and Certificates' would be a clear
and well defined scope.

> >> - 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.
> 
> In another thread, we concluded that we might want to ask SecDir.

Or just acknowledge that in the longer term an IANA solution may be
needed but we do this later.

> >> - 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.
>  
> Okay, now I understand your confusion.  I believe the text is 
> accurate.  Think of the PKCS#7 structure being a little like a 
> TAR file that contains a directory structure like this:
> 
>  pkcs7:
>   /signed-info
>   /signature   - this sig is only over 'signed-info' ...
>   /extra-certificates
>   /extra-revocation-objects
> 
> So, in this case, we're using a degenerate form of the pkcs7
> structure that has no content (signed-info), signature, or CRLs 
> (revocation-objects), it only contains the certificates. Perhaps
> my use of the word "unsigned" isn't clear enough?

So why pkcs7, is this what implementations use? The certificates I find
in /etc/ssl/certs on my Debian system seem to be in PEM format.
 
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>