Re: [netmod] x509c2n:cert-to-name problem

[Kent Watsen]

>> First, let me demote (2) from a SHOULD to a MAY, since there is a
>> workaround.
>> 
>> The thinking is that it may be common for deployments to use the same
>> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
>> hence there is no need to specify a "fingerprint" in order to lookup
>> what strategy to use.  For these cases, it would be better to not
>> specify a fingerprint at all.  If this remains "mandatory true", the
>> best fallback would be to specify the fingerprint for the *root* CA
>> certs spanning the end-entity certs connecting to that endpoint.
> 
> Are we still talking about the usage of cert-to-name in
> ietf-netconf-server?  

and ietf-restconf-server, yes.



> If so we have (as one example):
> 
>  +--rw netconf-server
> +--rw listen! {ssh-listen or tls-listen}?
>...
>+--rw endpoint* [name]
>   ...
>   +--rw (transport)
>  ...
>  +--:(tls) {tls-listen}?
> +--rw tls
>...
>+--rw netconf-server-parameters
>   +--rw client-identification
>  +--rw cert-maps
> +--rw cert-to-name* [id]
>+--rw id   uint32
>+--rw fingerprint  x509c2n:tls-fingerprint
>+--rw map-type identityref
>+--rw name string
> 
> [we can discuss if this is the best structure, but that's another
> thread]
> 
> What would a "cert-to-name" entry mean if the fingerprint isn't present?


Your snippet excludes "tis-server-perameters".   Here is a more complete view:

  +--rw restconf-server
 +--rw listen! {http-listen or https-listen}?
+--rw endpoint* [name]
   +--rw name   string
   +--rw (transport)
  +--:(http)
  |  +--rw http
  | ...
  +--:(https)
 +--rw https
+--rw tcp-server-parameters
|  ...
+--rw tls-server-parameters
|  +--rw server-identity
|  |  ...
|  +--rw client-authentication!
|  |  +--rw (required-or-optional)
|  |  |  ...
|  |  +--rw (local-or-external)
|  | +--:(local)
|  | |  +--rw ca-certs!  
|  | |  |  ...
|  | |  +--rw client-certs!
|  | | ...
|  | +--:(external)
|  |...
|  +--rw hello-params
|  |  ...
+--rw http-server-parameters
|  +--rw server-name? string
|  +--rw protocol-versions
|  |  +--rw protocol-version*   enumeration
|  +--rw client-authentication!
| ...
+--rw restconf-server-parameters
   +--rw client-identification
  +--rw cert-maps
 +--rw cert-to-name* [id]
+--rw id uint32
+--rw fingerprint
|   x509c2n:tls-fingerprint
+--rw map-type   identityref
+--rw name   string


The "tls-server-parameters" container defines the certificates used to 
authenticate the client's cert.   In many deployments, regardless how the 
client cert is authenticated, the "client-identification" section only needs to 
explain extract the "name" from the cert, a fingerprint isn't needed to 
identify either the client's end-entity or some intermediate cert.




> 
>> New issue.  Why isn't "list cert-to-name" order-by user given:
>> 
>>  "The id specifies the order in which the entries in the
>>   cert-to-name list are searched.  Entries with lower
>>   numbers are searched first.";
>> 
>> I suspect that this is for SNMP compatibility, but then your earlier
>> response on this thread said regarding "mandatory true" and empty
>> fingerprint values suggested that more appropriate YANG-isms should be
>> used, in general.  "ordered-by user" vs "ordered by id" seems like
>> such a case.
> 
> Yes I agree.  I don't recall but I also suspect the motivation was
> simple mapping to the MIB.  (mapping a zero-length string to/from an
> optional leaf is straightforward).

Is it too late to fix?   No reason to hold onto SNMP compatibility, given SNMP 
is now deprecated...


Kent // contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> Hi Martin,
> 
> > I have now filed an errata for this issue.
> 
> Ack.
> 
> > However, I remember that we had a discussion on whether we should
> > accept erratas on YANG modules or not.  The YANG module exist in
> > various places outside of the RFC, such as the IANA site, and it won't
> > be corrected there.
> 
> Yes, two thoughts:
>- this erratum could marked as document update required.
>- we may want to publish a -biz soon
> 
> 
> 
> >> In that case, there might be two issues:
> >> 
> >>1) the description statement excluding CA certs (mentioned before)
> >>2) `mandatory true` should be `mandatory false` ?
> > 
> > I don't understand 2), can you elaborate?
> 
> 
> First, let me demote (2) from a SHOULD to a MAY, since there is a
> workaround.
> 
> The thinking is that it may be common for deployments to use the same
> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
> hence there is no need to specify a "fingerprint" in order to lookup
> what strategy to use.  For these cases, it would be better to not
> specify a fingerprint at all.  If this remains "mandatory true", the
> best fallback would be to specify the fingerprint for the *root* CA
> certs spanning the end-entity certs connecting to that endpoint.

Are we still talking about the usage of cert-to-name in
ietf-netconf-server?  If so we have (as one example):

  +--rw netconf-server
 +--rw listen! {ssh-listen or tls-listen}?
...
+--rw endpoint* [name]
   ...
   +--rw (transport)
  ...
  +--:(tls) {tls-listen}?
 +--rw tls
...
+--rw netconf-server-parameters
   +--rw client-identification
  +--rw cert-maps
 +--rw cert-to-name* [id]
+--rw id   uint32
+--rw fingerprint  x509c2n:tls-fingerprint
+--rw map-type identityref
+--rw name string

[we can discuss if this is the best structure, but that's another
thread]

What would a "cert-to-name" entry mean if the fingerprint isn't present?

> New issue.  Why isn't "list cert-to-name" order-by user as opposed to:
> 
>   "The id specifies the order in which the entries in the
>cert-to-name list are searched.  Entries with lower
>numbers are searched first.";
> 
> I suspect that this is for SNMP compatibility, but then your earlier
> response on this thread said regarding "mandatory true" and empty
> fingerprint values suggested that more appropriate YANG-isms should be
> used, in general.  "ordered-by user" vs "ordered by id" seems like
> such a case.

Yes I agree.  I don't recall but I also suspect the motivation was
simple mapping to the MIB.  (mapping a zero-length string to/from an
optional leaf is straightforward).


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Randy Presuhn]

Hi -


On Tue, Oct 29, 2019 at 10:53:49AM +0100, Martin Bjorklund wrote:

Randy Presuhn  wrote:

Hi -

On 10/28/2019 2:22 AM, Martin Bjorklund wrote:


No, in many SMIv2 objects, a zero-length value is used for optional
nodes (due to the way the protocol (SNMP) works).

This comes as a complete surprise to me.  References?

I don't have any references at hand, so let me re-phrase:

   No, in many SMIv2 objects, a zero-length value is used for optional
   nodes.

(where "optional" means optional to set, not optional to implement)


No, for set operations DEFVAL in SMIv2 governs "missing" objects.
(RFC 1442 7.9 or any of its successors.)

The decision to define sentinel values is entirely up to the MIB 
designer.  Zero-length
string is a possible choice only for stuff built with OCTET STRING as 
the underlying

type.  But it's still a value, and in no way makes something "optional."

*Any* object/instance might appear to be "missing" for retrieval due to 
the operation of
VACM or its proprietary predecessors.  It's been that way since, like, 
forever.

See for example RFC 1157 section 4.1.2 to get an idea how ancient this is.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Schönwälder , Jürgen]

On Tue, Oct 29, 2019 at 03:35:19PM +, Kent Watsen wrote:
> > However, I remember that we had a discussion on whether we should
> > accept erratas on YANG modules or not.  The YANG module exist in
> > various places outside of the RFC, such as the IANA site, and it won't
> > be corrected there.
> 
> Yes, two thoughts:
>- this erratum could marked as document update required.
>- we may want to publish a -biz soon

I fail to see the argument. Standards-track RFCs typically lead to
some form of code somewhere so errata may always affect
implementations and I do not see why YANG is different just because
definitions are in a formal notation. Here we resolve a contradiction
contained in text of description clauses. If you implement this and
run into this contradiction, you likely check the RFC whether there
is already an errata.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Kent Watsen]

Hi Martin,

> I have now filed an errata for this issue.

Ack.

> However, I remember that we had a discussion on whether we should
> accept erratas on YANG modules or not.  The YANG module exist in
> various places outside of the RFC, such as the IANA site, and it won't
> be corrected there.

Yes, two thoughts:
   - this erratum could marked as document update required.
   - we may want to publish a -biz soon



>> In that case, there might be two issues:
>> 
>>  1) the description statement excluding CA certs (mentioned before)
>>  2) `mandatory true` should be `mandatory false` ?
> 
> I don't understand 2), can you elaborate?


First, let me demote (2) from a SHOULD to a MAY, since there is a workaround.

The thinking is that it may be common for deployments to use the same 
"cert-to-name" strategy everywhere (e.g., IDevID certificates), and hence there 
is no need to specify a "fingerprint" in order to lookup what strategy to use.  
For these cases, it would be better to not specify a fingerprint at all.   If 
this remains "mandatory true", the best fallback would be to specify the 
fingerprint for the *root* CA certs spanning the end-entity certs connecting to 
that endpoint.


New issue.  Why isn't "list cert-to-name" order-by user as opposed to:

  "The id specifies the order in which the entries in the
   cert-to-name list are searched.  Entries with lower
   numbers are searched first.";

I suspect that this is for SNMP compatibility, but then your earlier response 
on this thread said regarding "mandatory true" and empty fingerprint values 
suggested that more appropriate YANG-isms should be used, in general.  
"ordered-by user" vs "ordered by id" seems like such a case.


Kent // contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Default statements and deviate add/replace

[Rob Wilton (rwilton)]

I think that I basically agree with Balazs,  the spec refers to properties 
rather than sub-statements.

I would say, every data node always has these properties (either because they 
are required or because they have a defined default value if the statement is 
not present):
   config, mandatory, type
lists and leaf-lists also always have these properties (because they have 
default values if the statement is not present):
   max-elements, min-elements

So, I think that config, mandatory, type, max-elements, min-elements cannot be 
added or deleted, only replaced, because they always exist.

default, must, unique, units are all optional, and hence may be added, 
replaced, or deleted.

If we reach agreement, then I think that the text could also be clarified in 
YANG Next.

Thanks,
Rob


From: netmod  On Behalf Of Balázs Lengyel
Sent: 24 October 2019 14:45
To: Kent Watsen 
Cc: Edvardas Lasauskas ; Mark Hollmann 
; netmod@ietf.org
Subject: Re: [netmod] Default statements and deviate add/replace

Hello Kent,
As IMO practically all tools are misbehaving I would like a confirmation that 
my interpretation of the differences between deviate add and deviate replace 
are correct.  After that I will start reporting the issues to the tools.
Regards Balazs

From: Kent Watsen mailto:k...@watsen.net>>
Sent: 2019. október 22., kedd 16:37
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: netmod@ietf.org; Mark Hollmann 
mailto:mark.hollm...@ericsson.com>>; Edvardas 
Lasauskas 
mailto:edvardas.lasaus...@ericsson.com>>
Subject: Re: [netmod] Default statements and deviate add/replace

Hi Balazs,

Is this for the NETMOD list, or should bugs be filed against the misbehaving 
tools?

Kent


On Oct 22, 2019, at 6:56 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org>>
 wrote:

Hello,
I tried testing the following statements:

  deviation /nacm:nacm/nacm:enable-nacm {
deviate add {
  config false; } }

  deviation /nacm:nacm/nacm:rule-list {
deviate add {
  min-elements 1; }  }

In nacm both the config and the min-elements are absent, so their default 
meaning is true. I actually tried both add and replace in deviate.
I got rather confusing results whether the add/replace variant of deviate 
should be accepted or rejected because the property already exists or does not 
yet exist.

Pyang 2.0.2 locally:
Config=false   add-NOK  replace-OK
Min-elements=1  add-OK replace-NOK

YANG-Validator  pyang 2.0 & confdc
Config=false   add-OK replace-OK
Min-elements=1  add-OK replace-NOK

YANG-Validator yanglint
Config=false   add-OK replace-OK
Min-elements=1  add-OK replace-OK

IMHO the tools should always check the property, so even if the statement is 
not present the properties config=false and min-elements=0 ARE present. So add 
should be rejected and replace accepted.

Regards Balazs

--
Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd.
Mobile: +36-70-330-7909  email: 
balazs.leng...@ericsson.com

___
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

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Randy Presuhn  wrote:
> Hi -
> 
> On 10/28/2019 2:22 AM, Martin Bjorklund wrote:
> 
> > No, in many SMIv2 objects, a zero-length value is used for optional
> > nodes (due to the way the protocol (SNMP) works).
> 
> This comes as a complete surprise to me.  References?

I don't have any references at hand, so let me re-phrase:

  No, in many SMIv2 objects, a zero-length value is used for optional
  nodes.

(where "optional" means optional to set, not optional to implement)



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Hi,


Kent Watsen  wrote:
> Hi Martin,
> 
> 
> > I'll check with my co-author and get back.
> 
> Thanks.

I have now filed an errata for this issue.

However, I remember that we had a discussion on whether we should
accept erratas on YANG modules or not.  The YANG module exist in
various places outside of the RFC, such as the IANA site, and it won't
be corrected there.

> > No, in many SMIv2 objects, a zero-length value is used for optional
> > nodes (due to the way the protocol (SNMP) works).  In YANG we don't do
> > this, since the protocls (NETCONF etc) can handle non-existing
> > optional leafs.
> 
> In that case, there might be two issues:
> 
>   1) the description statement excluding CA certs (mentioned before)
>   2) `mandatory true` should be `mandatory false` ?

I don't understand 2), can you elaborate?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (5879)

[Ladislav Lhotka]

Ladislav Lhotka  writes:

> On Tue, 2019-10-22 at 17:02 +0200, Martin Bjorklund wrote:
>> Hi,
>> 
>> The problem is that it is not clear that we can use this new
>> definition with the rest of the text in the RFC that uses this term.
>> For example, section 7.1.5 talks about "the imported module's schema
>> tree", and this doesn't really work if the schema tree is not tied to
>> a module.
>
> On the other hand, sec. 9.9 says (and that's how I stumbled upon this):
>
>The "path" substatement (Section 9.9.2) is used to identify the
>referred leaf or leaf-list node in the schema tree.
>
> With the current definition of schema tree, it would mean that the referred 
> leaf
> or leaf-list node must be in the same module, which is of course a nonsense.

The erratum was rejected, but if we keep the definition of "schema tree", then 
the above definition of "path" statement is technically incorrect.

Lada

>
> Lada
>
>> 
>> Also the proposed definition is recursive since it is defined in
>> terms of "schema node", and a "schema node" is already defined as "a
>> node in the schema tree".
>> 
>> So it probably makes sense to look at this definition (and the text
>> and other definitions) if we do a document update, but as it is
>> currently written I think it should be rejected.
>> 
>> 
>> /martin
>> 
>> 
>> 
>> RFC Errata System  wrote:
>> > The following errata report has been submitted for RFC7950,
>> > "The YANG 1.1 Data Modeling Language".
>> > 
>> > --
>> > You may review the report below and at:
>> > https://www.rfc-editor.org/errata/eid5879
>> > 
>> > --
>> > Type: Technical
>> > Reported by: Ladislav Lhotka 
>> > 
>> > Section: 3
>> > 
>> > Original Text
>> > -
>> > o  schema tree: The definition hierarchy specified within a module.
>> > 
>> > 
>> > Corrected Text
>> > --
>> > o  schema tree: The hierarchy of schema nodes defined in the set of all
>> modules 
>> >implemented by a server, as specified in the YANG library data 
>> > [RFC7895].
>> > 
>> > 
>> > 
>> > Notes
>> > -
>> > The original definition of the term has two problems:
>> > 
>> > 1. Schema tree is not limited to a single module. Some YANG constructs, 
>> > such
>> as augment and leafref type, may refer to a schema node that is defined in
>> another module.
>> > 
>> > 2. Apart from schema nodes, YANG modules contain definitions that do not
>> contribute to the schema tree: groupings, typedefs, identities etc.
>> > 
>> > Instructions:
>> > -
>> > This erratum is currently posted as "Reported". If necessary, please
>> > use "Reply All" to discuss whether it should be verified or
>> > rejected. When a decision is reached, the verifying party  
>> > can log in to change the status and edit the report, if necessary. 
>> > 
>> > --
>> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>> > --
>> > Title   : The YANG 1.1 Data Modeling Language
>> > Publication Date: August 2016
>> > Author(s)   : M. Bjorklund, Ed.
>> > Category: PROPOSED STANDARD
>> > Source  : Network Modeling
>> > Area: Operations and Management
>> > Stream  : IETF
>> > Verifying Party : IESG
>> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod