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

From: Francesca Palombini <[email-masked]>
Date: Tue, 6 Apr 2021 10:18:55 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Apr 2021 17:46:11 +0200

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=[email-masked]> wrote:
> 
> CDDL experts,
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 6 Apr 2021 16:56:53 +0000

Thank you very much for the super quick and rigorous review Carsten! This is extremely helpful, I will point to your comments into my ballot.

Francesca

On 06/04/2021, 17:46, "CBOR on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Francesca,

    here are a few comments.

    (1)

    (2)

    (3)

    CDDL Style nits:

    (a)

    (b)

    (c)

    (d)

    …and used:

    Grüße, Carsten