> <ALEX> > True, this is keystore territory, and I don’t think this should venture in > that direction – the [sic] > can be considered clearly out of scope.
Why would it be out of scope? Seems like this is actually what you might want given what you wrote below... > However, what would actually make sense would be to offer a configuration > option that > clearly states which of the signature options (and signing material) should > be used. > Clearly the ability to configure this will be needed. I think I agree here but, if I understand you correctly, wouldn't this be best accomplished via references to keystore keys/certificates? > If you want to accommodate this, Actually, I'm just probing the issue. I was hoping the response was going to be "this was discussed by the working group here: <link to email-thread>" and we could move on. But since that does not seem to be the case, it would be good for the WG (not me) to decide if we want/need to accommodate this. What do people think? Options: a) leave as is (and document the shortcoming) b) remove signing-options (add back later when ready) c) address the issue now > you probably need to consider another modification to the model: It is > conceivable that there > could be multiple signers, and different signers might each use a different > option. Therefore, to > allow for differentiation by signer, you might want to consider introducing a > corresponding > parameter under a list of signers. (You could even move the configuration > parameters into this > list, although frankly I would opt to keep those parameters global (and the > use of the model > simple), not per-signer.) True, and potentially a reason to not go with (a) as, with that option, it may not be easy to add in this kind of flexibility later in a backwards-compatible manner. Thanks, Kent // shepherd
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
