Re: [SPICE] Call for consensus on SPICE charter

[Manu Fontaine <[e-mail]>]

Thanks Henk, I hope you'll be in Brisbane so we can meet in person.

Our perspective is that CC is literally (chip+workload) identity and
cryptographic security at the *physical* layer. It's the infamous "missing
layer" of the internet that we've all been looking for. It's *the* security
bedrock.

I cannot think of better places than the intersection of CCC and the IETF
SEC Area to re-imagine security from the silicon up.

Manu


On Sun, Feb 25, 2024 at 11:17 PM Henk Birkholz <[e-mail]>
wrote:

> Dear Manu,
>
> I've been a member of the Confidential Computing Consortium since its
> formation. I agree the CCC work is an implementation steered hub that
> binds many, many of the standardized building blocks that you mentioned.
> And a lot of IETF contributors and implementers meet there to find
> common ground, generalize APIs across hardware, and complain about
> Attestation Evidence heterogeneity all the time (that is fun, too).
>
> Advertisement hat on: It's a great place! Have a look!
>
> There is a tendency to produce confidential computing solutions from the
> bottom up - okay. But I'd not go so far as to say the "infrastructure
> layer" is the nucleus here. A ton of work is done on the API level and
> the OPS level and the IETF provides these really useful nuclei, one of
> them draft-ietf-rats-ar4si. That work shows that all pieces of the stack
> are important to the assessment, even the infrastructure layer. Is the
> situation great across vendors on that layer? Probably not great. Are we
> trying to give the best incentives to make it better? Yes!
>
> Let's try to scope the SPICE WG in a way that attracts the real-world
> experts, both users that really need standards, because "all I have are
> these ancient processes and documents and everything seems to be hyper
> confidential and now it must be interoperable and secure next week?" and
> experts that bring the experience to the SPICE WG that have the
> potential to solve parts of the problem. The interconnected system you
> are illustrating is not blocked by that. I think it is a good way to get
> there in time, actually. And it requires to listen to other WGs experts
> and interact with them in the IETF. I think that's great.
>
>
> Viele Grüße,
>
> Henk
>
> On 24.02.24 17:11, Manu Fontaine wrote:
> > 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/
> >     <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/
> <
> 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]
> >     <mailto:[e-mail]>> wrote:
> >
> >         On Fri, Feb 23, 2024, 5:17 PM Kaliya Identity Woman
> >         <[e-mail] <mailto:[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] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/spice
> >         <https://www.ietf.org/mailman/listinfo/spice>
> >
> >     --
> >     SPICE mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/spice
> >     <https://www.ietf.org/mailman/listinfo/spice>
> >
> >
>