dual-use digital signature vulnerabilityastiglic at okiok.com

[Peter Gutmann]

<Michael_Heyman at McAfee.com> writes:

>Your certificate definition says "additionalRecipients", mine says
>"additionalSubjects", Fred-over-there's says "coKeyOwners". The OIDs for
>these extensions end up all different. A human may be able to parse the
>intent from the ASN.1 it but email programs will have difficulty.

What I meant was that if there was any demand for this, someone would define a
standard place to store the info, which apps would (eventually) display.  At
the moment there's neither a "additionalRecipients", a "additionalSubjects", a
"coKeyOwners", or anything else, because no-one's ever asked for it.

Given the complete lack of demand for this to date I suspect that even if you
did do an RFC for it it'd be relegated to Experimental status and everyone
would ignore it... what exactly is the intent of adding this information?
Under what circumstances would it be used?  What's the UI for it?  Do you
throw up a warning?  Warning of what?  If it's "Others are listening in" then
the alternative is to not use the cert at all, in which case the choice given
to the users will be "Allow one or two others to listen in" vs. "Allow anyone
to listen in", since everyone will choose the former there's not much point in
putting it there in the first place.  etc etc etc.

(There have been similar suggestions made about other warn-the-user type
 features on the S/MIME list, which tend to get shot down with some variant of
 "I wouldn't even know how to begin to do a UI for this", with a backup of
 "This amounts to giving the user a choice of communicate or don't
 communicate, guess which one they'll choose?").

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com