Hiya, On 10/03/2012 04:11 PM, Sam Hartman wrote: > OK. > Let me rephrase. > > I claim for a given message the following reactions are reasonable:
I'm assuming we're talking generalities here and not just about abfab. > > 1) require signature > 2) ignore any present signature > > and that > > 3) verify if present and fail if verified > is unreasonable. Did you mean: 3) verify if present and fail transaction if not good-signature but handle transaction if no signature present as if a good signature was present If so, yes that'd almost certainly be unreasonable. > It may be that verify if present and tell a human what verification > yielded is sometimes helpful but I'm dubious. > > Are you arguing for 3? I'm arguing that in general (perhaps not for abfab, not sure), your three choices are too binary:-) Signature checking can fail for various reasons (hash compare fails, wrong key, don't have key, don't have path for key, revocation, naming, ...) and the reaction to failure of a signature check can also vary (fail the transaction, subject transaction to more checks as in DKIM, re-route transaction, log the transaction somewhere special, ...). The appropriate reaction to not being able to verify a signature on a signed message can reasonably be different to the reaction to an unsigned message. For example, if I were using key continuity, then the first time I see a signed thing I might allow the transaction even though I've no good reason to accept the public key. But the 2nd time different checks will apply, with possibly different results. For example, I might start rejecting transactions that claim to be from that source but don't have signatures that verify with the key I saw on the first signed transaction from that source. And again, the above are generalities. I'm not saying how the argument might or might not apply to abfab. (And I think we've wandered off topic somewhat.) > Or are you arguing that we should add a new security requirement to > RADIUS that there are some messages that MUST be signed? No, I've made no argument about RADIUS at all. S. > > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
