> 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
