(Sorry about the big quote). Ned, I can't sit by and not have secure
email until the gateway vendors evolve their products to accommodate
this recent (multipart/signed is two years ago -- not so recent)
development.
Whether or not multipart/signed is recent or not is irrelevant. It didn't
contain any language about gateway conformance. As such, it was simply ignored
by the customers seeking compliant gateways and hence it was also igored by the
gateway development community.
There are some gateways that are simply not in active
development, attached to networks that are simply too large to roll out
a new version because this faction of the Internet community would like
it to happen. I would even argue that there are some gateways that will
stay exactly the way they are until they are thrown out and replaced --
they will never be modified.
Sure, there's a big pile of legacy gateways out there. Microsoft Mail's SMTP
gateway, for example. The old cc:Mail gateway pile that produces seriously
incomliant messages. And so on.
But these gateways are not a problem in practice, for a very simple reason:
They were abandoned before MIME came out. As such, they don't delve into MIME
at all, much less multipart/signed. Tunneling is in fact the default with this
junk.
If there's a significant number of gateways that support MIME but have now been
abandoned I am unaware of their existance. And I deal with gateways at
thousands of customer sites on a dailly basis. If you have specific examples
I've love to hear about them, but until I see a list of such gateways I'm not
inclined to believe in their existance, much less their widespread existance.
As far as a gateway tunneling into signedData, I think at that point it
is really over the edge. The gateway has gone to the point where it
would implement PKCS #7 unwrapping code, and it has deliberately not
stopped to consider the consequences of modifying signed data. This is
generally destructive to the use of digital signatures, and is in my
opinion a suicidal move in the face of their increasing popularity.
I work for a gateway vendor and I have over 15 years of experience in this
area. I routine deal with support issues at literally thousands of different
sites that use our products. And I think this gives me the right to say the
following: You are simply, completely, and totally wrong about this. Far from
being suicidal to implement such code, it would be suicidal, in the event that
use of signedData by itself becomes widespread, for us not to. (It is also a
lot easier to do than you might think -- I could probably crank out the code to
do it, given the support libraries we already have in our product, in a couple
of hours.) What will happen is that a customer will call up on the phone and
say "what is this goo" and we'll respond that it's a signedData object which
contains MIME inside and they'll say "why didn't you convert it" and we'll say
"because that will wreck the signature". They will then say "this must mean you
didn't scan it for viruses either" and we'll say "yes that's true". And then
they'll say "that's unacceptable and words cannot express how little we care
about the signature so either convert it and scan it or we'll switch to a
gateway that does". And since we're not inclined to go out of business by
taking the high road and not implementing such support, you may count it as a
given that we will do it if this eventuality comes to pass.
The one difference between Innosoft and another gateway vendor is that we'll
take care to implement the right sorts of tunneling options as well as
signature removal options. Other vendors will not do this.
Right now, the use of signedData might make gateway vendors hopping mad,
but I still have my signatures intact. Maybe the gateway vendors will
take pause and understand that what I do is not out of malice or spite,
but out of necessity to enforce the sender's will over that of the
gateway, which does not understand the sender's goals of sending a
signed message.
Gateways vendors owe you no loyalty whatsoever and simply do not care what your
reasons are for doing what you do. Gateway vendors do owe their customers
something, however, and that something is to continually enhance their products
to accomodate whatever wierd sorts of content is thrown at them, converting it
into usable forms.
Right now we have accommodated for the sometimes conflicting goals of
the gateway (make sure it gets taken apart as best as it can, so that
the content is preserved in a meaningful way -- preservation of content)
and the sender (usually, I don't care if the signature gets eaten so
preservation of content is important. But dammit, sometimes I want to
make sure that the signature is preserved!) If the recipient's gateway
implements tunneling to attack signedData, then it is making a value
judgement -- it believes that mangling the content is more important
than the sender's wish that it not be mangled, even though the sender
has explicitly made the decision to keep the signature intact
(otherwise, he would have sent it unsigned or as multipart/signed).
This is a hard issue.
Hard line, maybe, but not a hard issue. The sender of the message has the same
right to consideration that you do: None whatsoever. Your right to dictate what
gateways do to messages simply doesn't exist in any realistic sense. What does
exist, however, is a recipient's right to get messages in the form that is most
advantageous for them. This is where there is some leeway, not at the other end
of things. So the thing to do is to come up with standards that say gateways
MUST implement the option to tunnel such material or not be compliant with
Internet specifications, not because some sender is whining about their
signature being busted, but because it is the best interests of recipients to
allow this option. This managers will hear and take note of, and it will change
their demands on gateway vendors considerably.
In fact gateway vendors welcome this sort of thing because it gives them a way
to distinguish themselves in the market. We win all sorts of sales over larger
companies because our gateways continue to provide more flexibility and
capabilites than the competition. If we can say "we implement compliant
multipart/signed handling and they don't" we just might win a sale we would
not have otherwise.
If PKCS #7 tunneling evolves without intelligent handling of the fact
that it is munching a signature, then I will encrypt all of the messages
also.
At which point we'll get called and told "you didn't convert this". We'll
respond, "we can't because it is encrypted and we don't have the keys". The
customer will then say "that means you didn't check for viruses and furthermore
our security policies may be in the process of being thwarted, right?" and
we'll say "yes that's true". At this point the customer will probably say
"relax, we see this one isn't your problem, but where's that division manager
who deployed S/MIME support -- we want to have words with him about his
upcoming lack of career prospects in this company". Or they could say "we'll
institute a policy where the keys have to be made available to you can you use
them" or "how about you simply reject all encrypted messages", both of which we
could implement. Whatever. The point is that this is far from the viable
last-ditch option you seem to think it is.
At some point my goals of on-demand guaranteed integrity,
non-repudiation and authenticity will be accomplished.
I admire your continued willingness to believe this. I do not share your
belief, however.
You're right,
this isn't healthy. Neither is diving into PKCS #7 signedData to grab
the MIME out and discarding the signature like a dirty tissue.
Depends on whether or not the customer regards it as a dirty tissue. If they do
then discarding it is the right thing to do.
I am in the position of developing both client and gateway products.
Our latest product is a gateway product that makes very hard, thoughtful
decisions about monkeying with signedData. In the event that a
modification would need to happen to a signed part (signedData or
multipart/signed), there are very clear, administrator definable rules
as to what should happen. These rules can be (among other things) the
modification of the content (and removal of the signature), or the
notification of the sender and quarantine of the message. I believe
that a similar level of intelligence is required for other gateway
products to evolve to the point where the sender's wishes are not
ignored due to the "I know better" attitude of some of the current
gateway technology that is still stuck in the early '90s, which
interferes with conducting business-grade email.
Innosoft has had all this support in place for years now for multipart/signed.
But other vendors didn't add comparable support for the simple reason that the
IETF didn't tell them to put it in. We need to fix this by telling them that
they have to.
In my opinion, I would
prefer that gateways return messages that are signed to the sender with
a notification that the gateway needs to perform processing on the
message which would invalidate the signature. At that point, the sender
could come up with some way to deal with this development (send the
message unsigned) and continue on his way.
We provide this option available as well in our products.
OK, so you use it unconditionally which pisses off every single mail
client that is not aware how to process these constructs. What am I
missing here? I get the impression that you're not considering the
clients right now. The installed base, as John points out.
You're missing the fact that this is a lose-lose situation. The product that
produces signedData fails because it generates a firestorm of protest and
regardless of security concerns, regardless of the need to upgrade
infrastructure, the basic ability to communicate has to come first. And you
lose because gateways vendors will also seek to accomodate this usage, and not
knowing what really needs to be done they won't get it right and your
signedData won't tunnel when it needs to.
Have we seen rapid response from gateway vendors with multipart/signed?
Of course not -- we didn't ask for a response so we didn't get one.
Is the use not widespread enough? I'm honestly asking.
It isn't a question of usage, it is a question of requirements. Believe it or
not, requirements often play a far more significant role in purchase cycles
than actual usage does. 1/3 of the mail on the Internet could be
multipart/signed and it would not be sufficient to make gateway vendors
implement tunnelling as an option. A requirement that tunneling be provided as
an option, on the other hand, will have an effect. It may take time, but
it will have an effect.
No one is suggesting that we ignore the gateways, they are most
certainly important. Maybe what needs to happen is that gateways need
to stop ignoring the goals of constructs like multipart/signed and
signedData, and instead stop screwing them up and deliberately working
around them. You cited before that Internet standard non-compliance is
a great wakeup call to gateway vendors to fix their products. I guess
that since RFC 1847 is just Standards Track, it isn't really a standard
yet, so the vendors wait until that "STD" shows up, and then become
compliant. I'm not referring to you, of course, but to the ones that
don't work and play well with multipart/signed.
The problem with RFC 1847 isn't that it isn't far enough along on the standards
track, it is that it doesn't impose any requirements on gateways. In fact the
word "gateway" appears nowhere in the document. Nor does the word "tunnel". (I
believe both of these words used to appear but the entire discussion got
removed because that's what the PEM WG wanted.)
So what can we add to multipart/signed to clarify this? There is
already language that says that you ***MUST NOT*** modify the first part
(which still happens), and the content is not always carried intact
through the gateway to keep the integrity of the signature.
There is no such text in RFC1847. The text that is there talks specifically
about message transfer agents not altering the content. But an MTA isn't a
gateway. They are different things. As such, this text cannot possibly be read
to impose any sort of restriction on a gateway. A gateway can in fact claim
full compliance with RFC1847 and do whatever it likes with multipart/signed.
In fact I'll go further than this. The fact of the matter is that gateways
are pretty much required to delve into multipart/signed by existing standards.
In particular, RFC2049 talks about how subtypes of multipart that don't get
other sorts of special treatment must be handled as multipart/mixed. Now,
this requirement applies to mail user agents. But while a gateway isn't
an MTA, it actually is thought of as a sort of MUA. We talk about gateways
having the right to exercise "user agent authority" on messages all the time.
Well then, it stands to reason that gateways also have follow the requirements
for user agents. And more to the point, gateways these days want to claim
MIME conformance. And the only MIME conformance we've ever bothered to
define is that of a receiving user agent. And there you go.
Is there
something ambiguous about the way that multipart/signed is worded that
seems to make gateway vendors think that modifying the first part, or
not presenting the first part intact along with the signature
information, is not necessary for signature validation?
Gateway vendors don't get this far. They simply see that there are no
requirements imposed on gateways here and they ignore the rest. They also
see what MIME conformance means and they take it from there.
I don't think
gateways are dumb -- it's just that sometimes they are behind the times,
which is quite apparently the case with multipart/signed.
They may be behind the times but they are not behind in terms of standards
compliance. I'm afraid you have no right to complain about gateway behavior in
this regard. You may have a right to complain that we've botched the standards
in this area. But it wasn't because I didn't know what the consequences were. I
will accept some measure of blame for not pursuing this issue more vigorously
but none for not realizing that it existed.
I still don't
see what the problem is with having a stopgap measure (signedData /
application/mime / application/signed / whatever) to get around
compatibility with older technology. I further don't see what the
problem is with having two encapsulation methods with clear rules to
decide when to use each one, so that as much compatibility can be
achieved before some future time where the world is better.
I never said there was any real harm. What I have said over and over again is
that this approach is basically a wash -- it neither helps nor hurts all that
much. What needs to happen is that we finally sit down and say what gateways
are supposed to do. I realize you think we've already done this, but I think
I've proved that not only have we not done so, we've gone out of our way to
avoid doing so. We can do this in conjunction with some stopgap measure or
without some stopgap measure. Frankly, I couldn't care less. But we absolutely
must do it or we will not have accomplished anything at all.
Ned