Choose timezone
Your profile timezone:
Token Trust & Traceability WG
→
Europe/Zurich
Description
Token Trust and Traceability WG
https://codimd.web.cern.ch/nwcd8WltTEqHkBoh9QA9LQ
# TTT 13/10/26
Attending: Matt, Maarten, Mischa
Apologies: DavidC
## Actions, Since Last meeting
Not much happening
## Trust Assurance Policy discussion
Discussing Maarten's added paragraph on the dual nature of our current status.
MS approves of the text, but maybe too much detail for the intro?
Some clearing up on text.
ML - we can't say something that will happen that will be difficult to impliment.
Software/middleware issues (ARC-CE) needs to be careful at selecting the right CAs for the right purposes.
For ARC they do too much in the same code stack
MS- cannot disable proxy verification.
if you allow tokens to be used, you should be allowed to use token only.
Can provide guidance on this. Host revocation etc, could be mentioned in the polciy document.
ML - By policy we can make this happen
ML - JW key set just needs to be factored out of their current stack, then the issue can be solved.
Hoping that ARC are the only ones with this sort of issue.
MS - suggested in ARC CE ticket. Seems to have stalled.
ML - suggest opening a new ticket in the near future.
MS - might need a call as don't understand the problem.
ML - here should come up with generic statements for the split between the two environments.
MS- also a 4th igtf assurance profile (ELM). made for the google CA. Created for IAM like solutions
ML - will need to update chain for IAM certificates to be compatable woth DCvota https://www.igtf.net/ap/dcvota/
Need to be clear in text that assurance for users and servers is performed differently
Discussion of second trust store directory.
Any need for a third (or more)?
Probably not, but Matt wonders about future proofing.
MS, ML - don't want more then two
Would have a different, but overlapping store for the second directory.
Other services can just ignore it.
ML - hopefully this can be changed in a few years when user certs go away
MS - if you don't want to blindly accept all the system CAs then we'll always have to have our own directory.
ML - notes that scitoken library uses system CA for writes.
Already precendent for not wanting allsystem CAs (not wanting letsencrypt IAM).
For our community, not allowing use of let's encrypt for critical services BY POLICY
ML - Let's encrypt could disappear too.
Discussion on the let's encrypt section of the side document. Reach out to discuss this with DavidG
ML- Could we rely on system CAs for key download, and rely on the above policy statement.
MS - disadvantage of using system CAs, rely on CA/B forum - if a CA in it gets hacked we're in trouble. Scope for nasty-stuff.
ML - currently we're masters of the system CA.
MS - also don't get warnings.
ML - this is an argument for our own group.
MS - also good if we see dodgy CAs we don't trust.
ML - a lot of CA/B forum CAs we'd have no business with anyway.
MS - something to risk assess.
ML - can do this in an informal way, and reach out to DavidG.
Then we can back the document up.
The maintenance of the second CA distribution would be some effort.
Need to do the risk assessment on this.
Need to back polciy with reasoning
MS - the other way would be to try to have software pick and choose and CAs used, or symlink.
Some discussion of how the system CA dir is unpacked, and digging around our systems. All of us see a slightly different picture
Maintenance could be a problem in a new CA cert directory.
ML - Don't want to put too much to work into something that will likely go away. But we might have a plan
No way of excluding CAs from within a directory.
## Actions for next meeting
Reach out to DavidG, regarding let's encrypt viability (or lack there of), and opinions on the viability and requirements for a seperate CA directory
## AOB, Next Meeting
Same time in 2 weeks (27th October)
There are minutes attached to this event.
Show them.