John: A few thoughts on some, but not all, of you questions.
> - 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. The parameters must be supported. For id-ecPublicKey, the parameter is namedCurve. > - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit > strings are used in public keys and signature values. BIT STRING will not need unused bits for public keys or signatures, but BIT STRING is also used for the key usage extension. > - 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. Support for TeletexString, BMPString, and UniversalString is OPTIONAL in RFC 5280. However IA5String is needed for emailAddress because @ is not supported bt PrintableString. > - 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. it only maters that the mapping is one-to-one. > - Do any more types of subjectAltName need to be supported? E.g. x400Address, > ediPartyName, and registeredID? These are not likely to be used in the IoT environment. > - 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. When do you see the transmission of the root certificate? TLS sends the certification path up to, but not including, the root certificate. Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
