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. - 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. - 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. - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit strings are used in public keys and signature values. - Do any more attributeTypes need to be supported? Do oid-tags need to be supported for attributeType? - 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. - 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. - Do any more types of subjectAltName need to be supported? E.g. x400Address, ediPartyName, and registeredID? - 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). - 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? - 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. - Do anything else similar to SCT list and id-at-organizationIdentifier that has been specified after RFC 5280 need to be supported? Cheers, John _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
