On Thu, Jul 09, 2020 at 10:02:15PM +0200, Joel Höglund wrote: > Hi Henk and all! > > Thank you for your comments and update proposals! > > > In brief, there is definitely a need to clarify the assumptions about > existing x509 data structures we want to encode, and probably in some cases > make the proposal more general to allow more valid rfc7925 certificates. > Some further comments to the highlighted issues follows. > > 1. About Issuer-field encodings: We would like to have more discussions on > if for instance your directoryString proposal is necessary, or if the > string types can be assumed -- hopefully with input from others with > experience of how Issuer-fields normally are encoded.
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)>> Which is bit unfortunate in two ways: - Set of pairs is not the same as dictionary. - The right hand side type is Any, and not DirectoryString. - The outer list is usually of size 1. If one really wanted to eke bytes, one could have either 1 or 2 lists, since the the first element of inner list can not possibly be a list itself. If one goes for implementation complexity at cost of wire size, then one would always have 2 lists. And then one could have the Oid be encoded as integer for common ones and bstr for not-common ones. And the value could be str, which tries to autoguess the correct type, or bstr containing asn1tag+value as escape. 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). Then there is the special case where subject is empty. That could be encoded as empty list. > 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. For instance, this encoding could encode Ed25519 or X25519 key to 35 bytes (3 bytes overhead). And with regards to signature algorithm (which is actually encoded twic in X.509!), the common case is a few actually used algorithms. E.g.: 0 => Ed25519 1 => Ed448 2 => ECDSA SHA-256 3 => ECDSA SHA-384 4 => ECDSA SHA-512 5 => ECDSA SHAKE-128 6 => ECDSA SHAKE-256 That goes to 1 byte (and of course one could have bstr escape without affecting common case). > 3. About a general extension oid-mapping: We believe the four extensions > mandated by rfc7925 should suffice, but are open for hearing about IoT > requirements that go beyond those four. Extensions could be encoded as array of pairs (one would not want map here due to order-sensitivity). One could have generic encoding by having integers encode known extensions (negative integers encoding critiality) and bstrs encode escapes (the value of escape would be optional critical flag and then the raw extension value, which is an octet string). Known extensions would have more specialzed encodings. Examples of what could be more specialized encodings: KeyUsage: Integer value + (1 << bits). This would not allow KeyUsage bits above 63th, but I do not think the number of defined bits is anywhere close to that (RFC5280 defines 9 bits). And things could turn real annoying if KeyUsage ever needs to set any bit above 63rd. Sure, one could escape the thing, but relying parties might puke on that. None of the other three extensions ever needs escaping for any reasonable value. ExtendedKeyUsage: List of integer / bstr Integers would encode some common key usages, bstrs would be escapes (with just values). BasicConstraints: null/true/uint Null encodes empty extension, true encodes just true, and int would encode true followed by max path length. SubjectAlternativeName: array of bstr The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded as: 4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IPv6 address would take 18 (2 bytes overhead in both cases). The difficulty of adding extension beyond these four would depend on the extension. There would be slots for 24 compact extensions (20 more than here), 232 bit less compact ones, etc... Looking at the extension list from RFC5280, the only ones that do not look like unsuitable for IoT are subject/authority key ID extensions. Besides the incompatible encodings, if PKI is not crazy, one can use issuer/subject fields as key identifiers (however, comparing the above subject/issuer encoding could be annoying). So these do not look important. Looking at the other fields, how those could be encoded: - version: Implicit from presence of optional fields. - serial_number: bstr (with initial 00 if any stripped). - validity: pair of integers (unix timestamps). The time format would depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr with asn1tag+value as escape in case of misencoded certificate. - issuerUniqueID/subjectUniqueID absent, null or bstr (including the strip bits byte). If subjectUniqueID is present, issuerUniqueID has to be as well. Looking at these rules, this could encode a lot more than just rfc7925 certificates, as there is an escape for nearly everything. The only obvious thing with no escape is the serial_number, but any violation there would be fatal ASN.1 error anyway. These should even give valid compression/decompression for webpki certificates, even if bad one, due to the junk present. I have not written any proof-of-concept code for this. So no performance numbers to give. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
