Ability to disable non default signature algorithm(s)#5
Ability to disable non default signature algorithm(s)#5bobhageman wants to merge 31 commits intobwesterb:masterfrom
Conversation
Ability to disable non default signature algorithm
| # are disabled. This is useful if you only want to support one algorithm. | ||
| # NOTE: if true, you can still verify validity of timestamps generated with | ||
| # any other supported algorithm for the keys listed in otherTrustedPublicKeys | ||
| disableOtherSigAlg: false |
There was a problem hiding this comment.
This presumes that either there only will be two signature algorithms supported or that you'd only want to enable one of them. It seems more logical to me to have an option enabledSigAlgs, and then perhaps interpret the first as the default.
Why do you want to disable one of them btw?
There was a problem hiding this comment.
Currently Yivi is creating a PoC moving the infrastructure into a cloud agnostic environment. Since we are only using ed25519 and we need atumd to be stateless, this small change is (for us) the least intrusive way to make that happen. No change in config needed to keep the current situation running while it is possible to disable all other algorithms (for now only XMSS[MT]) except the default one in our cloud setup.
Thought this could be a nice addition in functionality, hence the pr. On the other hand I also agree with you that the other way around with an option like enabledSigAlgs would be a nice approach.
…k-on-Ed25519KeyPath relax file permission check on Ed25519KeyPath
…k-on-Ed25519KeyPath fileInfo declared and not used
Liveness check added
This reverts commit d927edb.
chore: Update dependencies
fix: Scan image and unify image tagging
6 participants
This modification adds an extra boolean configuration variable
disableOtherSigAlgthat allows you to disable all signature algorithms other than the specifieddefaultSigAlg.If for example
defaultSigAlgis set toed25519anddisableOtherSigAlg=trueit will not be possible to generate a timestamp based on XMSS[MT]. Also (automatic) XMSS[MT] key generation at startup will not happen in this case, essentially disabling all XMSS[MT] based functionality.There is one exception: it will always be possible to verify timestamps for all supported algorithms. So in a scenario where XMSS[MT] is used as algorithm and server config is changed to only accept Ed25519 from now on, it is still possible to validate XMSS[MT] timestamps as long as the public key is listed in
otherTrustedPublicKeys.