Re: S/MIME v3.2 IDs key size text (resend, no signature)

At 3:51 PM -0500 5/12/08, Timothy J Miller wrote:
> 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.
Reading that quoted sentence, can you see that the "SHOULD" does not 
apply when not "displaying an indication..."? That sentence does not 
mandate showing anything. If there is something in an S/MIME document 
that mandates "showing" or "warning", it is an error. We spent years 
(well, now a decade) working on this so that a conformant 
implementation does not need to have a UI.
> 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).
Struck out, definitely. By all means point them out. I've read this 
too many times to find them, I guess.
> 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.
I disagree strongly with the former while agreeing strongly with the latter.

> 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.
That "misleading" will happen regardless of what the spec says. It 
already happens now, and it happened before the IETF took over 
S/MIME. And it's not just S/MIME: nearly every security protocol the 
IETF has developed has the same problem. It's in the nature of 
security and users and vendors.
If you want to write a BCP for implementers, that's great. This 
mailing list would be a great place for it to be discussed. This spec 
is not a BCP: it is a standard that needs to be consistent on both 
interoperability and security.
> Moving all UI-related issues or security related recommendations to 
> a separate section lowers their visibility, and that's not a good 
> thing IMHO.
It definitely lowers their visibility, and it's also the way we 
usually do things in the IETF. We've done it for over a decade for 
much higher-profile security protocols such as TLS and IPsec as well.