Hi John, On 2020-11-24, at 10:58, John Mattsson <[email protected]> wrote: > > Hi, > > We have addressed most of the comments that we got during the meeting. Some > issues require some more discussion and are listed below. Any comments on the > issues below or reviews of the whole -04 draft is very welcome. > > CBOR Certificates Open Issues: > > - Should a CBOR certificate be a CBOR Sequence or a CBOR array? Making it an > array would add 1 byte, but maybe it has benefits with CDDL validation using > current tools.
I’d rather fix the tool instead of spending that byte. I added an option to the verification choice in the CDDL tool that makes it read a sequence as an array. That should allow directly using the method recommended in RFC 8742. Usage: cddl foo.cddl vs bar.cborseq (v for validate, s for sequence). $ cat sequence.cddl a = [tstr, tstr, tstr] $ echo aaaaa | cddl sequence.cddl vs - $ echo aaaaa | cddl sequence.cddl vsp - /a/ [/tstr/ "a", /tstr/ "a", /tstr/ "\n"] $ (“a” is 0x61, the head for a text string of length one.) Use `gem update` to spring forward to cddl tool version 0.8.15 (*). > - Is "#6.6(bstr)" the correct way to write CDDL for tags-oid? Assuming the > label 6 will be used in the end. Would be good with something more readable > like biguint. 6 will not be the tag number; that would be a quite old version of the draft. Please see https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-03.html for a fresh version. Section 8: https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-03.html#name-cddl-typenames also has suggested CDDL that you can add to your spec. > - Do any algorithms with parameters need to be supported? Algorithms with > parameters are e.g. RSA-PSS with SHA2, id-ecPublicKey with id-ecPublicKey and > specifiedCurve are MUST NOT be used in PKIX according to RFC 5480. You mean with parameters beyond namedCurve? > - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit > strings are used in public keys and signature values. Good question. I’m not aware of anyone being that foolish. I would argue that we don’t need to support such foolery even if it does exist. > - Do any more attributeTypes need to be supported? Do oid-tags need to be > supported for attributeType? (Don’t know.) > - Do any more character string types than printablestring and utf8string need > to be supported? E.g. TeletexString, BMPString, or UniversalString, or > IA5String? Neither of therse should be used in new certificates. Again, even if they exist in the wild we should not support such foolery. > - Should the draft use unwrapped CBOR tag 1 for validity? That CBOR > implementations already support unix time removes one of the problems. RFC > 5280 certificates can use leap seconds, is this important to support? Unix > time does not. There are examples of certificates using generalized time for > dates < 2050 (in violation with RFC 5280). We could decide to not support > these. To have a problem with the UNIX time scale, a certificate would need to put one of its significant points in time on a leap second. This is hard to do for future times, as we usually don’t know more than half a year into the future whether there will be a leap second at one of the possible instants. Certifying a key at a leap second would probably generate enough interop problems that any CA would avoid that. So I don’t think we need to support leap seconds (read: provide a way to express instances of time that are on a leap second, 23:59:60 UTC). > - Do any more types of subjectAltName need to be supported? E.g. x400Address, > ediPartyName, and registeredID? Good question. > - Which optimizations are worth having and what kind of certificate should we > optimize for. The draft currently optimize encoding of the example > certificate. Encoding subject as a byte string provides quite big savings (17 > bytes). These are the savings we are looking for. (But, any German should know, “Kleinvieh macht auch Mist”, i.e., “Many pennies make a dollar”.) > - How to encode extensionvalue for non-7925 extensions? Should they stay DER > encoded byte strings, should we specify an encoding for each, can we come up > with a general DER-CBOR encoding that can be applied to them all? We could. I haven’t tried, but that would probably not save a lot. Do we have an example corpus of such extensions? > - There was a suggestion that SHA-1 algorithms should get large values, but > sha1WithRSAEncryption is still one of the most common algorithm. It is quite > commonly used in self-signed root certificates, where it is fine to do so. Agree. > - Do anything else similar to SCT list and id-at-organizationIdentifier that > has been specified after RFC 5280 need to be supported? Don’t know. Grüße, Carsten (*) Yep, that is a weird number to a German. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
