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
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
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
Description: S/MIME cryptographic signature