A few thoughts inline ...
> On Jul 21, 2020, at 7:50 AM, Ilari Liusvaara <[email protected]> wrote:
>
> 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.
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
You need a way to be clear the difference between no BasicConstraints at all
and a BasicConstraints with cA=False and pathLen absent.
> 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).
Yes, a SET OF would have defined an order, but it does not help the relying
party, who only cares about whether a particular OID is in the SEQUENCE or not.
Putting them in the same order as SET OF would work for new certificates, but
it will not help with existing ones.
> 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)).
Agree that new EKU values are needed for this context.
Russ
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
