[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Asrg] E-mail Postmarks
On Fri, 4 Jun 2004, Bob Atkinson wrote:
That is what I thought. My possible problem with that is that usually the
signeddata structure is expected to stay constant once its been created.
That would surprise me; the thing that can't change, clearly, is the
stuff that is signed. But that's certainly not the entire SignedData
structure.
Let me explain. The S/MIME signature can technically be changed after it has
been created by having additional party sign upon it. However my understanding
is that S/MIME signature was meant to be constant once the signature is added
to email. This is more of 'we're probably breaking some unwritten rule by
standard creators' type of objection.
To which fields do you refer? They certainly aren't immediate children
of the SignedData...
They are. Any X.509 certificate has date fields and that includes when its
expressed in PKCS7 format. To be honest I'm not certain if the dates would
be specific to SignedData or to actual signature certifiate (i.e. SignerInfo)
I will check on it.
Did you look at alternative of having multiple SignedData structures as
part of multipart/signed.
Yes. I couldn't find any way that would do that in a compatible way.
I've been testing this concept this weekend. Based on what I find, some
(but not all) MUAs have problems when multiple SignedData exists and
especially if the signature is added to non-smime message, they will
report email to user as having invalid s/mime signature and user will
have to take extra steps to be able to open it.
However I found a simple workaround to that, I've change it so that signature
is added with mime content-type "application/x-mta-pkcs7-signature" rather then
"application/x-pkcs7-signature". This may not be ok with MIME purists
that could say that content-type should reflects not the application
that generated the data (or one intended to use it) but general form of this
data structure (and both are pkcs7 signatures). However I think this is a lot
better approach then trying to redefine the actual SignedData
structure.
Currently I've tested x-mta-pkcs7-signature approach with all MUAs available
to me (Pine with S/Mime patch, Outlook, Netscape and Mozilla) and all of them
simply see it is an attachment "mtasig.p7s" which they dont try to open.
Additionally I added signatures to emails signed with S/MIME already
and with PGP and in both cases, the extra unknown signatures were ignored as
long as primary signature was the first one and if the email's
"Content-type: multipart/signed" specified as protocol parameter the original
user's signature type.
If anybody likes to see how this looks, let me know and I'll give you access to
IMAP mailbox with copies of the test emails. For now I'll begin
working on the milter for sendmail and extension to postfix to add these
signatures automaticly for real proof-of-concept testing and will post
to the list when its ready.
Don't know about everyone, but it was totally clear to me that headers
would not be signed and some of them really do need to be. The subject
is first one that comes to mind, but in my view the signer MTA should be
able to choose on its own which header data it wants to sign.
I don't philosophically disagree; as I say, I think signing headers has
value.
However, it seems to me that the case for signing certain headers is
even stronger and much more compelling in the case of user level signing
(the Subject: header in particular). That said, the signed mail world
has lived without that so far, so it's clearly NOT a show stopper issue.
Actually openssl for example has specific options when doing s/mime to specify
"subject", "from" and "to"... But I don't think its been much
used as you note about it. My opinion is if the postmark or similar idea
is to be developed futher, it would be better to immediatly have more
complete concept that specifies how headers may appear in the signature
and how client could check on that data. If its used or not will again depend
on if MTA operators choose to do it or not.
Also unlike the content, I actually don't see any reason why
intermediate MTA would need to resign headers again.
That would depend on the details of the semantic intended to be conveyed
by the act of signing, wouldn't it?
Yes. Same as with original signature actually, intermediate MTA may choose
to add its own signature to confirm validity of the data at the time
message was passing through it or it may choose to pass message through as is
if original signature checks out and message was not modified since.
The certificate chain, of course, may in cases be just one certificate
long, consisting of just a self-signed cert. When doing domain signing,
this is probably even common.
This concept is actually very usefull for reputation systems. Same certificate
maybe signed not only with domain's own signature or that of standard
certifiate authority like Verisign (in which case there is no need to use dns
to get public key) but it may have been signed by
certificate of known reputation authority. Obviously for reputation authorities
it is more importent then ever to check CRLs so extra step of contacting
reputation authority would still be necessary, however for
sites that process lots of emails, the CRL updates maybe downloaded on hourly
or daily basis, which avoids doing this for each and every email
that passes through the system.
Small point: right now I don't have certs in <ep>, but rather just the
keys.
I do in the way I see this concept progressing in the future in my mind :)
Actually more particularly, what I want is in addition to having ceritifate
signed by couple large vendors and like several large reputation systems to
also allow for concept of trust that is used in PGP world where the exist
complex web of trust between users and trust is established if there exists a
chain of trust between receiver and sender. Same concept can be reused as kind
of "email reputation web of trust" and if MTA spams, it'd probably not be
trusted by its peer MTAs any more. This concept would
require maintaining keyring servers in same way as PGP does and that is
where I think new xml protocol and extension of <ep> structure would
really become usefull and they could be reused and where it would become
necessary to maintain a lot more information these records then just in dns but
access to the data would be specific to the question asked.
I'll write something more formal on this concept in the future if others are
interested in pursuing this.
It's also interesting to note that some of even the most massive domains
out there have only a single digit number of DNS servers out there.
That is actually good indication that dns is fairly stable protocol and we
really don't want to compromise it.
I guess I don't follow that line of reasoning regarding stability.
That only few dns servers are necessary and it keeps dns working good enough
for large sites. That applies that dns is quite stable.
Actually number of dns servers for domain does not show how hard those
dns servers are working. Usually actually 1st and 2nd dns server get
all the queries anyway, rest are backups just in case.
It does though make a statement about an upper bound on how hard they
could be working. Which, in total, just can't be very hard on an
absolute scale.
You're missing the point. This is the same wrong assumption Verisign made when
they introduced wildcards. DNS is designed to be generel protocol used by every
application on the net, not just for web, email, etc. If we overload it just
for one protocol - we're breaking it. In such a case
its better to have that protocol have its own variation of dns-like quick
database access infrastructure, which is exactly what I'm advocating for.
That said, using a new protocol bring up attendant deployment and
administrative concerns that will delay adoption in ways that using
existing infrastructure does not.
Well, I'll remind you that in the same reply message, you mentioned
SOAP.
Wherein I was positing to the hypothetical of IF I had to choose another
protocol.
For me its not hypothetical. After initial milters for signing the mail
going through MTA, I'll start work on the next level for the actual
verification of signature and how to get public key for the domain.
Most likely initially it'll be just direct HTTP call, but in the future
I'd definetly like to work on something like SOAP over HTTP/BEEP/UDP concept
more.
Additionally the whole scenario involving MARID and Postmarks and DK is
that the servers who are capable of using such services would need to
update their mail software. I really don't see it as such a big deal
if they also have to deploy policy service as part of such upgrades.
Big point: this isn't a monolithic issue; it's more complicated than
that.
With MARID for example, as currently drafted, NO updates to software on
the *sending* side are needed. That's a HUGE advantage to deployment.
Indeed.
With signing, clearly something new is needed in the mail stream. But
that's not the same issue as requiring new DNS server software.
Which is why I think Microsoft would not have the same problems as you desribed
before as far as adding new dns type and why adding new non-dns
service (especially if its just xml specification and will reuse core
access from existing service) is quite possible and email operators may
understand this as part of the upgrade of their email server software
to support these new MTA-level signatures.
---
William Leibzon
william at completewhois.com
_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg