CNCF projects are expected to follow the DCO.

It's a one click install to enable this for all the SPIFFE repos:
https://github.com/integration/dco

In cases where more than one SVID is returned for a workload, it is desirable to understand and/or control the ordering in which they are delivered and may be applied. This is currently undefined in the specification. I believe both an administrative component (e.g. a priority field in the X509SVID message) and a default component (e.g. SVID sorting) should be defined in some way. This would allow, but not require, control plane management as well as offer a solution for both default ordering so as not to require control plane operations as well as control plane conflicts where two or more SVIDs end up with the same ordering metadata.

It is possible that administrative selection of default SVIDs is outside the scope of this specification, and will be left to server implementations. In that case, some standard default mechanism should probably still be defined here.

Hello! Our team is working with SPIFFE Trust Map. The SPIFFE bundles mentioned that the format of a <trust_domain_name, bundle> tuple, but has no indication of how/where to store these tuples. We find it really convenient to have a standard format for SPIFFE Trust Map File, which will be a good place to keep track of this trust domain-bundle map and has some other benefits. Details about the question and our proposal can be found here. We'd love to hear about suggestions/thoughts.

From @justinburke

Having a map from trust domain to CRL(s) would probably help out client implementors.

As for not checking the signatures of the CRLs: sounds like there would be an implicit contract that server is expected to validate signatures as needed for all of its workloads. Expecting clients not to validate signatures sounds suspect to me... but if that's the intention here, would recommend documenting it.

We discussed possibly skipping signature verification on CRLs during a past SIG-Spec call, but I don't see that the language actually made it into the text. The justification was that data delivered over the Workload API is trusted. To @justinburke's point, while we trust the the control plane has delivered the correct data, we don't get to assert the provenance of the list without validating it.

It is unclear to me exactly which parties are allowed to create/publish CRLs. Traditionally, it is only the authority that the CRL represents. Is there a use case that might require a site administrator to internally distribute a CRL on behalf of a federated authority without having actually received a CRL from them?

Does anyone know how to create a X509-SVID certificate using a CA/B Forum EV Certificate? I don't believe that CA/B Forum members support SAN URI fields, just verified DNS & IP address SAN entries.

Some specs have requirements on certain choices (e.g. extended key usage bits on X509-SVID) without the accompanying justification. This can cause confusion and extra work as readers seek out answers from the community (or worse, give up on evaluating).

We should audit the specs and add embellishment, where appropriate, to increase understanding and bring the reader along on the journey of why the specs are shaped the way they are.

2021 H2 SSC Election

This is the official tracking issue for the 2021 H2 SSC election. The timeline for this election is as follows:

• Oct 6, 2021: Nominations open
• Oct 20, 2021: Nominations close
• Oct 28, 2021: Polls open
• Nov 4, 2021: Polls close
• Nov 9, 2021: Results announced

How to Participate

All SPIFFE community members and contributors demonstrating active engagement in the project(s) are invited to both nominate and vote on new SSC members. The eligible participants are listed below. For more information about the definition of active engagement, and how this list was compiled, please see the Election and Term Mechanics section of the SSC Charter.

All eligible participants must have an email address publicly associated with their GitHub account. You may be omitted from the participant list if we're unable to determine your email address.

If you feel that you are an active SPIFFE community member or contributor but are not included in the list below, please contact the SSC at [email protected] and we will be happy to include you.

Nominating an SSC Member

Eligible participants may nominate up to two candidates per available SSC seat during the nomination period. They may nominate themselves or someone else.

If you'd like to nominate an SSC member for this election cycle, please follow these steps:

1. Verify that your GitHub handle is included in the list of eligible participants below
2. Verify that, in your best judgement, the nominee meets the criteria specified in the Nominee Qulifications section of the SSC Charter
3. Fork this repository
4. Copy ssc/elections/NOMINEE_TEMPLATE.md into the appropriate subdirectory, and name it after the person to be nominated
   1. For example, from the root directory:

   $ cp ssc/elections/NOMINEE_TEMPLATE.md ssc/elections/2021H2/JANE_DOE.md
   

5. Fill in all fields in the copied template as completely as possible
6. Open a GitHub Pull Request back to this repository to add the new nominee
   1. Create a new commit with the name of the election and nominee
      1. For example, Nominate Jane Doe for 2021H2 SSC Election
   2. Open a new GitHub Pull Request against https://github.com/spiffe/spiffe
      1. Give the Pull Request the same name as the commit it includes
7. An SSC member will review the nomination and merge it when ready

Electing an SSC Member

The SPIFFE project uses the CIVS tool to conduct its elections. Please register your email address with the tool before the polls open if you intend on voting.

Once the polls open, all eligible participants will receive an email from this tool. The email includes a link which can be used to vote. Do not share this link, as it is private.

If you are in the list of eligible participants and you don't receive a link on the day the polls open, please contact the SSC at [email protected].

Each participant casts a single ranked vote. If more than one SSC seat is available, the top N nominees will be selected.

Eligible Participants

This section lists everyone eligible to participate in this SSC election cycle. If you believe you were omitted in error, please contact the SSC at [email protected].

• Tyler Julian (@APTy)
• Andres Gomez-Coronel (@Andres-GC)
• Ian Haken (@JackOfMostTrades)
• Jonathan Oddy (@JonathanO)
• Jonathan Perry (@Jonpez2)
• Josh Van Leeuwen (@JoshVanL)
• Marcos Yacob (@MarcosDY)
• Rei Shimizu (@Shikugawa)
• Matteus Silva (@SilvaMatteus)
• Aidan (@SirNexus)
• Sunil R (@ai2017)
• Alexander Viktorov (@alexviktorov)
• Lars Lehtonen (@alrs)
• Agustín Martínez Fayó (@amartinezfayo)
• Andrew Moore (@amoore877)
• Anjali Telang (@anjaltelang)
• Andres Vega (@anvega)
• Andrew Harding (@azdagron)
• Brian Barnes (@bbarnes52)
• David Arnold (@blaggacao)
• Ben Leggett (@bleggett)
• Brad Blackard (@bradbl)
• Brian J Martin (@bri365)
• Caley Goff (@caleygoff-invitae)
• Chris Aniszczyk (@caniszczyk)
• Carl Bourne (@carlskii)
• Cole Kennedy (@colek42)
• Craig Box (@craigbox)
• Derek Edwards (@derekbedwards)
• Batuhan Apaydın (@developer-guy)
• Daniel Feldman (@dfeldman)
• (@dragcp)
• Ed Warnicke (@edwarnicke)
• Eric Lee (@elee)
• Eli Nesterov (@elinesterov)
• Erik Godding Boye (@erikgb)
• Eugene Weiss (@esweiss)
• Evan Gilman (@evan2645)
• Faisal Memon (@faisal-memon)
• Georgi Lozev (@georgi-lozev)
• Glaucimar Aguiar (@glaucimar)
• Chen Xi (@hixichen)
• Tomoya Usami (@hiyosi)
• Hugues de Valon (@hug-dev)
• (@inajob)
• Irbe Krumina (@irbekrm)
• John Kevlin (@jkevlin)
• Justin Burke (@justinburke)
• Kris Gambirazzi (@kgtw)
• Jeremy Krach (@krockpot)
• Mariano Kunzi (@kunzimariano)
• Dórian C. Langbeck (@langbeck)
• Maik Riechert (@letmaik)
• Luis Santiago Re (@lsantire)
• Luciano Iván Zablocki (@lucianozablocki)
• Brandon Lum (@lumjjb)
• Marco Franssen (@marcofranssen)
• Marcos Yedro (@marcosy)
• (@mayur040993)
• Mauricio Vásquez (@mauriciovasquezbernal)
• Max Lambrecht (@maxlambrecht)
• (@mazamats)
• Mat Byczkowski (@mbyczkowski)
• Maximiliano Churichi (@mchurichi)
• Michael Shen (@mjlshen)
• Mariusz Sabath (@mrsabath)
• Michael Weissbacher (@mweissbacher)
• Nestor (@narg95)
• Nick Lehmann (@nick-lehmann)
• Rahul Jadhav (@nyrahul)
• Prasad Borole (@prasadborole1)
• Prashant Varanasi (@prashantv)
• Richard Featherstone (@ricfeatherstone)
• Raphael Campos (@rscampos)
• Ryan Turner (@rturner3)
• Ryuma Yoshida (@ryysud)
• Andrew Block (@sabre1041)
• Sachin Kumar Singh (@sachinkumarsingh092)
• Steve Anderson (@sanderson042)
• Sanjay Pujare (@sanjaypujare)
• Sorin Dumitru (@sorindumitru)
• Spike Curtis (@spikecurtis)
• Sushil Prasad (@sushil-prasad)
• Thiago dos Santos Leite (@thiagosantosleite)
• Umair Khan (@umairmkhan)
• Vlad Botez (@vbotez)
• Vijay Mateti (@vijaymateti)
• Marc Yang (@yangmarcyang)
• Holger Freyther (@zecke)
• Zachary M. Train (@zmt)

Eligible Participants with Missing Email Addresses

The following participants would normally be eligible to participate, but do not have email addresses published on their GitHub account. Please publish an email address and contact the SSC at [email protected] to be added to the list of eligible participants.

• @GuoqiangZ
• @adobley
• @alchen99
• @alwaysastudent
• @bjencks
• @bt-nia
• @caleblloyd
• @dana-harrington
• @florentinvintila
• @gcohler
• @loveyana
• @mamy-CS
• @marco-developer
• @phalli
• @srwaggon
• @tahirali-endurance
• @timmyyuan
• @webmutation
• @xinlaini
• @zeldigas

Hello friends.

Looking into https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#44-extended-key-usage we have the following sentences.

When included, fields id-kp-serverAuth and id-kp-clientAuth MUST be set.

while if we check the reference https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#appendix-a-x509-field-reference we have

Extended Key Usage	id-kp-serverAuth	This field may be set for either leaf or signing certificates.
Extended Key Usage	id-kp-clientAuth	This field may be set for either leaf or signing certificates.

Does anyone recall the reasoning behind both id-kp-serverAuth and id-kp-clientAuth being present?

Do you see as a viable use case to have only TLS Web Client Authentication in case you don't plan to use it for TLS Web Server Authentication ?

Note: This issue is NOT what PR #27 is about. This issue is further clarifying things.

The draft spec currently says: “They MUST NOT set keyEncipherment or keyAgreement. This helps ensure that they cannot be used for authentication purposes.”

However,

1. The digitalSignature key usage has the same issues as keyEncipherment or keyAgreement with respect to allowing additional non-CA usage of a CA certificate.
2. The check that "CA = true" isn't set in the basic constraint extension during leaf validation already prevents SVID signing certificates from being used as leaf certificates.

I propose that the text “They MUST NOT set keyEncipherment or keyAgreement" be removed. This helps ensure that they cannot be used for authentication purposes.” be removed.

Failing that, digitalSignature should be added to the list, for consistency's sake.

Hello! I am looking to secure production workloads with SPIFFE SVID. I am also looking at how workloads can be tied to decentralized identity (DID from DIF - https://identity.foundation).

Like to know if there are any differences between SPIFFE vs DID and if there are overlaps between both and if there are ways for both to interoperate?

This might not be the best venue to post this question so my apologies in advance.

https://security.stackexchange.com/questions/256175/svid-vs-did-secure-production-identity-framework-for-everyone-spiffe-verifiab

2022 H1 SSC Election

This is the official tracking issue for the 2022 H1 SSC election.

One SSC seat is available. We thank @evan2645 for his time, commitment, and passion on the committee. He will continue to serve SPIFFE as both a SPIFFE and SPIRE Maintainer.

The timeline for this election is as follows:

• April 6th, 2022: Nominations open
• April 13th, 2022: Nominations close
• April 20th, 2022: Polls open
• April 27th, 2022: Polls close. Results announced within days.
• May 4th, 2022: Term Start

How to Participate

All SPIFFE community members and contributors demonstrating active engagement in the project(s) are invited to both nominate and vote on new SSC members. The eligible participants are listed below. For more information about the definition of active engagement, and how this list was compiled, please see the Election and Term Mechanics section of the SSC Charter.

All eligible participants MUST have an email address publicly associated with their GitHub account. You may be omitted from the participant list if we're unable to determine your email address.

If you feel that you are an active SPIFFE community member or contributor but are not included in the list below, please contact the SSC at [email protected] and we will be happy to include you.

Nominating an SSC Member

Eligible participants may nominate up to two candidates per available SSC seat during the nomination period. They may nominate themselves or someone else.

If you'd like to nominate an SSC member for this election cycle, please follow these steps:

1. Verify that your GitHub handle is included in the list of eligible participants below
2. Verify that, in your best judgement, the nominee meets the criteria specified in the Nominee Qualifications section of the SSC Charter
3. Fork this repository
4. Copy ssc/elections/NOMINEE_TEMPLATE.md into the appropriate subdirectory, and name it after the person to be nominated
   1. For example, from the root directory:

   $ cp ssc/elections/NOMINEE_TEMPLATE.md ssc/elections/2022H1/JANE_DOE.md
   

5. Fill in all fields in the copied template as completely as possible
6. Open a GitHub Pull Request back to this repository to add the new nominee
   1. Create a new commit with the name of the election and nominee
      1. For example, Nominate Jane Doe for 2022H1 SSC Election
   2. Open a new GitHub Pull Request against https://github.com/spiffe/spiffe
      1. Give the Pull Request the same name as the commit it includes
7. An SSC member will review the nomination and merge it when ready

Electing an SSC Member

The SPIFFE project uses the CIVS tool to conduct its elections. Once the polls open, all eligible participants will receive an email from this tool. The email includes a link which can be used to vote. Do not share this link, as it is private.

If you are in the list of eligible participants, and you don't receive a link on the day the polls open, please contact the SSC at [email protected].

Each participant casts a single ranked vote.

Eligible Participants

This section lists everyone eligible to participate in this SSC election cycle. If you believe you were omitted in error, please contact the SSC at [email protected].

• José Benardi de Souza Nunes (@Benardi) [email protected]
• Furkan Türkal (@Dentrax) [email protected]
• Jayasheel (@Jayasheel) [email protected]
• Josh Van Leeuwen (@JoshVanL) [email protected]
• Kaizhe Huang (@Kaizhe) [email protected]
• Marcos Yacob (@MarcosDY) [email protected]
• Авраменко Михаил (@Mixaster995) [email protected]
• Matteus Silva (@SilvaMatteus) [email protected]
• Aidan (@SirNexus) [email protected]
• Victor Vieira Barros Lea da Silveira (@Victorblsilveira) [email protected]
• Anas EL BARKANI (@aelbarkani) [email protected]
• Sunil R (@ai2017) [email protected]
• Alexander Viktorov (@alexviktorov) [email protected]
• Ariel Roque (@arielroque) [email protected]
• Andrew Harding (@azdagron) [email protected]
• Wolodja Wentland (@BABILEN) [email protected]
• David Arnold (@blaggacao) [email protected]
• Brian J Martin (@bri365) [email protected]
• Carl Bourne (@carlskii) [email protected]
• Cole Kennedy (@colek42) [email protected]
• David Garcia (@davidgarc) [email protected]
• Batuhan Apaydın (@developer-guy) [email protected]
• (@dfeldman) [email protected]
• André Lima (@drelima82) [email protected]
• Ed Warnicke (@edwarnicke) [email protected]
• (@esweiss) [email protected]
• Evan Gilman (@evan2645) [email protected]
• Frederick F. Kautz IV (@fkautz) [email protected]
• Tomoya Usami (@hiyosi) [email protected]
• Irbe Krumina (@irbekrm) [email protected]
• Juliano Fantozzi (@jufantozzi) [email protected]
• Mariano Kunzi (@kunzimariano) [email protected]
• Maik Riechert (@letmaik) [email protected]
• Brandon Lum (@lumjjb) [email protected]
• Marcos Yedro (@marcosy) [email protected]
• Mauricio Vásquez (@mauriciovasquezbernal) [email protected]
• Max Lambrecht (@maxlambrecht) [email protected]
• Mayur Rastogi (@mayur040993) [email protected]
• Maximiliano Churichi (@mchurichi) [email protected]
• Mikhail Swift (@mikhailswift) [email protected]
• Michael Shen (@mjlshen) [email protected]
• Mariusz Sabath (@mrsabath) [email protected]
• Nathan Aw (@nathanawmk) [email protected]
• Nick Lehmann (@nick-lehmann) [email protected]
• Andrew Block (@sabre1041) [email protected]
• Sachin Kumar Singh (@sachinkumarsingh092) [email protected]
• Sharpy (@shaaaarpy) [email protected]
• Saylor Berman (@sjberman) [email protected]
• Brandon Mitchell (@sudo-bmitch) [email protected]
• Thiago dos Santos Leite (@thiagosantosleite) [email protected]
• Zachary M. Train (@zmt) [email protected]

Eligible Participants with Missing Email Addresses

The following participants would normally be eligible to participate, but do not have email addresses published on their GitHub account. Please publish an email address and contact the SSC at [email protected] to be added to the list of eligible participants.
Those marked with * have previously participated in an election cycle by privately providing an email address to the SSC. Unless told otherwise, these emails will be re-used.

• @0123hoang
• @Andres-GC *
• @GerardoGR
• @JackOfMostTrades *
• @JonathanO *
• @ajessup *
• @alwaysastudent
• @amartinezfayo *
• @amoore877 *
• @anjaltelang *
• @anvega *
• @appian-ashugarts
• @bbarnes52 *
• @bjencks
• @blairdrummond
• @bleggett *
• @boyanguber
• @caleygoff-invitae *
• @dana-harrington
• @dlorenc *
• @dragcp *
• @dzhou3
• @faisal-memon *
• @florentinvintila
• @gadinaor-r7
• @georgi-lozev *
• @glaucimar *
• @hampus77
• @hellerda
• @inajob *
• @jonringer
• @justinburke *
• @kfox1111 *
• @loveyana *
• @lucianozablocki *
• @mamy-CS
• @marcofranssen *
• @marques-ma *
• @mweissbacher *
• @navarrothiago *
• @noxora *
• @pawsey-kbuckley
• @phalli
• @ricfeatherstone *
• @rscampos *
• @rturner3 *
• @ryysud *
• @sanderson042 *
• @sanjaypujare *
• @sorindumitru *
• @spikecurtis *
• @sushil-prasad *
• @szvincze
• @tahirali-endurance
• @timmyyuan
• @tjamir
• @umairmkhan *
• @vijaymateti *
• @wibarre
• @y3gj3ib3tjr
• @yangmarcyang *
• @yueqiao1

The GOVERNANCE.md was written a long time ago. Almost 3 years to be precise. Now is a good time as any to make sure the statute still makes sense and determine if there are updates to be made. Particularly considering that the projects are now at a CNCF incubation level.

I want to propose a discussion for the upcoming TSC meeting to go over the purpose and responsibilities of the TSC, make sure those make sense as described, and evaluate if there is any rift between what was originally conceived and the evolving state of the projects. There are probably other things too. The objective is to ensure the charter is representative of known and understood needs, current and future.

I have heard of a strong desire to see the TSC revitalized from @suniljames, @evan2645, and @y2bishop2y.

Leading adopters among end-users, ecosystem integrators, and academia have expressed interest in seeing larger representation in either the TSC directly or in the form of a community advisory board. The list of advocates includes @elee, @fkautz, @wfu8, and @JustinCappos.

Hi SPIFFE team,
I'm new here, so please forgive me if this has an obvious answer.

My question is about the following paragraph from the SVID standard:

Trust domains are nominally self-registered, unlike public DNS there is no delegating authority that acts to assert and register a base domain to an actual legal real-world entity, or assert that legal entity has fair and due rights to any particular trust domain.

In case SPIFFE takes off and becomes a widely adopted standard, Trust Domain name collision are bound to happen.

• How can I enable communication between my trust domain and a couple of trust domains who happen to use the same name?

• Can I rename them when I configure the federation? How would we make sure this doesn't cause confusion?

Thanks.

The contributing suggests I need to sign the CLA (which I believe my company has already signed), but there is no CI check for this.

As there is an intention of submitting to CNCF, would it be possible to switch from CLA to DCO, which CNCF also accepts, as it is a much lower bar to contribution?

In particular, pathLenConstraint set to 0 would mean that the SVID signing cert is valid for signing leaf certs only and can't be used to cross-sign other SVID signing certs (for other trust domains). This seems like a valid restriction to want to place on a SVID signing certificate so either (a) pathLenConstraint should be allowed, or (b) the spec should explain why path length constraints aren't allowed.

The draft spec says "the SPIFFE ID of the signing certificate MUST be equal to the leaf certificate’s SPIFFE trust domain". However it also says "A signing certificate MAY be used to issue further signing certificates in the same or different trust domains."

Let's consider two trust domains, spiffe://a and spiffe://b. spiffe://b wishes to issue a certificate for a service spiffe://a/some-service, but it can't because it's SPIFFE ID isn't the same trust domain. However, it seems like it can easily circumvent that restriction by first issuing its own "spiffe://a" sub-CA certificate and then issuing the spiffe://a/some-service certificate from that sub-CA certificate.

Either the specification should clarify things to explain why this isn't possible, or why it is intentionally allowed and why it is not dangerous. Or, if this scenerio isn't intentionally allowed then maybe some additional requirements on validation are required.

The spec at https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md does not include the iss claim and in general the way to advertise bundles seems different from OIDC discovery endpoints.

On the other side, SPIRE seems to implement OIDC and includes iss. See https://spiffe.io/docs/latest/keyless/oidc-federation-aws/.

What am I missing?

If we are going to use the spiffe URI scheme for SPIFFE IDs, we should register it with IANA

The current SVID-X509 spec document here

https://github.com/spiffe/spiffe/blob/1e028a071ff517afe9bc21233ec935a91a4f321d/standards/X509-SVID.md#32-signing-certificates

Says

A signing certificate is itself an SVID. The SPIFFE ID of a signing certificate MUST NOT have a path component, and MUST reside in the trust domain of any leaf SVIDs it issues. A signing certificate MAY be used to issue further signing certificates in the same or different trust domains.

I interpreted that to mean that any signing certificate in the chain MUST have a URI SAN with matching spiffe://<trust domain> with no path.

Yet running the reference generator/verifying in svid-test generates both Root and Intermediate CAs in t "good" cases that verify correctly with no URI SAN at all and with a DN that is some arbitrary string, e.g. Issuer: C=US, O=test7.acme.com, CN=RootCA.

Am I misunderstanding the spec or is svid-test not implementing the spec correctly?

Restore examples or cut line from Readme?

'spiffe-examples: Examples and demonstrations.'

The specification should explain why only one SPIFFE ID is allowed per certificate.

The specification should indicate whether a validator is required to reject a leaf certificate with multiple SPIFFE IDs, or otherwise what should happen during validation when multiple SPIFFE IDs are present in a leaf certificate.

The specification should indicate whether a validator is required to reject a signing certificate with multiple SPIFFE IDs, or otherwise what should happen during validation when multiple SPIFFE IDs are present in a signing certificate.

This repo is signed up as part of the KubeCon Security Slam. I'm bringing to your attention the checklist from the official CLOMonitor page for SPIFFE -- it refreshes every hour, so it should be up-to-date.

CLOMonitor report

Summary

Repository: spiffe
URL: https://github.com/spiffe/spiffe
Checks sets: COMMUNITY + CODE
Score: 57

Checks passed per category

Checks

Documentation [90%]

• Adopters (docs)
• Changelog (docs)
• Code of conduct (docs)
• Contributing (docs)
• Governance (docs)
• Maintainers (docs)
• Readme (docs)
• Roadmap (docs)
• Website (docs)

License [75%]

• Apache-2.0 (docs)
• Approved license (docs)
• License scanning (docs)

Best Practices [15%]

• Analytics (docs)
• Artifact Hub badge (docs)
• Contributor License Agreement (docs) EXEMPT
• Community meeting (docs)
• Developer Certificate of Origin (docs)
• Github discussions (docs)
• OpenSSF badge (docs)
• Recent release (docs)
• Slack precense (docs)

Security [45%]

• Binary artifacts (docs)
• Code review (docs)
• Dangerous workflow (docs)
• Dependency update tool (docs)
• Maintained (docs)
• Software bill of materials (SBOM) (docs)
• Security policy (docs)
• Signed releases (docs)
• Token permissions (docs)

Legal [0%]

• Trademark disclaimer (docs)

For more information about the checks sets available and how each of the checks work, please see the CLOMonitor's documentation.

2021 H1 SSC Election

This is the official tracking issue for the 2021 H1 SSC election. The timeline for this election is as follows:

• April 14, 2021: Nominations open
• April 21, 2021: Nominations close
• April 27, 2021: Polls open
• May 4, 2021: Polls close
• May 5, 2021: Results announced

How to Participate

All SPIFFE community members and contributors demonstrating active engagement in the project(s) are invited to both nominate and vote on new SSC members. The eligible participants are listed below. For more information about the definition of active engagement, and how this list was compiled, please see the Election and Term Mechanics section of the SSC Charter.

All eligible participants must have an email address publicly associated with their GitHub account. You may be omitted from the participant list if we're unable to determine your email address.

If you feel that you are an active SPIFFE community member or contributor but are not included in the list below, please contact the SSC at [email protected] and we will be happy to include you.

Nominating an SSC Member

Eligible participants may nominate up to two candidates per available SSC seat during the nomination period. They may nominate themselves or someone else.

If you'd like to nominate an SSC member for this election cycle, please follow these steps:

1. Verify that your GitHub handle is included in the list of eligible participants below
2. Verify that, in your best judgement, the nominee meets the criteria specified in the Nominee Qulifications section of the SSC Charter
3. Fork this repository
4. Copy ssc/elections/NOMINEE_TEMPLATE.md into the appropriate subdirectory, and name it after the person to be nominated
   1. For example, from the root directory:

   $ cp ssc/elections/NOMINEE_TEMPLATE.md ssc/elections/2021H1/JANE_DOE.md
   

5. Fill in all fields in the copied template as completely as possible
6. Open a GitHub Pull Request back to this repository to add the new nominee
   1. Create a new commit with the name of the election and nominee
      1. For example, Nominate Jane Doe for 2021H1 SSC Election
   2. Open a new GitHub Pull Request against https://github.com/spiffe/spiffe
      1. Give the Pull Request the same name as the commit it includes
7. An SSC member will review the nomination and merge it when ready

Electing an SSC Member

The SPIFFE project uses the CIVS tool to conduct its elections. Once the polls open, all eligible participants will receive an email from this tool. The email includes a link which can be used to vote. Do not share this link, as it is private.

If you are in the list of eligible participants, and you don't receive a link on the day the polls open, please contact the SSC at [email protected].

Each participant casts a single ranked vote. If more than one SSC seat is available, the top N nominees will be selected.

Eligible Participants

This section lists everyone eligible to participate in this SSC election cycle. If you believe you were omitted in error, please contact the SSC at [email protected].

• Tyler Julian (@APTy)
• Andres Gomez Coronel (@Andres-GC)
• Ian Haken (@JackOfMostTrades)
• Jonathan Oddy (@JonathanO)
• Jonathan Perry (@Jonpez2)
• Josh Van Leeuwen (@JoshVanL)
• Marcos Yacob (@MarcosDY)
• Rd (@Ruide)
• Rei Shimizu (@Shikugawa)
• Matteus Silva (@SilvaMatteus)
• Aidan (@SirNexus)
• Aidan Obley (@adobley)
• Sunil Ravipati (@ai2017)
• Andrew Jessup (@ajessup)
• Lars Lehtonen (@alrs)
• Agustin Martinez Fayo (@amartinezfayo)
• Andrew Moore (@amoore877)
• Andres Vega (@anvega)
• Ben Burry (@benburry)
• Ben Leggett (@bleggett)
• Brad Blackard (@bradbl)
• Brian Martin (@bri365)
• Craig Box (@craigbox)
• Antoine Grondin (@aybabtme)
• Andrew Harding (@azdagron)
• David Arnold (@blaggacao)
• Caley Goff (@caleygoff-invitae)
• Chris Aniszczyk (@caniszczyk)
• Doron Chen (@cdoron)
• Cole Kennedy (@colek42)
• Christine Tsou (@cyt3ea)
• Geoff (@devgig)
• Dan Feldman (@dfeldman)
• Dongryeol Shim (@dr-shim)
• (@dragcp)
• Dave Langhorst (@drrt)
• Faisal Memon (@faisal-memon)
• Frederick Kautz (@fkautz)
• Ed Warnicke (@edwarnicke)
• Eric Lee (@elee)
• Georgi Lozev (@georgi-lozev)
• Eli Nesterov (@elinesterov)
• Glaucimar Aguiar (@glaucimar)
• Erik Godding Boye (@erikgb)
• Eugene Weiss (@esweiss)
• Evan Gilman (@evan2645)
• Galo Gimenez (@galo)
• Chen Xi (@hixichen)
• Tomoya Usami (@hiyosi)
• Hugues de Valon (@hug-dev)
• Ian Ferguson (@ianferguson)
• inajob (@inajob)
• John Kevlin (@jkevlin)
• Joe Williams (@joewilliams)
• Justin Burke (@justinburke)
• Kris Gambirazzi (@kgtw)
• Kirutthika (@kirutthika)
• Jeremy Krach (@krockpot)
• Mariano Kunzu (@kunzimariano)
• Martin Capello (@martincapello)
• (@mayur040993)
• Dórian C. Langbeck (@langbeck)
• Luis Santiago Re (@lsantire)
• Luciano (@lucianozablocki)
• Brandon Lum (@lumjjb)
• Marcos Yedro (@marcosy)
• Mauricio Vásquez (@mauriciovasquezbernal)
• Max Lambrecht (@maxlambrecht)
• (@mazamats)
• Mat Byczkowski (@mbyczkowski)
• Maximiliano Churichi (@mchurichi)
• Michael Shen (@mjlshen)
• Mariusz Sabath (@mrsabath)
• Michael Weissbacher (@mweissbacher)
• Nestor (@narg95)
• Rahul Jadhav (@nyrahul)
• (@odidev)
• Prabhu Subramanian (@prabhu)
• Prasad Borole (@prasadborole1)
• Prashant Varanasi (@prashantv)
• Prateek Agarwal (@prat0318)
• Ryan Turner (@rturner3)
• Ryan Nelson (@ryancnelson)
• Ryuma Yoshida (@ryysud)
• Andrew Block (@sabre1041)
• Sachin Kumar Singh (@sachinkumarsingh092)
• Steve Anderson (@sanderson042)
• Ken Mohr (@sigtrap)
• Kyle Anderson (@solarkennedy)
• Sorin Dumitru (@sorindumitru)
• Spike Curtis (@spikecurtis)
• Samuel Waggoner (@srwaggon)
• Umair Khan (@umairmkhan)
• Vlad Botez (@vbotez)
• Vijay Mateti (@vijaymateti)
• Marc Yang (@yangmarcyang)
• Yuri Shkuro (@yurishkuro)
• Holger Freyther (@zecke)

Eligible Participants with Missing Email Addresses

The following participants would normally be eligible to participate, but do not have email addresses published on their GitHub account. Please publish an email address and contact the SSC at [email protected] to be added to the list of eligible participants.

• @AdamKorcz
• @GuoqiangZ
• @PriyaKatkade
• @RichardHCL
• @Taranasaur
• @alchen99
• @bt-nia
• @caleblloyd
• @derekbedwards
• @gcohler
• @janssk1
• @jdtw
• @mcpherrinm
• @paulhowardarm
• @scotte
• @webmutation
• @xinlaini
• @yvanin
• @zeldigas

It's a good practice—if not a requirement considered by some—to officially register a URI scheme, see also BCP35 for guidance.

Since SPIFFE claims the spiffe URI scheme, we should kick off the IANA registration for this scheme.

Need to create the equivalent of the https://github.com/spiffe/go-spiffe library for Java.

In order to retrieve the SAN URI from an SVID, it is necessary to parse it out with an ASN.1 parser in Java. Having the java-spiffe library can hide all this complexity from a user.

From the SPIFFE Workload Endpoint specification, section 6, Error Codes:

In the event that the SPIFFE Workload Endpoint implementation is running but unavailable, for instance if it is still initializing or it is performing load shedding, clients will receive the gRPC status code "Unavailable". Clients receiving this code OR clients which are unable to reach the SPIFFE Workload Endpoint MAY retry with a backoff.

This behavior is articulated from the client's perspective, but no explicit requirement is placed on the server implementation in this statement. Consider rewording this section to use standard MUST terminology for the server implementation to make the semantics around returning the Unavailable gRPC status code a more explicit requirement for the server implementation.

• 1. Top-level doc explaining what SPIFFE is. This document should link to all the following
• 1. Core SPIFFE RFC
• 1. X.509 SVID RFC
• 1. SPIFFE Community Information
• 1. svid-test

Section 4.2.2 of the SPIFFE Trust Domain and Bundle specification has the requirements for the use parameter in the SPIFFE Bundle Format.
While implementing a SPIFFE Bundle parser, it was not completely clear how this parameter should be treated in conformance with the standard.
In particular, the specification says:

The use parameter MUST be set.

and also:

Clients encountering unknown use values MUST ignore the entire JWK element.

Which does not provide clarity for the case where there is a document that has some keys with valid SPIFFE values for the use parameter and some with no use specified.
It would be good if it is clear from the standard perspective how such case should be treated by software that produces/consumes documents using the SPIFFE Bundle Format.

Add an ADOPTERS file that lists people who are using SPIFFE in interesting ways.

Cargo cult away here: https://github.com/linkerd/linkerd/blob/master/ADOPTERS.md

This is a requirement of CNCF Graduation down the line but it's better to get this done earlier imho, you never know who will come out of the wood work :)

Hello SPIFFE team,

I have a use case which would benefit from using query strings in SPIFFE IDs, a use currently forbidden by The SPIFFE Identity and Verifiable Identity Document standard. ("Valid SPIFFE IDs ... MUST NOT include a query ... component.")

Our services have [at least] two attributes

• application id (app) - Used when services have multiple entry points or execution modes, such as web application or batch processing. Also used when the same service runs with a variety of different configurations such as a log processor ingesting from two different streams.
• run time environment (env) - Used to indicate production vs staging. Production takes customer traffic, staging does not.

Both app and env are used to make authorization decisions: staging services can only write to other staging services; different applications should be able to read only from their corresponding input source.

(A similar example is given in the 2.2 Path section using service account and namespace.)

Adding app and env to URI path implies a hierarchical relationship when there is none:

• Do applications live inside an environment, for example
  spiffe://k8s-west.example.com/service/foo/env/staging/app/streaming
• or, is environment a sub-component of an application?
  spiffe://k8s-west.example.com/service/foo/app/streaming/env/staging

Neither is strictly true, app and env are orthogonal concepts. (The problem is multiplied when adding a third attribute.)

To highlight the key value nature of the data and we could use =, part of "sub-delims" reserved by RFC 3986, instead of /:
spiffe://k8s-west.example.com/service/foo/env=staging/app=streaming
spiffe://k8s-west.example.com/service/foo/app=streaming/env=staging

We can of course build application logic that would treat these two URIs as identical, however the naive approach would treat them differently and most developers are used to treating paths as hierarchical, regardless of separator.

On the other hand, because most web application developers and url parsing libraries are already familiar with query string as an unordered maps. It is more clear that
spiffe://k8s-west.example.com/service/foo?env=staging&app=streaming
is identical to
spiffe://k8s-west.example.com/service/foo?app=streaming&env=staging.

How would you recommend to handle this situation?
What are your reasons for excluding query component from SPIFFE URIs? (Perhaps trying to add metadata to identity is a mistake in the first place.)
Are you open to expanding the standard?

Thank you.

Hello!

The project we're working on, Parsec, is planning on using some sort of tokens for identifying and authenticating clients, and JWT seemed the best choice for this, aiming towards having a SPIFFE'ish environment.

Reading about the issues created by the complexity of the JOSE specs and the vulnerabilities in some JWT libraries means that your JWT-SVID restriction on JWT sounds quite appealing from a security perspective. However, the document mentions that

This document specifies an experimental identity document standard for the internet community, and requests discussion and suggestions for improvements. It is a work in progress.

How stable can that spec be considered? There seem to have been relatively few changes made since its inception.

Hi I am the owner of this project https://github.com/ServiceComb/go-chassis
we are about to integrate with Istio auth, but I found this solution here, so do you have a example about how spiffle work with Istio, that will be great for us to consider about how to integrate with Istio

This new spiffe/spiffe repository is great, but it would be even greater if it had a SPIFFE logo at the top.

Hello Awsome Spiffes!!
As a biggner when I looked over the name of SPIFFE, it looks bit strange to me.
SPIFFE: Secure Production Identity Framework For Everyone

1. Firstly is it a framework/specification/protocol?
2. If it's a framework, does it only applicable to Production? Otherwise what does Production mean?
3. Why "Everyone" is included in name, it's upto those who uses it. There is no protocol/framework (ex: FTP, HTTP etc.) which claims it's for for everyone.
4. Does the name choosen deliberately?

Can someone among who came-up with this name, share there thoughts(/justify)?

Service spiffe://example.com/foo provides services to spiffe://example.com/bar and others through HTTPS; i.e. it is a web server of some form. Other services will look up how to contact spiffe://example.com/foo, which is likely to be an HTTPS connection to some hostname, e.g. https://foo.example.com/.

When clients connect to https://foo.example.com/ to access spiffe://example.com/foo, what should they put in the SNI Server Name Indication (SNI) extension? AFAICT the client cannot put spiffe://example.com/foo because the SNI extension only defines a name form for (DNS) hostnames, so presumably the client must put "foo.example.com" there or avoid SNI completely. If it avoids SNI completely then we lose the ability to have multiple services listening on a single IP, so that seems out. Thus, it seems like the client must put "foo.example.com" in the SNI extension of the TLS client hello.

How, then, should the X.509 certificate for spiffe://example.com/foo include a dNSName subjectAltName entry for foo.example.com in addition to the uniformResourceIdentifier entry for spiffe://example.com/foo?

Or, do we need to define a new SNI entry type or a new SNI-like extension that lets us put the SPIFFE ID in the client hello? See the mailing list thread [TLS] Accepting that other SNI name types will never work. about the difficulties in doing that.

We have clear integration examples for AWS-based infrastructure, now we need a similar level of detail around the Kubernetes integration use case.

• Meet with SIG-k8s on 8/18 to go through worked example
• Update diagrams and flows to support the k8s use case
• Present findings at Kubernetes SIG-Auth meetup on 8/23

Summary

Would it be possible to allow a client process to call the Workload API solely for the purposes of verifying a signed SVID and obtaining the SPIFFE ID string?

Detail

It's currently only possible for a client to call the Workload API if that client is itself a registered workload. However, it might be a valid use case for a client process to be able to call the API solely for the purpose of verifying a SVID and extracting the SPIFFE ID string.

The use case is as follows. Suppose we have a storage service that partitions stored assets according to a name-spacing scheme. And suppose that we have a SPIFFE-based system where we want to use the SPIFFE IDs as the name-spacing token within that storage service. The service would allow, say, a calling process with an id of spiffe://my.system/application1 to store assets in a separate area from spiffe://my.system/application2. This could be achieved by having the client processes call the service using a signed SVID for authentication. They obtain that SVID using the Workload API in the normal way. But the storage service then needs to be able to verify the SVID and extract the SPIFFE ID in order to use it for name-spacing. If the storage itself is not a SPIFFE workload, then it currently can't do that.

If the storage service could call just the verify operation on the Workload API, and get the SPIFFE ID back, then this use case could be enabled.

The X509-SVID specification mandates that a subject alternative name (SAN) is provided and makes no mention of the subject DN.

RFC 5280, Section 4.2.1.6, §3 mandates that if the subject DN is empty, the SAN must be marked as critical (See https://tools.ietf.org/html/rfc5280#section-4.2.1.6 for reference).

Not marking the SAN as critical leads validation errors in conforming implementations, for instance in Java with the default Sun* providers or BouncyCastle.

Please clarify:

• whether the subject DN is optional
• that if the subject DN is not set, the SAN must be marked as critical

There appears to be disagreement between the JWT-SVID document and the JSON schema.
In the document:

Registered claims not described in this document, in addition to private claims, MAY be used as implementers see fit.

however the JSON schema expressly forbids this

additionalProperties: false

Is it correct to assume the JSON schema is incorrect/out of date?

openssl/openssl#12753

Since this is the best available leverage and a silent but powerful enabler for wide-spread and hassle-free SPIFFE adoption, I would propose for involved people to support this motion in appropriate ways — I don't dare to suggest one of those ways at this point, but it might be wise to connect those discussions end-to-end through the entire software stack.

The table of content links include a "." in the URL; the GitHub markdown implementation doesn't include the "."

e.g. 5\. [Validation](#5.-validation) should be 5\. [Validation](#5-validation)

Apart from the other issue I filed about how the current test suite is out of date w.r.t. signing cert SANs (#65), can I ask what the rationale is for requiring that signing certificates all must be valid SVIDs right back to the root?

All else equal it makes sense to specify a new format that way, however in practice I know of organisations who would want to root trust in any new system from an existing organisational trust root which may or may not be capable of adding URI SANs to the root and intermediates.

Further, several third-party CAs we need to integrate with don't support generating roots with URI SANs which rules out both implementing SPIFFE and being compatible with them.

I'd be interested to know the rationale for making that a strict requirement in the spec.

As it stands it seems to me like many existing orgs will either need to implement non-conforming validation that allows for external non-compliant trust anchors, or will need to just avoid SPIFFE and come up with essentially the same thing without using the "standard".

I note for example that Envoy doesn't appear to even perform SPIFFE validation (just regular x509 path validation via openssl) despite being the implementation used in Istio which as far as I understand is the main motivating implementation. I don't know if that's just a timing thing but it seems like vendors would be tempted to not implement that validation strictly to maintain compatibility.

Any info here and potentially in the spec text on why this is deemed necessary, or consideration of relaxing it to allow compatibility would be great!

Thanks for pushing this standard forward.

An X.509 SVID MUST contain exactly one URI SAN, and by extension, exactly one SPIFFE ID. SVIDs containing more than one SPIFFE ID introduce challenges related to auditing and authorization logic, and SVIDs containing more than one URI SAN introduce challenges related to SPIFFE ID validation

The only challenge I can see introduced by allowing other non-SPIFFE ID URI SANs would be that auditing and authorizing logic would have to loop over the URI sans and look for multiple spiffe:// URI SANs. If multiple SPIFFE IDs are found the SVID can be rejected.

That seems like a small price to pay when weighed against the reduced interoperability it introduces by commandeering all URI SANs.

As part of becoming a CNCF project, we expect projects to part take in the CII Badging program and ensure you pass: https://bestpractices.coreinfrastructure.org/en

This involves defining some security best practices like a disclosure program etc.

Does spiffe use expiration time or certificates revocation to manage life cycle of x509 certificates? I can't find any document regarding this.
Thanks in advance!

https://github.com/spiffe/spiffe/blob/master/standards/JWT-SVID.md

Section 5.1

JWT-SVIDs MUST be serialized using the JWS Compact Serialization method described in RFC 7515 Section 3.1. Note that this precludes the use of a JWS Unprotected Header, as mandated in the JOSE Header section.

The above section seems to be redundant. A JWT is always compact serialized. When we say a JWT, that it self implies it is compact serialized (with JWS Compact Serialization or JWE Compact Serialization).

Hello Awesome Spiffies!

What is the stand of Spiffe, on using of Security Groups/Firewall rules? Does SPIFFE wanna eliminate these concepts(eventually)? Or SPIFFE complements existence of Firewall rules?

I had checked a talk at KubeCon NA '17. It looks that SPIFFE addressing limitations of Firewall rules. I created this issue, so that community gets aware of SPIFFE stand.

In this paragraph, it is written:

If the scheme is set to unix, then the authority component MUST NOT be set, and the path component MUST be set to the absolute path of the SPIFFE Workload Endpoint Unix Domain Socket (e.g. unix:///path/to/endpoint.sock). The scheme and path components are mandatory, and no other component may be set.

I believe the authority component is introduced with // so if only the path component is required then the example of URI should be: unix:/path/to/endpoint.sock (without the //).

I have questions on base assumptions of The SPIFFE Workload API server/client. Can someone please clarify?

1. Based on the document, the Workload server potentially a Single Point of Failure (SPF), as workload clients always assume that the server is up and running. In a distributed system, if all compute nodes depend on workload server, it has a high blast radius. The document needs to mention whether the server is SPF or not. Can there be any alternatives to avoid SPF? Doc needs to clarify the basic requirements of the server.
2. Workload API document doesn't even recommend about storage requirements of the server. If single storage is been shared among multiple instances, again storage can be SPF. Requirements on storage requirements to be added.
3. SPIFFE expects the entire infrastructure to follow the specification, but in reality, it doesn't work. The document doesn't mention, whether it's possible to run a hybrid approach.