Re: [PROPOSED WORK ITEM] ECDSA Secp384r1 Cryptosuite v2019

Agree that the CCG probably lacks the security expertise to debate
cryptographic suites and their implementations and serializations.

We need to be clearer, I think it's dangerous and harmful to conflate "JWK
is a bad key representation", with "the fact that JWK can represent all
existing keys is bad" and "some developers will just allow all valid key
representations in the app layer".

The fact that JWK / JWS / JWE can represent existing cryptography is good.

The fact that developers can choose which JWK suites to support (at the
application layer) is good.

The fact that some developers choose to write software that lets other
developers choose which JWKs, JWEs, or JWSs to use at the application layer
is good.

The fact that "trusted experts" can recommend a subset of JOSE for a given
threat environment is good.

I don't need a standards organization (or community group) to tell me
which keys to use.... I need them to tell me how a key is represented when
it conforms to a specific standard.

JOSE, COSE and PGP are successful because they accomplish this objective.

JSON-LD Proof Suites are "getting better" at doing this, but they need to
be a lot better to justify a switching cost.

Most the citations requests in the previous email seem to be regarding the
conflation of "key representation standard" vs "cipher suite standard".

I don't have anything but experience working with JOSE, COSE, PGP and
JSON-LD to base my opinions on. I like clean layers:

Higher Order Data Models (WebAuthn, DIDs, VCs) <- you are here.
Serialization (controlled by IETF)
Raw Crypto (controlled by IETF)

Calling the serialization layer for key types a "footgun" is like
complaining that knowledge representations are a "footgun" because they
allow for representations of lies... its a mind projection fallacy at best.

I am not opposed to higher order data models, or even alternatives to the
lower layer standards... but I am strongly opposed to attempting to
vertically integrate on a subset community drafts while throwing existing
standards under the bus as "footguns"... if we agreed to only use certain
kty / crv and certain alg... we would have the exact same proposal.... only
built on existing standards... the current proposal is worse than that,
because it requires more work... and relies on less durable standards.

I could make the same argument with CBOR instead of JSON.

Calling JOSE / COSE footguns as justification for standardizing alternative
representations for a subset of their keys and algorithms... seems like a
facegun.

(its selling the lack of capabilities as a "feature".... which is not
appropriate at any layer except for the "experts recommend you ONLY use
these" layer.)

If the vision for JSON-LD keys, ciphers and proof suites is "like JOSE but
with support for less keys and less algorithms, and with less off the shelf
tooling, and less language support, and less documentation and more
opinionated naming conventions"... its a hard sell for me... I suspect it
will be for other developers.

I am asserting that conflating "raw crypto"  with "serialization" with
"recommended serializations by experts you trust" is an anti pattern.

Each is useful, and a proper combination of them could justify more
investment at each individual layer (including alternatives for that layers
most popular standards)... but conflating them all together is not
attractive to me as a contributor.

The only thing that would change my mind as a developer would be a grander
vision for replacing JOSE / COSE with something better... which would
require a cleaner separation of layers and more respectful tone to the
importance of separate layers... and probably a backwards compatibility
mapping to encourage upgrades.

Regards,

OS



ᐧ

On Mon, Jan 24, 2022 at 11:13 AM Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> Do the Ockam folks know about this? It seems up their alley:
> https://github.com/ockam-network/ockam
>
> -Brent
>
>
> On Mon, Jan 24, 2022 at 10:13 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 1/24/22 9:41 AM, Orie Steele wrote:
>> > It's likely that secp384r proposal you are making is redundant to both
>> multikey-2021 and jws-2020
>>
>> The multikey spec, as it is currently specified, is a security footgun and
>> kitchen sink specification.
>>
>> JWS-2020, as it is currently specified, is acceptable (if one accepts the
>> security dangers with accidentally mixing up the
>> keys/parameters/algorithms in
>> JWS -- which has been a source of security vulnerabilities). JWS-2020 also
>> requires the usage of the JOSE stack where the currently proposed
>> specification does not.
>>
>> > to justify the switching cost to lazy developers
>>
>> We should not be optimizing a security solution towards laziness. We
>> should be
>> optimizing so the system fails closed when bad inputs are provided
>> (instead of
>> the proposals you mention above, which run the risk of failing open when
>> bad
>> inputs are provided).
>>
>> > a standard that can only represent a subset will always
>> > lose out to a standard that can represent the full set.
>>
>> Debatable... do you have a citation?
>>
>> > a community draft that does not define the private key
>> > representations. I can see one for multibase proposals,
>> > I strongly object to standardizing public key only
>> > representations.
>>
>> Again, debatable... citation? This is also an orthogonal debate, and is
>> your
>> (well understood) opinion. Some of us just have a different opinion.
>>
>> We should note that the purpose of the work item is to ensure that some
>> variation of secp384r1 is in scope for discussion in VCWG 2.0. Blocking
>> our
>> ability to put the discussion in scope in the VCWG does not seem like a
>> sound
>> strategy.
>>
>> It's worth pointing out that the CCG has historically been fine with
>> running
>> multiple work items that might conflict (at a philosophical level) with
>> one
>> another (such as Ed25519Signature2020 /and/ JWS-2020). The place to
>> debate and
>> narrow down the final technical solution is in the VCWG, not in an
>> incubating
>> body such as the CCG.
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> News: Digital Bazaar Announces New Case Studies (2021)
>> https://www.digitalbazaar.com/
>>
>>
>>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>