Micheal: I suspect that many IoT devices will need to be able to connect to existing infrastructure, and if the requirements get too tight, then people will put proxies in place to avoid changing the certificates on existing infrastructure. That thinking leads me to a view that we can get great compression when the reasonable subset is followed, but we need to accommodate things outside the subset, even if it means less compression.
Russ > 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 > [ > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
