Thanks for your comments and German lessons Carsten! >I’d rather fix the tool instead of spending that byte.
Agree. Thanks for fixing the tool. and I will try version 0.8.15 :) >6 will not be the tag number; that would be a quite old version of the draft. Yes, I must have looked at an an old version of the oid tag draft. I made a commit that use "oid" in CDDL. The tag number is not important anymore when there is suggested CDDL >> - 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? As pointed out also by Russ, this question was not well-formulated. Let me try again :) The current draft support id-ecPublicKey with namedCurve and RSA algorithms that set parameters to NULL. The question is if CBOR certificates need to support anything beyond this. RSA-PSS with SHA2 signatures are for example not currently supported, but does not seem to be used much. >> - 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). Agree, we do not need to support leap seconds. The question is if compression of certificates from misbehaving CAs using GeneralizedTime for dates before 2050 need to be supported. >> - 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. Probably not, but for natively signed certificates, the extensionvalues would have to be parsed. I would maybe not be so optimal to force devices to also support DER. >Do we have an example corpus of such extensions? The Web? Cheers, John -----Original Message----- From: Carsten Bormann <[email protected]> Date: Tuesday, 24 November 2020 at 11:40 To: John Mattsson <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] CBOR Certificates Open Issues 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
