On May 12, 2008, at 3:19 PM, Paul Hoffman wrote:
Only somewhat similar. Tony's proposed changes has a "SHOULD inform" and a "SHOULD provide a warning". The quoted test is "SHOULD provide alternate processing" which may be displaying a message. That's a big difference.
Yet the very next paragraph says: """A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification.
""" Sounds the same to me.Here's the thing: You're advocating interpreting the spec as purely a protocol spec. If that's what you're after, then that's a bigger issue than trading barbs over key length recommendations. There are a number of clauses that require UI implementation that need to be struck out (or at least moved to the security considerations section).
But here's my problem with that thinking: S/MIME isn't just a protocol, it's a ceremony. There's an fundamental UI aspect to ceremonies. This needs to be dealt with properly and *prominently* or we'll end up with implementations that don't just *allow* bad things to be done, but that *mislead users* into thinking things are true about messages that just aren't.
Moving all UI-related issues or security related recommendations to a separate section lowers their visibility, and that's not a good thing IMHO.
-- Tim
Attachment:
smime.p7s
Description: S/MIME cryptographic signature