Thanks Russ, >> - 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.
As pointed out also by Carsten, 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. >> - 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. Thanks, good to get confirmation that unused bits != 0 do not need to be supported in public keys and signature values. The question was really just for these two cases. The bit string in the key usage extention is already encoded as an int. >> - 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. RFC 5280 states that "Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted." Given your answer I guess CAs are still putting emailAddress and IA5String in new certificates and that it need to be supported. I made a commit to support emailAddress. > - 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. If CAs follow RFC 5280, we could encode both UTCTime and GeneralizedTime to POSIX time without additional information. It would be one-to-one. If CAs use GeneralizedTime for dates earlier than 2050, it would not be one-to-one and we need to do something more. >> - 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. Good point. Not as often as other certificates, but the root certificates need to be transfered to the IoT devices at least once in the factory or when they are deployed. IoT devices may want to store there root certificates as CBOR certificates to save storage and memory. Compressed root certificates would not even have to be decompressed again. Cheers, John -----Original Message----- From: Russ Housley <[email protected]> Date: Tuesday, 24 November 2020 at 16:31 To: John Mattsson <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] CBOR Certificates Open Issues 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
