Re: [Cbor] CDDL in draft-ietf-acme-star-delegation-07

Carsten Bormann <cabo@tzi.org> Tue, 06 April 2021 15:46 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDF3A2654; Tue, 6 Apr 2021 08:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 ZpNB6A5bQGiS; Tue, 6 Apr 2021 08:46:15 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBA43A2618; Tue, 6 Apr 2021 08:46:14 -0700 (PDT)
Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FFBhN2DpLzyR4; Tue, 6 Apr 2021 17:46:12 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <215725D8-7589-4121-A209-5E8802291955@ericsson.com>
Date: Tue, 06 Apr 2021 17:46:11 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>, "draft-ietf-acme-star-delegation@ietf.org" <draft-ietf-acme-star-delegation@ietf.org>
X-Mao-Original-Outgoing-Id: 639416771.594656-415d36642fb40dcd4f76fe3c62702e57
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E353DC2-E9E5-4BDE-9522-024A080093BB@tzi.org>
References: <215725D8-7589-4121-A209-5E8802291955@ericsson.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/23A-PFhRY-pdkg2-Kgcd4jqySVo>
Subject: Re: [Cbor] CDDL in draft-ietf-acme-star-delegation-07
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2021 15:46:23 -0000

Hi Francesca,

here are a few comments.

(1)
The json-schema.org definition uses oneOf, which should never be used (anyOf is usually what is actually meant; this is a well-known problem in the json-schema.org vocabulary).

(2)
keytypes is missing a minItems=1.

(3)
The regexp for “oid” (in both JSO and CDDL) is quite permissive with respect to leading zeros.  It is rather unusual to have leading zeroes (except for arc zero itself) in OID strings, so there might be some interop issues with that.

(4) the intro to the CDDL should probably mention that the multipleOf=8 on the RSA key size is not reflected in the CDDL, nor are the format=xxx keywords (which are not terribly well-defined in JSO either).

(5) subjectAltName.DNS items allow “*” and “**” in the CDDL form but might not in the JSO form (format=hostname).

CDDL Style nits:

(a)
rsaKeySize = int .ge 2048
=>
rsaKeySize = uint .ge 2048
While these mean the same in CDDL, converters such as CDDL-YANG converters could put in different underlying built-in data types, and uint is actually the basic type for a size in bits.

(b)
There are a number of “1*” occurrence qualifiers that might be slightly more readable as “+”. 

(c)
regtext-or-wildcard could be simplified by making use of prioritized choice (Appendix A of RFC 8610).  Of course, the current form is easier to translate into other specification formats (which actually wasn’t done for the JSO form), so this is just a note.  

(d)
The non-empty object requirement (JSO: minProperties=1) could be stated in CDDL as

({……}) .and ({ + any => any })

To reduce noise, a generic could be defined:

non-empty<M> = (M) .and ({ + any => any })

…and used:

distinguishedName = non-empty<{
  ? country: regtext-or-wildcard
...
}>

There is not a lot of tool support for .and, so I am not going to push for this, but it sure works for me.

Grüße, Carsten



> On 2021-04-06, at 12:18, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:
> 
> CDDL experts,
> 
> I am reaching out because draft-ietf-acme-star-delegation-07 is in IESG review, and it contains some normative CDDL, accompanied by non-normative JSON schema alternative, which I don't think got any reviews from (other than authors) CDDL folks. I have personally checked the CDDL via tools, but another set of eyes looking would be great.
> 
> If you have a second to take a look at it, ad send any feedback before tomorrow, I would be very grateful: https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation-07#appendix-B 
> 
> (Yes, this will become part of the ART Area Review Team area of competence, and you are very welcome to take part in that discussion https://mailarchive.ietf.org/arch/msg/art/lZD8ommZAxqSTJ43YZ-RK7bL4Mw/ )
> 
> Thanks,
> Francesca
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor