Hi Russ, Then I suggest stick with not supporting RSA-PSS+SHA2. RSA-PSS with SHAKE is supported if people would start to use RSA-PSS.
I already made a commit to support email addresses in issuer, subject, and subjectAltName. assume there a three places you see email addresses. Supporting email addresses in issuer and subject was an easy fix. Henk also indicated before that he thought it probably needed to be supported. Based on your comment on time I made a commit to use POSIX time which is easy given that people follow RFC 5280/2459. I think we should only support things that deviates from RFC 5280 if it happens to be very widespread. With the new commit time is encoded as unwrapped CBOR epoch date/time (label 1). This simplifies things and aligns with CBOR. It saves 1 byte for dates in the range 2050-2106 and adds 4 bytes for dates in the range 2106-9999. /John -----Original Message----- From: Russ Housley <[email protected]> Date: Wednesday, 25 November 2020 at 22:11 To: John Mattsson <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] CBOR Certificates Open Issues > On Nov 24, 2020, at 5:15 PM, John Mattsson > <[email protected]> wrote: > > 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. I see no uptake of RSA-PSS or RSA-OAEP or RSA-KEM, so it seems reasonable to let them fail compression. >>> - 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. Okay. >>> - 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. I see email addresses in three places, but I would really encourage people to only use rfc822Name in the subject alternative name extension. As best I can tell, the other two locations are to support legacy applications, and I hope that IoT does not have too many of those yet. >> - 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. This convention has been around since 1999. RFC 2459 says: CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. I hope we can count on it. Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
