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

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 17 Jul 2017 01:43:28 -0700

Reviewer: Jürgen Schönwälder
Review result: Not Ready

draft-ietf-netconf-keystore-02

- s/YANG data module/YANG module/ or s/YANG data module/YANG model/

- Find a better phrase for 'hold onto'. Does the module allow
  configuration of trusted private keys and certificates? If so, say
  so.

- What is 'extends special consideration'?

- What is a 'semi-configurable' list?

- s/is MAY/MAY/ (does this may need to be allcaps?)

- s/an optional attributes/optional attributes/

- the module seems to use actions but the surrounding text talks about
  rpcs

- does the generate-private-key really take a key length as a parameter
  as promised in section 2?

- section 2.2. talks about 'examples above' but there are none 'above'

- Have the examples been validated? Is rsa1024 a valid identityref
  value?

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

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

- Is it helpful that some examples use XML / NETCONF while others use
  JSON / RESTCONF or is this possibly confusing? If you include JSON
  examples, do you not need to reference RFC 7951?

- s/(c) 2014/(c) 2017/

- reference statement of the revision statement seems to have the
  wrong title

- Should the document title be aligned with other YANG module
  definitions, so it is easier to spot it?

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

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

- "If additional algorithms are needed, they MAY be augmented in by
  another module" seems confusing; I think all that is needed is to
  define a new identity, right? If so, there is no augmentation in the
  YANG sense.

- The description of the keystore container talks about passwords and
  I am not sure this is correct. I am also not sure the terms 'active
  material' and 'passive material' really help.

- The description of keys says "A list of keys maintained by the
  keystore.". I think it would be more helpful to say "A list of
  public-private key pairs maintained by the keystore." Every list
  element seems to have two keys.

- What about the comment in the definition of algorithm-identifier?
  Looks like an open issue or something that should be resolved before
  publishing this document.

- Add a reference clause to the definition of private-key? Do we
  really need the INACCESSIBLE enum and the union? There is another
  open question right below the private-key definition...

- Add a reference clause to the definition of public-key?

- Why do certificate names have to be unique across all keys?

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

- All references to RFCs and I-Ds in description clauses must resolve
  to regular citations somewhere and references in the references
  section.

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

- I am a bit concerned about the two list names 'trusted-certificates'
  and 'trusted certificate' which mean very different things and can
  be potentially confused. (The same for 'trusted-host-keys' and
  'trusted-host-key'.) [No, I do not have a good naming proposal that
  I like, perhaps some brainstorming helps.]

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

- 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

- Why is the certificate (data) leaf in trusted-certificate not
  mandatory? Does it make sense to have list elements where there
  is only a name?

- I am wondering whether it is really a good idea to handle both X509
  keys and certificates as well as some SSH host keys in this document.
  Perhaps it is better to really split things. Also think about devices
  that only do SSH or only to TLS.

- I am not sure I fully understood the call home statement in the
  description of trusted-host-key. This probably needs more or better
  explanation.

- Are SSH implementation encoding keys in ASN.1/DER? I doubt this very
  much. Perhaps this SSH stuff should be moved to a separate I-D since
  I believe this needs more work.

- You cite RFC 6020 (YANG 1) but you use actions which were only added
  in YANG 1.1. I think you should only cite YANG 1.1 (RFC 7950).
 
- The prefix is 'ks' and not 'kc' as stated in the IANA considerations
  section.

- Security considerations talk about 'RPC operations' but the data
  model actually uses actions. Perhaps simply talk about 'operations'.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jul 2017 21:06:59 +0000

Hi Juergen,

Thanks for your review.  Below are my responses to your comments.

PS: why is [email-masked] in the CC?

Kent

--

<KENT> Fixed.

<KENT> Done.

<KENT> reworded.

<KENT> fixed (per Martin's comment earlier)

<KENT> previously fixed and case-lowered.

<KENT> fixed.

- the module seems to use actions but the surrounding text talks about rpcs

<KENT> fixed.

<KENT> no it doesn't (anymore). fixed.

<KENT> fixed.

<KENT> Just did, found no issues.

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

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

- Is it helpful that some examples use XML / NETCONF while
  others use JSON / RESTCONF or is this possibly confusing?
  If you include JSON examples, do you not need to reference
  RFC 7951?

<KENT> I thought there was a criticism a while back that
drafts should show balance in their examples?  In the 
meanwhile, I reworded the sentence to look more like the
other two examples and, in doing so, removed the "JSON
encoding" string altogether.

- s/(c) 2014/(c) 2017/

<KENT> fixed, in all my drafts.

<KENT> fixed.

<KENT> I don't understand, what do you mean?

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

<KENT> yes, but your comment before was valid.  I don't see why
this makes a stronger case though...

<KENT> Fixed.

<KENT> agreed. Fixed.

<KENT> Fixed.

<KENT> comment removed per Martin's review.

<KENT> added.

<KENT> added.

<KENT> because otherwise leafrefs might be ambiguous, right?

<KENT> I'm confused, certificates are signed structures already...

<KENT> Fixed.

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

<KENT> okay, let's keep this one open.

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

<KENT> "set" doesn't sound too bad - dunno.  Regarding moving
"data", see the tail-end of the email I sent on July 11.

<KENT> I was supposed to be mandatory.  Fixed.

<KENT> I believe that it is correct for the keystore to
contain all these things, and I think it's most readable
for them all to be defined in this document.  What do
others think?

<KENT> it was dumb, I removed the whole paragraph.

<KENT> Good point.  Just now realizing that ietf-system's
'authorized-key' has a workable definition.  I just switched
to using it.

<KENT> Fixed.

<KENT> holdover from when draft was called "keychain".  Fixed.

<KENT> Fixed.  (Benoit should update his template as well)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Jul 2017 18:59:42 +0200

> PS: why is [email-masked] in the CC?

I used the datatracker form and it does what it does.
 
> 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  -->

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

> <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.
 
> to define every algorithm (not just public-key algs), which

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.

> this makes a stronger case though...

Well, the notion of what is strong changes every N years.

> <KENT> because otherwise leafrefs might be ambiguous, right?

OK. Perhaps explain this detail so it is obvious to everybody.

> <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.
 
> but by supporting this module, the server must support all of

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?
 
> 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?
 
> "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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 20 Jul 2017 19:06:08 +0200

We actually asked Datatracker admin to remove [email-masked] 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 <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Yangdoctors last call review of
> > <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?
> 
this?
> > <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
> 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).
> 
have.
> > <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.
> 
> > <KENT> yes, but your comment before was valid.  I don't see why this
> > makes a stronger case though...
> 
> > 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?
> 
> > <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...
> 
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?
> > <KENT> "set" doesn't sound too bad - dunno.  Regarding moving "data",
> > see the tail-end of the email I sent on July 11.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Jul 2017 19:18:30 +0200

> clearly crypto algorithm identities must be easily extensible.

I looked a bit more and you define

  identity key-algorithm {
    description
      "Base identity from which all key-algorithms are derived.";
  }

plus a bunch of concrete algorithms. draft-ietf-rtgwg-yang-key-chain-24
defines

     identity crypto-algorithm {
       description
         "Base identity of cryptographic algorithm options.";
     }

and then a bunch of concrete algorithms (hashes and symmetric ones).
They also do not expect IANA to maintain things. I would love if
security area people would help us with getting this right, well
perhaps they jump in during secdir review.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Jul 2017 22:37:50 +0000

Hi Juergen,

> perhaps they jump in during secdir review.

FWIW, the two sets of algorithm identities are disjoint.  The ones in
the keystore draft are all public-key algorithms.  As for the key-chain
draft, all but one of the identities are hmac algorithms, with the last
one being for a key derivation function.

It would be best to address this in the WG, for visibility.  I think
that it's possible to request an early secdir review, or maybe we can 
ask about just this concern.  This is a chair-action. 

Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 02:12:33 +0000

Hi Juergen,

> I used the datatracker form and it does what it does.

From other responses, it seems that [email-masked] is not meant to be in
the CC, so I removed the alias from the CC on this message.  I wish I 
had done the same on my other response to you sent earlier.  Oh well.

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

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

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

> clearly crypto algorithm identities must be easily extensible.

In another thread, we concluded that we might want to ask SecDir.

> Well, the notion of what is strong changes every N years.

;)

> OK. Perhaps explain this detail so it is obvious to everybody.

Done.

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

> keystore going to interfer with this? Or should it better be silent
 
Okay, I see your point.  We want the keystore to support as many 
algorithms as possible; this is why we're using identities.  The
keystore is like an application- and (somewhat) protocol-independent
database, anything can be stored in it, but apps (higher-level 
modules) referring to it (via configuration) need to ensure that 
the reference is valid for its use.  The keystore action itself 
may not fail, but the app referring to a value there may have 
issues.  I'm not yet sure what to do here.

> what is trusting a listed certificate and why?
 
Regarding the word "trusted", maybe it's overstating things, but I
think it's accurate.  Regarding "concrete context", I think what
the "fix" for your concern is that clients SHOULD choose meaningful
names for their certificates, such as I do in the keystore example.

> Aha. Not sure this resolves this (or I looked at the wrong message).

Sorry, my email was addressed to Martin (CC list) with the subject
"Re: [Netconf] comments on draft-ietf-netconf-keystore-02".  Here:
https://mailarchive.ietf.org/arch/msg/netconf/KXpig_5AsisqhmwoayS3UIVbjEo

> /js

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 07:21:27 +0200

> ask about just this concern.  This is a chair-action. 

I all for secdir review for this document. That said, perhaps it is OK
to have the identities as they are and to define a proper IANA
registry later. The price might be that some identities are defined
twice but that would likely not be a significant implementation cost.
Its a trade off between (i) moving fast and maybe requiring to adapt
later or (ii) trying to work everything out while doing the first
version and hence being slow.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 09:39:23 +0200

> 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).
 
> the client.  These are the host keys that OpenSSL often puts into the 

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

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

> 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

---

From: Per Hedeland <[email-masked]>
Date: Fri, 28 Jul 2017 12:09:05 +0200

On 2017-07-28 04:12, Kent Watsen wrote:
> is itself a valid base64 string.

Nice idea, but actually it isn't - i.e. there does not exist an octet
sequence that will encode to that string, and a decoder "should" reject
it as invalid. But maybe that is a feature?:-)

(By definition, there can be at most 2 trailing '=' characters in the
encoding. You can have "base64encode" or e.g. "base64encodedA==", but I
guess neither is as appealing...)

--Per

---

From: Per Hedeland <[email-masked]>
Date: Fri, 28 Jul 2017 12:15:20 +0200

> guess neither is as appealing...)

"base64encoding==" is also OK...

--Per

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 12:36:47 +0200

> "base64encoding==" is also OK...

base64encodedvalue== also seems to be OK

/js

---

From: Per Hedeland <[email-masked]>
Date: Fri, 28 Jul 2017 13:05:57 +0200

> base64encodedvalue== also seems to be OK

Yes, as far as I can see, any string that

a) is restricted to the alphabet
b) is a multiple of 4 characters long
c) has 0, 1, or 2 '=' characters at the end (only)

is valid. But it seemed there was a length restriction in the particular
usage considered here. "base64==" is also OK.:-)

--Per

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 11:30:41 +0000

> (By definition, there can be at most 2 trailing '=' characters in the encoding.

You know, this is what I always thought too, but the tool I was using told me the input was finally ok after adding the 3rd '=' on a fluke.  Maybe the tool is broken, i'll double-check...

K.

---

From: Per Hedeland <[email-masked]>
Date: Fri, 28 Jul 2017 16:26:51 +0200

On 2017-07-28 13:30, Kent Watsen wrote:
> You know, this is what I always thought too, but the tool I was using told me the input was finally ok after adding the 3rd '=' on a fluke.

'mimencode' from the ancient 'metamail' package does that - i.e. it
complains (with a "warning") when the length isn't a multiple of 4, but
silently discards the partial result of decoding a 4-character chunk
with 3 trailing '=' pad-characters, as in "d===".

--Per

> Maybe the tool is broken, i'll double-check...
> 
> K. 
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 15:01:26 +0000

Hi Juergen,

> sounds like an interesting option since this should allow tools
> to validate the instance documents (and this is what I am really
> looking for).

Great, and this thread forked already, so let's continue it there.

> account's known-hosts file? In this case, the keystore may be the
 
/keystore/trusted-host-keys/trusted-host-key is in fact like the
known-hosts file.  That is, these are the host-keys that a client has
"pinned" or "trusted".  The ietf-ssh-client has a leafref to one of
these entries.  We could rename "trusted-host-key[s]" to 
"pinned-host-key[s]" if that helps. Ditto for trusted-certificate[s])

By contrast, /keystore/keys/key/name is referenced by ietf-ssh-server
to identify the host-key(s) the SSH server presents to SSH clients.
This is analogous to /etc/ssh/ssh_host_rsa_key.pub and friends.  This
node isn't called e.g. /keystore/keys/key/ssh-host-key because, AFAICT,
the system should be able to generate its host-key from the private-key
itself.  Thus, referencing the name is equivalent.  If there were a
/keystore/keys/key/ssh-host-key node, it would be a gratuitous config
false value that somehow encoded the host-key in a more SSH friendly
format.  But, it may have a subtler value in that, I think that your
confusion may be because it was NOT there and so, in its absence, 
you may have thought that the "trusted-host-keys" must serve that 
function.  Thoughts?

BTW, "host key" has a specific meaning, defined in RFC4251#4.1, not to
be confused with authorized keys.

> Data Model for Managing X.509 Keys and Certificates' would be a clear

From a refactoring perspective, we could have a base module and then
two augmenting modules, one for SSH and the other for X.509.  I would
think to define all three modules in the same draft, but that wouldn't
help your draft-name issue.  We could put each module into own draft
(e.g. +2 drafts), but is it worth it for renaming sake?  Maybe an even
longer title?  "YANG Data Model for Managing Asymmetric Private Keys,
X.509 Certificates, and SSH Host Keys'?  Naming aside, what do you 
think about the module-factoring idea?

> needed but we do this later.

Maybe, and really I wonder who is in a better position to make the
call.  Sure, SecDir can confirm that there are common algorithms
used in cryptography, but they may not necessarily have a crystal
ball to know how many YANG modules will be coming in the near 
future for which it matters.  Is the NETCONF/NETMOD WGs more
able to make this call?  I'm personally unaware of any other 
work-in-progress having a need for these algorithm identities
such as are defined here, nor do I have a crystal ball for 
predicting the future.

> So why pkcs7, is this what implementations use? The certificates

Why pkcs7 is because each certificate may have an associated chain
of certificates leading to a trust-anchor CA certificate.  For instance,
a vendor might have a CA called "foo-root" that signs an intermediate
CA called "foo-intermediate" that signs the "foo-entity" certificates.
So, a given foo-entity certificate (a single X.509 structure) is
commonly presented along with its chain of CA certs (more X.509 
structures), in this case, the "foo-intermediate" and "foo-root" CA
certs.  The pkcs7 structure is commonly used for this purpose in the
PKI world.  Yes, it could be just a TAR file having a flat list of
certs, but then we'd have to define that structure, whereas its 
already defined in pkcs7.

> I find in /etc/ssl/certs on my Debian system seem to be in PEM format.

PEM and DER are interchangeable formats.  PEM is essentially the base64
encoding of the DER surrounded by the "===== BEGIN/END CERTIFICATE
=====" header/footer.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 17:40:08 +0200

> be confused with authorized keys.

I do not really follow you. I think I do understand what a host key
(pair) is and that it is different from a users key (pair). Yes, I did
not understand from reading the ID that the private SSH host key is to
be found in /keystore/keys/key/name (likely because of all the
certificate stuff around it that I have never seen used with SSH host
keys).

I guess I am not a big fan of bundling the way X.509 keys and certs
work together with how SSH keys work (because I am not used to this
and the systems I tend to use do not do this either). Anyway, if this
is the direction to go, I think this needs explanatory text somewhere.
 
> think about the module-factoring idea?

Perhaps it is simpler to have one data model to manage X.509 keys and
certs and another data model to manage SSH keys. I do not know how
much commonality there is. At the end, I also do not mind if
everything is lumped together as long as it is clear how to implement
things and key formats etc match with what implementations typically
do.
 
> such as are defined here, nor do I have a crystal ball for 

Crypto algorithms have changed in the past and they will change in the
future. So we will need flexibility here, sooner or later. Getting this
right requires to have the right people involved (i.e., not me).
 
> encoding of the DER surrounded by the "===== BEGIN/END CERTIFICATE

DER encoded certificate or pkcs7? I thought PEM is just a base64
encoded version of the DER encoded certificate, no pkcs7 involved.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 17:00:06 +0000

> (pair) is and that it is different from a users key (pair).

Fine, but this is SSH architecture thing, not something specific to
the draft - right?

> Yes, I did

Okay, then do you like having a /keystore/keys/key/ssh-host-key node?

> is the direction to go, I think this needs explanatory text somewhere.

So then perhaps factoring out the x.509 and ssh stuff out into augmenting
modules? 

> things and key formats etc match with what implementations typically

Two modules, something like ietf-ssh-keystore and ietf-x509-keystore?
Of course, there would overlap between them (e.g., both modules would
have the /keys/key hierarchy, the ietf-ssh-client/server modules might
need to import both keystores, since SSH can use X.509 certs too (per
RFC6187).  I don't know, this doesn't seem right.  For instance, what
is a server to do if it generates a private key that has not yet been
associated with an X.509 cert or SSH host key, is the private key to
appear in both keystores?

> Crypto algorithms have changed in the past and they will change
> in the future. So, we will need flexibility here, sooner or later.
> Getting this right requires to have the right people involved 
> (i.e., not me).

Okay, so maybe we're only in the position of saying that such a
thing is highly desirable, but we'd be dependent on security 
experts to get it right, and SecDir involvement could help
kickoff that effort...

> encoded version of the DER encoded certificate, no pkcs7 involved.

Both PKCS7 and X.509 or ASN.1-encoded structures, and all ASN.1 structures
can be encoded using PEM, DER, or even BER.   Your debian system's "certs"
directory undoubtedly only contains root certs, hence there is no cert-chain
to staple to them, and hence a single X.509 structure (either PEM or a DER)
is perfect.  As soon as you step into needing more than one cert, then
either PKCS7 or PKCS12 (both of which could be PEM or DER encoded), or a
very special multi-part PEM (one that contains more than one of the "====="
BEGIN/END blocks) could be used.  BTW, all this was discussed a while back
related to https://github.com/netconf-wg/keystore/issues/1.  What's written
in the GitHub issue tracker should be ignored, search instead the list-archive
on issue #1... 

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 19:09:30 +0200

> Fine, but this is SSH architecture thing, not something specific to

???
 
> Okay, then do you like having a /keystore/keys/key/ssh-host-key node?

I guess what I am looking for is a more radical split between X.509
stuff and SSH key stuff, the most radical split would be a module for
X.509 keys and certs and another module for SSH host keys. Or
alternatively, if there is really a strong reason to have all these
different keys in one list, then define the list such that
augmentations add X.509 stuff and SSH key stuff. I am not a fan of
lists where the usage of leafs for different purposes is not clear.

> So then perhaps factoring out the x.509 and ssh stuff out into augmenting

I am not sure how much is left, other than a list with a key name leaf
and whether it is worth to have this common structure (and whether any
uniqueness constraints resulting from that are a benefit or not).

> appear in both keystores?

Is this how systems work? My command line tools either create X.509
keys or SSH keys.

> in the GitHub issue tracker should be ignored, search instead the list-archive

What matters is that the I-D is clear and captures the important
reasons etc. You can't expect implementors to read github issues
or mailing list archives. Sorry for my ignorance.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 31 Jul 2017 18:30:21 +0000

>> Fine, but this is SSH architecture thing, not something specific to
 
I'm unsure about what you want here.  

A host-key is how the server authenticates itself to clients.  It is the thing that, when an SSH client first connects to a server and is presented the fingerprint, is placed into the client's ~/.ssh/known-hosts file.

Separately, user accounts can be configured to authorize a client based on a public-key (as opposed to a password).  This public-key is the thing that is commonly placed in ~/.ssh/authorized_keys, and is configurable via ietf-system/system/user/authorized-key/key-data.

> lists where the usage of leafs for different purposes is not clear.

I just filed https://github.com/netconf-wg/keystore/issues/7 to track
this.  My current thought is to break the module up into a main module
and two augmenting modules.  This isn't quite what you want, but I'm
hoping that the net-result is more readable, since nodes will be
prefixed.  If nothing else, it can be a first step to a larger 
break-up...

> uniqueness constraints resulting from that are a benefit or not).

Right, the remaining module would be pretty skinny - just a list of keys
and an action to generate a new private key.  I think the primary value
is that everything is in one location, but maybe that doesn't matter here,
since there is no human-in-the-loop, such as there is for desktop-oriented
keystore mechanisms. Generally, the keystore is password-protected, but
in this case there is no password, other than whatever the client used
when connecting to the server.

> Is this how systems work? My command line tools either create X.509

No, your system most likely does not use a keystore mechanism.  For
instance, OpenSSL's `ssh-keygen` utility just writes to a local file.
We're doing something a little different here, which is a cause for
careful review (thanks again).  Taking a step back, one of the drivers
for this keystore mechanism is to centralize the /trusted-host-keys
and /trusted-certificates, as these lists are referenced from many
locations.  Less important to centralize are the private keys, as
the keys (always?) have a single use.  The only reason for centralizing
the private keys is to give keys created via the generate-private-key
action a place to be listed before they are used for some purpose...

> or mailing list archives. Sorry for my ignorance.

Okay, I rewrote the description. Actually. I just removed the word
"unsigned", as the rest seemed okay:

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

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Jul 2017 21:06:40 +0200

> Separately, user accounts can be configured to authorize a client based on a public-key (as opposed to a password).  This public-key is the thing that is commonly placed in ~/.ssh/authorized_keys,…

Yes, the host-key resides on the server, the public part of the host
key may be stored on a client in a known-hosts file so that client can
check whether it talks to the right server. So far so good.

It seems /keystore/trusted-host-keys/trusted-host-key represents
/etc/ssh/ssh_known_hosts (i.e. a _global_ known hosts list) and there
is no way to learn the public known host key from a server via the
YANG module. Can I request creation of a hew host key? There is
generate-private-key but that seems to be more tied to X.509 stuff.

Note that this does not model ~/.ssh/known-hosts since the list is not
on a per user account base. It would actually be the equivalence of a
global /etc/ssh/ssh_known_hosts file.

> action a place to be listed before they are used for some purpose...

The question is whether there is value to centralize beyond the
differnet key systems. Is there really added value to try to treat SSH
keys and X.509 in the same list infrastructure or are they at the end
just different things? What about other keys, i.e., for signing DNS
zones or RPKI keys? Is it useful to try to put all of these keys that
serve different purposes into a common structure? The open source
people maintaining software packages seem to keep things separate. Is
Junos having such a centralized asymmetric keystore? How about IOS XR?
Others? If not, why would a standard do this?

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 31 Jul 2017 20:18:46 +0000

Removing [email-masked] from CC.

Following up on this, I just realized that the SSH and TLS client-server drafts are also defining a number of algorithm identities, and these are more like the ones found in ietf-key-chain.  Now it seems that factoring these identities to another module is more prudent than ever.

Files https://github.com/netconf-wg/keystore/issues/8 to track this item.

K.

/js