On Tue, Jul 21, 2020 at 08:19:30PM -0400, Michael Richardson wrote: > > 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 most end-entity stuff just has one of the SANs duplicated as CN and nothing else. Omitting subject is fairly rare due to some software puking on that. > 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. I think names are usually PrintableString. Utf8String is just used for the cases where PrintableString just won't do (PrintableString is proper subset of ASCII, most notably @ and & are not in it). > >> 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 :-) Well, codepoints are pretty cheap here. There are 24 one-byte uints, and the above just uses 3 of those. And even if it was not, it would be maybe a two dozen or so more bytes. > 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. Well, on TLS/HTTPS, there is mostly WebPKI, which mandates all sorts of effectively uncompressable junk. Looking at one 1169 byte certificate, removing all the junk would make it shrink to ~650 bytes. And using more efficient crypto would shrink it to ~405 bytes. And fair bit of thet ~405 bytes could be compressed. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
