Trevor,
Having no way to determine that one is the intended recipient of an
S/MIME signed message is just one of a number of obvious limitations
which have been discussed on the list, but not fully resolved in my
view. Simply saying ?just hope that a recipient can guess that a signed
?thing? was intended for him/her from the content? is not a satisfactory
answer, particularly when the protocol fix is so simple. To reinforce
this point, the message to which I am responding contained no indication
it was for me. The SMTP ?To? field gave a clue, but it is interesting
that if we were using S/MIME, relying on these unauthenticated fields is
(rightly) discouraged. Some implementations may not even display them.
It is at the end of the
day people using these systems, not ASN.1 experts.
Yes but it is machines which are going to be generating and processing
signatures. Many of those will have little or no direct human
interaction: timestamping facilities, CAs, firewalls, virus scanners,
Web servers, to name but a few. Machines are capable of understanding
ASN.1, and they know the context of an application. They are capable of
spotting something which has been taken from one application and (mis-)
used in another.
Other examples such as time stamping do not seem ambiguous.
I do not understand given the current spec how an implementation is
going to detect the difference between an originator?s signature and one
created for time-stamping purposes. How is a time-stamping agency going
to protect itself against the lawsuit from someone who thought it
originated the content of the message?
This seams to me
inherent feature of using a hostile infrastructure. I certainly do not
trust
the document any the less because of its uncertain means of
transportation(email or http), since I trust the signature.
In our experience, the main threat is not coming from the hostile
infrastructure, but from hostile end systems. As I?m sure you know,
writing software which takes local files and sends them off through a
messaging API without the user knowing about it is worryingly easy to
do.
I am well aware that the signature purpose attribute cannot fix all
known security problems on its own. But with careful implementation, I
suggest it contributes to a solution to some of them. To take the
example in the previous paragraph, a firewall could detect and block
outgoing messages which do not have the ?message originator? purpose
code set. There are many organizations (like ours) where that would be
a definite advantage. As a refinement to this, an S/MIME module could
check a user?s capabilities before allowing them to use a particular
purpose code. This would stop ?naughty? software from calling the
module for inappropriate purposes. An obvious place to store user
capabilities is in the certificate.
Determining that you are the intended recipient of a signed message is
also easy to fix: just include the recipient?s distinguished name (or
certificate) in the signature block. That plus sig-purpose protects you
from another class of attacks.
I am guessing that the main counter-arguments are coming from
implementers who claim this breaks ?layering? and S/MIME?s claimed
application-independence. IMHO these features make for bad security,
and it is part of our responsibility to attempt to fix them. Ergo,
vivat sig purpose!
Tim
Trevor Freeman [SMTP:trevorf(_at_)microsoft(_dot_)com] wrote:
I am having real difficulty in seeing any value from including a
signature >purpose attribute. Some of the examples given are trying to
authenticate >the context or the transport of the signed document. Other
examples such >as time stamping do not seem ambiguous.
If Bob receives a document signed by Alice, he does not and cannot
know it was sent by Alice, only that Alice signed the document. This
seams to me inherent feature of using a hostile infrastructure. I
certainly >do not trust the document any the less because of its
uncertain means of >transportation(email or http), since I trust the
signature. If Alice >constructs a document solely intended for Bob, but
addresses it ?to >whom it may concern? then she has opened the door
herself for Bob to >forward the document. Any document Carol receives
signed by Alice and >beginning ?Dear Bob? must be understood by Carol
for what it is. I >cannot see any technological add-on will help Carol
at this point. It is at >the end of the day people using these systems,
not ASN.1 experts.
Signature Purpose - R.I.P.
Trevor