On Jul 21, 2020, at 8:19 PM, Michael Richardson <[email protected]> wrote:
Signed PGP part
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 [
