Re: [SPICE] Call for consensus on SPICE charter

[Henk Birkholz <[e-mail]>]

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>
> 
>