Choose timezone
Your profile timezone:
Token Trust & Traceability WG
→
Europe/Zurich
Description
Token Trust and Traceability WG
https://codimd.web.cern.ch/VhGsEwx8QKiiaNntllACxQ
# TTT 18/8/26
Attending: Luna, Linda, Simon, DaveD, Matt, TomD, Mischa, Maarten
Apologies: DaveK, DavidC
## CHEP Paper, other actions
CHEP paper still a WIP. Deadline 25th September so not stressed yet. TomD been adding to it, should get back to it beginning of September.
EGI2026 presentation in hand (as using DOMA presentation as a base).
## Acceptable Authentication Assurance Policy work
Refer to side doc and our copy of the draft
ML - current draft dominated by IGTF. Need to allow more flexibility, but be aware of risks.
Existing policies from a 25 year old base, involving a closed ecosystem.
World has changed, so should formulate new policy in a forward compatable way.
In area of tokens things have diverged. Tokens are a new thing (for us), need to change wording. IGTF certificates harder to get hold of, but user certs still relevent.
Want to avoid writing a policy that's already obsolete. But still be backward and forward compatable.
MS - question - who was this document (policy) intended for. This document is missing
DCVOTA assurance policy.
Should discuss which CAs, which policies, are acceptable for signing host cert of issuer.
Do we want a subset of standard system CAs? How to do this? IGTF can and should be involved in this.
Perhaps we need a new profile.
3 profiles in draft are for user certs.
Luna and Mischa discuss let's encrypt and the "would a bank use it" argument.
For the current system reuqires URLS to be verfied, and this will not likely go away. So need trust in this, and the CA that signs it.
Luna - could have different sets of rules?
ML - agree with banks not using let's encrypt. Levels of trust, would want important players to be at the highest level of assurance.
Let's encrypt is for encryption. But makes these discussions difficult, as the certificate is so much easier to get. And they're all in the same browser CA forum.
IGTF recognises different levels of trust. DaveK recently mentioned do we want to be at the mercy of the CA forum (note recent harica CA debacle) - if we're in our own ecosystem we have more scope to make our own rules.
IGTF will need to evolve too. Our policy will have to be adaptable. Given that not all CAs equal, would prefer a handpicked selection of CAs.
MS - this is one of the reasons for the DCVOTA, the google CA, google working with the tagPMA (basically ELM). If we agree that DCVOTA is enough then that's great, but would want to as ML says cherry pick acceptable CAs.
Currently all CAs are in one big bundle.
Luna - A lot of EV removed, ov valid. The browsers have removed this.
Having a list is good, as it provides assurance.
https://chromium.googlesource.com/chromium/src/%2B/HEAD/docs/security/ev-to-page-info.md
https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/
MS - agreed.
Luna - people in the community would have to have a certificate from the list. The list could then be packaged (trust anchors).
But otherwise less strict about this.
ML - we need to have the "final say", not being relient on what the OS decides for itself. Most middleware ignores the system CAs. Occasionally causes problems, but we have managed. Entities in our extended community can put forward candidates for inclusion, to be discussed.
Let's Encrypt is different as not really a CA, at least not in our sense. If we don't have to introduce any unrelated entities would it be best to leave them out.
Luna - would it? Or would
ML - can't use openssl, system, or java job store. But only use one.
Luna - would it?
MS - /etc/grid-security/certificates, from a few places (EGI, PMA) delivered as rpms. Can exclude system directory. Install a custom set somewhere.
ML - java might be more flexible. All our clients use the same. By default system directory excluded. We can decide to enlarge our "universe", but in selective ways, but not the whole CA browser forum.
Will need even more people (like Davek)
MS - the document needs to be updated to include auth by tokens, and update the assurance. IGTF self assessment. Thinks there's something like that for issuers, Hannah done for the CERN IAMs (encouraged by AARC).
--need to follow up on this, if the document needs updating update it.
Encourage self assessments regularly.
MS - these give trust in that people are doing the right thing.
ML -confident this can be part of regular operations at CERN.
This would be a low hanging fruit, publishing publically (zenodo or similar)
MD - agreed
ML - scope to remove biggest hurdle to new country joining, lack of a national CA.
DD - if we want to have higher assurance for issuers have extended validation, and put this into the client logic.
MS - COuld even do OV, but currently we're stuck at DV (cilogon is just DV and can't go higher as they rely on Amazon).
Need to check this (Dave did)
The cilogon is okay as we see the whole picture, even if a single "block" is a little weak.
Getting the whole picture is hard for the whole CA.
DD checked in this, just DV.
Luna - if a CA creates EV certificates but isn't otherwise up to scratch (on our list) then we can't accept it.
ML - make selections on the use case. Note scitokens library and how it verfies token issuer url. This would currently verify okay for let's encrypt. Could have a policy that stops folks from doing this.
DD - problem is let's encrypt might be spooffed.
ML - today the software would work.
Could have somewhere where we have the amazon CA, but not let's encrypt.
MS - in the US it's easier as completely off usercerts. Not the case in the EU.
MS - Do we want to have a seperate /etc/grid-security/$token_cert ?
ML - could there be any other use cases that would want to have a seperate directorie?
MS - without usercerts just need to trust issuer certifciates, but these want high assurance.
ML - if we have a new directory might want to give it a generic name.
Luna - what's the problem we want to solve by seperating?
MS - the problem we have is that host certs and client certs can be mixed. Don't want someone making a proxy cert out of lets encrupt hostcert. A CE would have used /etc/grid-security/certificate that had let's encrpy in it this could be misused.
IGTF CA enforced subject DN would be unique. Start mixing "good enough" CAs would get messy. Recall the original DUNE amazon CA issue.
Seperation not needed if service just does one or another.
--Some re-framing of the discussion
WLCG VOs were "good" VOs, but others not as good. Vetting not as good for the "long tail of science". Some incidents involving this.
Note of the issue of AI making exploiting easier.
Luna - if the solution comes with too much complexity.
Need to come up with new name for possible new certificates.
Would contain CAs of accepted host certs endorsed by us.
Luna - do we need the new path?
ML - to some extent institutes will have to server more communites, so would like to avoid having to do different things for different groups.
Fairly sure our ecosystem will remain reasonably closed, data not flowing between communities.
Coming back to second directory, would be feasable that we put all CAs for host certificates into that CA?
MS - no need for different hostcerts yet, if there's a CA we approve it's likely good for all. This new directory could be a premable for the future situation - that we only have CAs for hostcerts. /etc/grid-security/certificates continues, second directory would look quite similar, but have one or two others in it.
/etc/grid-security/certificates needs to be set for most services, could change it. Have a campaign to make sure this directory in all the right places.
MS - need to think about this and the consequences. But explicit use of a different directory is a good idea.
ML- need to discuss this with David Greop, and if he approves we can take a step forward with this.
Makes sense to have Something like the IGTF involved.
Actions
* Run these ideas past David G
* Assurance document too much user certificate based, IGTF focussed, needs assurance profiles updated. Make a start at updating it (suggestions welcome)
ML - The text of the policy doc has messages in it that need to be preserved, but needs to be scrapped.
A lot of the lines will be completely replaced.
Introduction will need to be expanded.
ML will take a look this week.
Matt will recirculating the links.
## AOB, Next meeting
Confirmed next meeting Tuesday 15th September at 15.00 CEST
Only meeting in September, but will communicate via docs or the list.
There are minutes attached to this event.
Show them.