Re: [SPICE] Call for consensus on SPICE charter

[Denis <[e-mail]>]

Manu,

The "IETF SEC Area" is neither a BoF, nor a WG.

So the "intersection of CCC and the IETF SEC Area" will not be the SPICE 
BoF (nor a WG formed from it).

Within the IETF, the TEEP WG has produced RFC 9397, i.e., the Trusted 
Execution Environment Provisioning (TEEP) Architecture.
It is currently progressing draft-ietf-teep-protocol-18, i.e., Trusted 
Execution Environment Provisioning (TEEP) Protocol.
This can be viewed as a back-office management function.

The need to consider a TA running under a TEE in the context of SPICE 
does not originate from the Confidential Computing Consortium,
but from a security threat analysis focusing on the Holder.

The holder (application) needs to manage either asymmetric key pairs or 
Link Secrets together with Blinded Link secrets (BLSs).
Not only these keys need to be protected in a TEE, but also the TA 
(Trusted Application), i.e., the Holder, that manages and uses
them needs to be hosted in a TEE.

In the context of SPICE, from a front-office point of view, before 
issuing a digital credential to a Holder, the digital credential issuer 
needs to be convinced
that the digital credential request originates from a TA which supports 
"specific characteristics" and that this TA is indeed hosted in a TEE.
This missing piece of the puzzle could be developed in a future SPICE WG 
... or , even better, as an additional RFC published by the RATS WG.
This is why coordination with both TEEP and RATS is important.

A goal of a future SPICE WG should not be to build /the "missing layer" 
of the internet that we've all been looking for/", nor "/*the* security 
bedrock/".

Denis


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