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

[Kent Watsen <[e-mail]>]

Hi Juergen,

 
>> PS: why is [e-mail] in the CC?
>
> I used the datatracker form and it does what it does.

From other responses, it seems that [e-mail] 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.

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


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


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


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


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

Done.


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


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


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


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

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.