Re: [netconf] WG LC for three drafts or two of them

Kent Watsen <kent+ietf@watsen.net> Thu, 18 June 2020 13:41 UTC

Return-Path: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505D43A0F52 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye-Y__D4VpU5 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:41:35 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5253A0F51 for <netconf@ietf.org>; Thu, 18 Jun 2020 06:41:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592487694; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=SyJn9zO37Ob98mDV+5LrMGDT2R4N+uMNd4Cig01LU+c=; b=BEl5TLoQxXK3daGsPRH2DH4X6SJD00vxtBqB5CQ0qZFVI7oAXeozW+tSQdEVteuX rmTNXjzEQgWptZ98hKEjOA3dyfPqLe0IXSK82delakM2LHL/qaZsZdZ0pRWKIovBzY3 b+1XDLeAOk4XkbysrEosY7E+OQlqli6inSy/UiAc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C11C88A-7A1E-4A6C-AEF6-1DCDE8A053E3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 18 Jun 2020 13:41:33 +0000
In-Reply-To: <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: tom petch <ietfc@btconnect.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.18-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RK8iBi2fGmmwsYtZQE7pfPPw6cA>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 13:41:38 -0000

Hi Tom,

Thank you!

This text is a superset of the text sent yesterday, so I’ll focus on consuming this content instead.  Reading it, two thoughts arise:

1) Much of this text should surround tree diagram snippets.   As Juergen implied yesterday, a wall of tree diagram artwork alone doesn’t make for a great “overview”.

2) It is too bad that RFC 8340 doesn’t define a way to represent identities, features, or typedefs (note that both identities and features can form trees too).  I’ll likely devise my own format for the “overview” section, around which some of your text would go.

PS: I have no IPR on this work either, it all goes to the IETF.

Kent // contributor


> On Jun 18, 2020, at 7:43 AM, tom petch <ietfc@btconnect.com> wrote:
> 
> I thought some more and here is the text that I would have liked to have read in crypto-types before diving into the YANG.  It is a tribute to the painstaking work of Kent that almost all I have done is cut and paste, removing duplicate phrases.  The IPR is all Kent's.
> ====================================================
> 
> X This module contains YANG identity, typedef and grouping for use by YANG modules involved with security.
> 
> X.1 This module contains YANG identity for private keys, public keys and symmetric keys.
> 
> From the base "private-key-format" there are derived identity for 
> - rsa-private-key-format for use with RSA as defined in RFC 3447
> - ec-private-key-format for use with Elliptic Curve as defined in RFC5915 [**format]
> - one-asymmetric-key-format as defined for use with CMS (Cryptographic Message Syntax) as defined RFC 5958, encoded using ASN.1 DER (Distinguished Encoding Rules) as specified in ITU-T X.690.
> - encrypted-one-asymmetric-key-format as defined for CMS use in RFC 5958, encoded using ASN.1 DER.
> 
> From the base "public-key-format" there are derived identity for 
> - ssh-public-key-format as defined for use with SSH as specified by RFC 4253, Section 6.6.
> - subject-public-key-info-format as defined for use with X.509 in RFC 5280, encoded using ASN.1 DER.
> 
> From the base "symmetric-key-format" there are derived identity for 
> - octet-string-key-format encoded as a raw octet string.
> - one-symmetric-key-format as defined for use with CMS in RFC 6031 and
>          encoded using ASN.1 DER
> - encrypted-one-symmetric-key-format as defined for use with CMS 
>          in RFC 6031 and encoded using ASN.1 DER
> 
> 
> X.2 This module contains typedef for X.509 certificate, CMS structures and trust anchors.
> 
> 'csr' is derived from 'binary' and is for use with a CertificationRequest          as specified in PKCS#10, RFC 2986, encoded in DER.  No other types are derived from this base.
> 
> 'x509' (without the period) is derived from 'binary' and for use for a X.509 Certificate (RFC5280), encoded in DER.  From 'x509' are derived 
> - trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)
> - end-entity-cert-x509 a X.509 certificate for end entities, i.e. a certificate that is neither self-signed nor having the 'cA' bit in the basic constraints extension set to true (RFC 5280 Section 4.2.10)
> 
> 'crl' is derived from 'binary' and is for use for a X.509 'CertificateList' structure, as specified in RFC 5280, encoded in DER.  No other types are derived from this base.
> 
> 'cms' is derived from 'binary' and for use for a CMS ContentInfo structure encoded in DER (RFC5652 Section 2).  From 'cms' are derived 
> - data-content-cms 
>           a CMS structure whose top-most content type MUST be
>           the 'data content type' (RFC 5652 Section 4)
> - signed-data-cms - a structure whose top-most content type MUST be the
>          'signed-data content type' (Section 5 RFC 5652)
> - enveloped-data-cms  
>         "A CMS structure whose top-most content type MUST be the
>          'enveloped-data content type' (Section 6 RFC 5652)
> - digested-data-cms {
>         "A CMS structure whose top-most content type MUST be the
>          'digested-data content type' (Section 7 RFC 5652)
> - encrypted-data-cms {
>         "A CMS structure whose top-most content type MUST be the
>          'encrypted-data content type' (Section 8 RFC 5652)
> - authenticated-data-cms {
>          "A CMS structure whose top-most content type MUST be the
>          'authenticated-data content type' (Section 9 RFC 5652)
> 
> From 'signed-data-cms' are derived
> - trust-anchor-cert-cms is a CMS SignedData structure that contains a single chain of X.509 (RFC 5280) certificates which authenticate the certificate presented by a client or end-entity.  The chain must include a root certificate; this may be the only certificate present when that is also the certificate for the client or end-entity. Objects relating to the revocation status of the certificates MAY be present.  This uses the degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 certificates and revocation objects.
> 
> -  end-entity-cert-cms is a CMS SignedData structure that contains the end entity certificate itself and MAY contain any number of intermediate certificates leading up to a trust anchor certificate which MAY be included as well.  This differs from 'trust-anchor-cert-cms' in that the root certificate and intermediate certificates, if any, are optional.  Other certificates MUST NOT be present but objects relating to the revocation status of the certificates MAY be present.  This uses the degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 certificates and revocation objects.
> 
> 
> X.3 This module contains YANG grouping related to keys and certificates. The groupings for keys all contain NACM (Network Configuration Access Control Model), RFC 8341, default deny for the key leaf itself.  The groupings for end entity certificates and for trust anchors contain a YANG notification that the certificate is, or is about to, expire and also contain a NACM default deny. 
> 
> symmetric-key-grouping contains a leaf whose type is derived from 'symmetric-key-format'.  The format of the key is a YANG 'choice' of 'binary' or 'empty'; the latter is for use with a hidden key.
> 
> public-key-grouping contains a leaf which is the public key in 'binary' and whose format is derived from the type 'public-key-format'.
> 
> asymmetric-key-pair-grouping uses the public-key-grouping and contains a leaf  for the private key format whose type is derived from the type private-key-format and for the key itself whose type is binary or empty; the latter is for use with a hidden key.       
> 
> trust-anchor-cert-grouping contains a leaf of type 'trust-anchor-cert-cms'
> 
> trust-anchor-certs-grouping contains a leaf list of type 'trust-anchor-cert-cms'
> 
> end-entity-cert-grouping contains leaf of type 'end-entity-cert-cms'
> 
> end-entity-certs-grouping contains a leaf list of type 'end-entity-cert-cms'
> 
> generate-csr-grouping contains a YANG action to generate a signed CertificationRequest); the associated node MUST have a 'public-key-format' value of 'subject-public-key-info-format'. 'input' to the action are the 'subject' and 'atributes' fields of  CertificationRequestInfo as specified in RFC 2986, Section 4.1, encoded in DER. 'output' of the action is a leaf of type 'csr' as described above.
> 
> asymmetric-key-pair-with-cert-grouping contains a private/public key pair and an associated certificate. The grouping uses; 
> - asymmetric-key-pair-grouping
> - end-entity-cert-grouping
> - generate-csr-grouping
> as defined above.
> 
> asymmetric-key-pair-with-certs-grouping is similar to 'asymmetric-key-pair-with-cert-grouping' but contains a list of end entity certificates for the public key where, for example, there are separate certificate for IDevID and LDevID [reference**]
> ====================================================
> 
> ________________________________________
> From: netconf <netconf-bounces@ietf.org> on behalf of tom petch <ietfc@btconnect.com>
> Sent: 17 June 2020 17:23
> To: Kent Watsen
> Cc: Netconf
> Subject: Re: [netconf] WG LC for three drafts or two of them
> 
> From: netconf <netconf-bounces@ietf.org> on behalf of tom petch <ietfc@btconnect.com>
> Sent: 13 June 2020 12:29
> 
> <tp>
> I thought about the text I would like to see in crypto-types and starting with identity since they are simplest I came up with
> NEW
> This module contains YANG identity for private keys, public keys and symmetric keys.
> 
>> From the base "private-key-format" there are derived identity for
> - rsa-private-key-format as defined in RFC 3447
> - ec-private-key-format as defined in RFC5915
> - one-asymmetric-key-format as defined in RFC 5958,
>          encoded using ASN.1 distinguished encoding rules
>          (DER), as specified in ITU-T X.690.";
> - encrypted-one-asymmetric-key-format, as defined in RFC 5958,
>          encoded using ASN.1 distinguished encoding rules (DER),
>          as specified in ITU-T X.690.";
> 
>> From the base "public-key-format" there are derived identity for
> - ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:
> - subject-public-key-info-format as described in RFC 5280 encoded using ASN.1
>          distinguished encoding rules (DER), as specified in
>          ITU-T X.690.";
> 
>> From the base "symmetric-key-format" there are derived identity for
> -  octet-string-key-format encoded as a raw octet string.
> -  one-symmetric-key-format as defined in RFC 6031 and
>          encoded using ASN.1 distinguished encoding rules
>          (DER), as specified in ITU-T X.690.
> -  encrypted-one-symmetric-key-format as defined
>          in RFC 6031 and encoded using ASN.1 distinguished
>          encoding rules (DER), as specified in ITU-T X.690.";
>            Specification of Basic Encoding Rules (BER),
>            Canonical Encoding Rules (CER) and Distinguished
>            Encoding Rules (DER)
> 
> Obviously all I have done is take the text and reformatted it. I debated about keeping the references to CMS.  The aim is to tell the reader whether or not to dig deeper into the YANG in order to use it.  For groupings I see more new text needed
> 
> Tom Petch
> 
> 
> 
> 
> 
> I have concerns about trust-anchors and crypto-types.  They are both more or less non-existent when it comes to text.  I do not want to have to reverse engineer the YANG or XML to find out what RPC or action there are, what types of cipher suites and such like are supported - and perhaps those that are not such as raw keys.  I would expect there to be five or ten pages of such in each.  Look for example at layer0-types or layer1-types for modules with what I would regard as adequate text.
> 
> Tom Petch
> 
> From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org>
> Sent: 12 June 2020 21:03
> 
>>> -----Original Message-----
> 
>>> From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
> 
>>> Jethanandani
> 
>>> Sent: Tuesday, June 2, 2020 7:48 PM
> 
>>> To: Netconf <netconf@ietf.org>
> 
>>> Subject: [netconf] WG LC for three drafts
> 
>>> 
> 
>>> NETCONF WG,
> 
>>> 
> 
>>> The authors of
> 
>>> 
> 
>>> - draft-ietf-netconf-crypto-types
> 
>>> - draft-ietf-netconf-keystore
> 
>>> - draft-ietf-netconf-trust-anchors
> 
>>> 
> 
>>> have indicated that these drafts are ready for Last Call (LC).
> 
>>> 
> 
>>> This kicks of a 2 week WG LC for the three drafts. Please review and
> 
>>> send
> 
>> any
> 
>>> comments to the WG mailing list or by responding to this e-mail.
> 
>>> Comments can be statements such as, I read/reviewed the document and
> 
>>> believe it is ready for publication, or I have concerns about the
> 
>>> document. For the
> 
>> latter,
> 
>>> please indicate what your concerns are.
> 
>>> 
> 
>>> Any reports on implementation status or plans to implement are also
> 
>>> very useful.
> 
>>> 
> 
>>> Thanks.
> 
>>> 
> 
>>> Mahesh Jethanandani (as co-chair)
> 
>>> mjethanandani@gmail.com
> 
>>> 
> 
>>> 
> 
>>> 
> 
>>> _______________________________________________
> 
>>> netconf mailing list
> 
>>> netconf@ietf.org
> 
>>> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf