Re: [SPICE] Call for consensus on SPICE charter

[Manu Fontaine <[e-mail]>]

I am reacting to mentions of "hardware", "balance", and "maximalist
positions" regarding important parts of "delivering secure and usable
systems".

Confidential Computing hardware (TEEs) is readily available, and a
blueprint exists
<https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-05-a-universal-name-system-uns-and-universal-certificate-authority-uca-00>
to solve for global assurance of provenance, integrity, authenticity,
confidentiality, reputation, and privacy for all bits, be they code or
data, for persons and non-person entities. No exotic cryptography required.

The problem space collapses when using Confidential Computing at the
"infrastructure layer". In 2024, identity, authentication, authorization,
data encryption, key management, and credentialing should all be
re-imagined on top of Confidential Computing, if for nothing else than CC
providing attestation+verification of hardware+software integrity. Why
would anyone not want to verify these critical pieces of infrastructure?
#zerotrust

I am still an IETF newbie trying to understand how to bring this work to
the IETF, realizing that it's tricky as it overlaps with many WGs. I'll be
in Brisbane and will schedule a side meeting to give an update on our work
in this direction, and I hope to start/continue conversations with all of
you.

Manu


On Fri, Feb 23, 2024 at 9:58 PM Orie Steele <[e-mail]>
wrote:

> The charter mentions profiles of JWP/CWP, which is from JOSE not OAuth,
> and which supports BBS, but can be extended to other systems, assuming they
> can support similar interfaces.
>
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
>
> I'd personally like to see CFRG publish some lattice based zkp system that
> could offer similar capabilities... Probably, we are years away from seeing
> hardware support for that... I'd be happy to be wrong, as long as the
> lattice system lasts longer than elliptic curve discrete log.
>
> In the informal meetings, which we have had, BBS has been discussed a lot.
>
> As have the consent and privacy issues, and infrastructure costs
> associated with single use key bound credentials, which include ISO mDoc
> and SD-JWT.
>
> Sustainability, privacy, inclusivity and transparency are all important
> parts of delivery secure and usable systems.
>
> Some balance is necessary, because we are unlikely to agree to maximalist
> positions on any one of these important dimensions.
>
> See also:
>
>
> https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/
>
> OS
>
>
> On Fri, Feb 23, 2024, 8:36 PM Watson Ladd <[e-mail]> wrote:
>
>> On Fri, Feb 23, 2024, 5:17 PM Kaliya Identity Woman
>> <[e-mail]> wrote:
>> >
>> > I don't know what you mean by "privacy" Nick.
>> > I think the folks who are in the trenches of developing the protocols
>> of digital identity at least those arising out of the community arising
>> from Internet Identity Workshop community have been very focused on how to
>> best give individual people the most control possible over how they can
>> leverage digital credentials and have worked very hard.
>>
>> Results, not effort, matter.
>>
>> >
>> > We have also come up against very real world constraints - while the
>> BLS family of cryptography that the BBS+ work is anchored in and is
>> progressing through CFRG is fantastic in providing a path forward for
>> really great selective disclosure capabilities.  It isn't finished review
>> and it hasn't been standardized for how to actually use it to create
>> credentials (Although some great companies leading this work have been
>> experimenting).
>>
>> Isn't that the work of standards bodies and companies to develop the
>> tech and standardize?
>>
>> > Even if it WAS ready "now" the phones that are on the market and widely
>> adopted don't have the capabilities to actually do BLS signatures to anchor
>> the credentials to phones.   (for better or worse this is the primary
>> subject holder binding mechanism that European governments have decided to
>> proceed with for the issuance of state issued documents to
>> citizens/residents).
>>
>> I'm not that familiar with secure element design but I have written
>> papers and run code showing that it's possible to achieve these
>> bindings while preserving privacy and not modifying the element. Now
>> there were some mistakes later work has fixed but it is possible: see
>> SAC '21 and the successor that fixes some stuff is a preprint I can
>> share.
>>
>> >
>> > Extensive research into all the possibilities of formats and signatures
>> and bindings was made and I believe that SD-JWT was the best possible one
>> out of the bunch given all the REAL WORLD constraints. (see this community
>> built spread sheet for the details)
>> >
>> > I think we need the SPICE working group in the IETF to actually make a
>> home to continue to progress the work towards even better credentials with
>> better properties. It is specifically envisioned by the folks who are
>> asking for this working group that work on how to do credentials with BBS+
>> signatures would happen in this group once the CFRG review is complete and
>> I know that there are government folks who want better choices then they
>> have now in terms of ways to protect and support citizen empowerment and
>> "privacy".
>>
>> But that's not what the group is being singularly chartered for nor is
>> it combining all this work over the IETF. The debate here is really
>> about what should be done in the group and elsewhere, and if the
>> charter was BBS identity I think a lot of people would support it.
>>
>> >
>> >
>> > If we don't actually make space to move the work forward it can't move
>> forward.
>>
>> No one is saying we shouldn't do BBS based credentials here. We're
>> asking questions about the scope and whether or not to approve
>> mechanisms that don't meet the bar privacy wise without a lot more
>> effort in deployment that's been pushed out of scope.
>>
>> >
>> >
>> > I find it a bit hard to take seriously folks who have not been actively
>> engaged in the community working on digital credentials for people landing
>> down taking one glance around and saying in an off the cuff way "its not
>> good enough privacy" when they have not really taken the time to understand
>> the history, context, real extremely extraneous effort that has been put
>> into achieving the development of reasonable systems within the real world
>> constraints that really exist.
>> >
>> > Maybe it is our job to do a better job to communicate this prior art
>> and significant body of existing work, and really dedicated people who have
>> a real commitment to core positive values.
>>
>> If this community was committed to privacy you'd collectively away
>> when the constraints make it impossible. That's what being committed
>> to values means. Luther did not say "I stand here, and I'll move a bit
>> if it's inconvenient".
>>
>> SD-JWT isn't a minor privacy problem. It lets the government track
>> every time you use a credential online, with active proposals to
>> mandate it for the viewing of "sensitive" materials, a category
>> encompassing some of the most beautiful photography of the 20th
>> century, several Oscar winning movies. Some governments will of course
>> seek to extend this further to Winnie the Poh memes, French Peanuts
>> reprinters, or news Carter-Ruck doesn't like.
>>
>> >  The work has been happening in earnest with a coherent group of people
>> who have been inter-related and working together on this for 20 years.
>> Many of these people gather twice a year at the Internet Identity Workshop
>> and ongoing efforts inbetween happen in bodies such as the Decentralized
>> Identity Foundation, OpenID Foundation, Trust over IP Foundation, Kantara
>> Initiative, various W3C Community Groups.
>>
>> There has been inordinate work on credentials ever since CL01 and
>> CL04, and all of that has been ignored. It could have gone into secure
>> elements: TPM has DAA after all. But instead we get this. The lack of
>> engagement with cryptographers and privacy engineers is unfortunate,
>> but we can't ignore these issues on the basis that the water has
>> passed under the bridge.
>>
>> >
>> > I have only been to the last two IETFs and I was really impressed with
>> the deep collective intelligence and wisdom I saw in action.  I was
>> surprised about how many different working groups who's efforts touch in
>> some way on identity are not intersecting very much or learning from each
>> other (PrivacyPass has quite limited overlap with OAuth work - TIGRESS is
>> working on moving keys between phones/wallets? also not interacting with
>> work focused on that in the identity community)  Dick and Rifaat have a
>> great outline for an identity sense making effort that could go a long way
>> to helping various groups just as step 1 understand what each other is
>> doing.
>>
>> PrivacyPass is doing something different than OAUTH hence the lack of
>> overlap. If they overlapped more then there would be a problem.
>>
>> >
>> > I think SPICE is needed and I hope the charter will be approved.
>> > I don't think adding more MUSTs to the charter right now will help us
>> progress.  Folks who believe that certain properties and features should be
>> in protocols that the group works on should get engaged to struggle through
>> the real work needed to find the path - rooted in the real world of real
>> adoption by real users of the technology.  If it (digital identity) was
>> "easy" it would have been solved 15 years ago.
>>
>> And if the people solving it has been at all familiar with the
>> literature and cared about privacy they wouldn't have made SD-JWT.  If
>> we end up with SD-JWT everywhere choking the oxygen from a better
>> solution that's bad.
>>
>> End of the day there is no protocol police. So what exactly is it you
>> want the IETF to give you this real world adoption cannot? Why can't
>> we say "here's a privacy preserving solution to your problems" rather
>> than ratify a lot of very flawed work? To be clear I think we need to
>> have a forum to have this discussion, but to the extent SPICE isn't it
>> because things continue in OAUTH (thanks to JWT) and the charter
>> prejudges the result I'm against it. I'd support a broader charter
>> that doesn't have a commitment to ratifying SD-JWT.
>>
>> Sincerely,
>> Watson Ladd
>>
>> --
>> SPICE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spice
>>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>