- From: Brent Shambaugh <brent.shambaugh@gmail.com>
- Date: Mon, 24 Jan 2022 11:11:00 -0600
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CACvcBVqvFae6kzS1vqpCokbYgkR7oLnJjbUc_+d4kQhpFv8Eyg@mail.gmail.com>
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/ > > >
Received on Monday, 24 January 2022 17:11:25 UTC