On Thu, Jul 16, 2020 at 11:38:06AM +0200, Joel Höglund wrote:
> Hi!
>
> Ilari Liusvaara, we are grateful for your detailed comments, and
> constructive proposals. With an extra thank you for sharing your insights
> on which field types that are actually in common use. Your comments
> highlight the need to further discuss trade-offs between compactness,
> generality and ease of implementation.
The principles I followed were mostly:
- Try to do something simple, yet compact in common cases. The solution
may or may not be pareto-optimal. And even if it is pareto-optimal, it
may or may not be the best.
- Offer escape hatches, unless fundamential PKIX limitation.
- Minimize the impact of escape hatches on common case (mostly no
impact).
- Check RFC7925 for the most important extensions, then check RFC5280 to
see if there are more extensions that could be considered important
(turns out there are none that are not iffy).
There are some simple optimizations left. For example, one could encode
CN-only names as just tstr/bstr, like is done in
draft-mattsson-cose-cbor-cert-compress-01. This would save 2 bytes for
such name (by eliminating array and integer type tag).
> As you might have seen, we have merged and updated the old cbor certificate
> related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) where
> we have added some more details regarding encoding and optimizations. We
> will look closer to the implications of your proposals as input for
> upcoming revisions.
The approach in draft-mattsson-cose-cbor-cert-compress-01 seems much
more specialized. It will probably be at least a few bytes more compact
than what I came up with, but can encode much fewer certificates (which
still may be plenty).
Some issues I noted in draft-mattsson-cose-cbor-cert-compress-01:
1) The encoded certificates may be CA certificates, which would
presumably indicate that issuer certificate can be explicitly
encoded.
There are at least two issues with encoding such certificates:
a) because subject of issuer must equal issuer of subject (preferably
bitwise), and subject is CN-only the name of any such CA is
restricted to be CN-only. Which is not really sufficient for CAs,
as I would also at least expect unique identifier of the
organization.
b) The issuing certificates commonly have Pathlen=0, which is not
RFC7925-compliant, and is not possible to encode.
If it is not intended to have explicit issuers, one could remove
the CA flag entierely, and assume that BasicConstraints is always
empty.
2) ExtendedKeyUsage is not fixed-order:
ExtendedKeyUsage is SEQUENCE of OBJECT IDENTIFIER. Neither RFC5280
nor RFC7925 define order. So presumably the order used is CA-
dependent, and does affect the signature.
4 bits is not sufficient to represent non-empty ordered subsets
of 4 elements. One needs at least 6 bits for that.
However, one could fit the thing in 4 bits by noting that combining
id-kp-OCSPSigning with anything else is Bad Idea. And non-empty
ordered subset of mutually exclusive sets of 3+1 elements does
fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA,
CAB, CBA, Z).
3) id-kp-serverAuth/id-kp-clientAuth are TLS-only (the "WWW" in the
description should read "TLS"). This does also encompass DTLS (and
future cTLS). But it does not encompass EDHOC.
EDHOC uses signatures in way incompatible with TLS, and using the
same key in multiple incompatible ways is not a good idea. Altough
none of COSE, JWS, X.509 and TLS 1.3 interact harmfully (for pretty
obvious reasons), e.g., analyzing if TLS 1.2 and COSE would interact
harmfully is not trivial.
EDHOC would need its own ExtendedKeyUsage values. And those can
not be encoded within RFC7925 profile (encoding non-empty ordered
subset of mutually exclusive sets of 5+1 elements would need 9 bits
to encode (as there are 326 possibilities)).
4) The draft uses TLS certificate compression instead of TLS certificate
types. These two have different semantics:
- TLS certificate types are about encoding of a single certificate
(it is assumed that all the certificates in chain are of the same
type).
This seems to match with what this draft is doing.
- TLS certificate compression compresses the entiere TLS certificate
messages in one go. With potentially many certificates, and
extension blocks for each (which are used, e.g., for OCSP).
It is only meant to be used with possibly specialized general-
purpose lossless data compressors (meaning can produce valid, but
possibly not well-compressed, bytestream for any input). Even the
much more general compressor I outlined is not even close to
general-purpose (as there are plenty of inputs where it can not
produce a valid bytestream).
And TLS certificate compression and TLS certificate types can both
be used at once. In this case the decompression is expected to
produce certificate(s) of correct type. If it does not, the
certificates(s) very likely get parsed wrong (hopefully running
into fatal parse error).
>
> On Fri, 10 Jul 2020 at 14:58, Ilari Liusvaara <[email protected]>
> wrote:
>
> > 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
> >
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
