Ilari Liusvaara <[email protected]> wrote: > I would say that the encoding of the issuer (and subject) fields is the > most difficult part.
> Looking at the definition of issuer/subject, it is essentially:
> List<Set<(Oid, Any)>>
Yes, you are right.
To decode for others, the point is that one can have a DN like:
DC=tuna,DC=sandelman,DC=ca
this is rather uncommon, as most would use CN=tuna.sandelman.ca,
or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject.
I think that the question is perhaps:
* can we write a reasonable subset (BCP) profile of PKIX for constrained
environments?
> The type autoguess would guess PrintableString if every character is
> valid for PrintableString, else it would guess Utf8String. In practice,
> I do not think anybody uses any other ones (and wrong guess would be
> just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte
> penalty).
Who did the CSR, and did the CA molest the type at all?
Otherwise, we could just do Utf8String.
>> 2. About algorithm parameters: Our current assumption is that for our
>> target certificates, all needed algorithm info can be represented using
>> only the subjectPublicKeyInfo_algorithm field.
> Note that in practice, there are very few different SubjectPublicKeyInfo
> field types in any sort of wide use. Anything else is extremely rare.
> Thus, one could compress the field by having integer for type, and bstr
> for contents. And perhaps bstr type and bstr contents as escape hatch
> (maybe even with the bit stripping octet retained), should that be ever
> needed (that would not increase size in common case).
> For instance, types could be:
> 0 => X25519/X448
> 1 => Ed25519/Ed448
> 2 => ECDSA P-256/P-384/P-521.
> The type overloads are resolvable.
We'll have to have RSA in the list too. We may never want to use it, but I
think it will hav eto be there :-)
What I think we need to do is have someone implement the
compressor/decompressor and then do a survey of certificates out there via
TLS/HTTPS. That won't be definitive: we'll probably have some failures, and
we may declare them out-of-scope.
I think that the biggest problem will be what goes in the Issuer, which can
be empty, so it has all sorts of kinda throw-away stuff, then a simple CN=
would be enough.
See ^^^ about BCP.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
