mathew wrote:
Benjamin April wrote:
My main concern here is that allowing the receiving MTA to validate the
token offers a false sense of authority. We now know it is far easier
than originally expected to create a "fake" signing cert.
It was never intended to be anything other than trivial to create a
signing cert. But just because I can create a signing cert, doesn't
mean that anyone else is going to recognize it.
With SSL, the fact that you create a signing cert doesn't mean any
browser software is going to accept it as valid. With e-postage,
sensible recipients will have a policy of not accepting unknown
postage vendors by default. Just as browsers have lists of signing
certs they accept, so e-mail MTAs and/or client software will have
lists of signing certs they accept.
I would imagine that to get your cert onto the standard list for a
common MTA, you'd need to demonstrate that you actually paid out the
postage and weren't just committing fraud. Much as you won't get added
to the default cert list for Firefox if you irresponsibly sign any SSL
key presented to you.
While that is accurate it misses the point. There is a verified attack
methodology whereby I can create my own key-pair to replace the key-pair
blessed by a trusted CA(e.g. Verisign). I can then use my key-pair as if
it were signed by the CA, and it would be trusted as such. When the CA
signs a key they only sign a digest. There are still CA's that use MD5
as their digest algorithm. Known weaknesses in MD5 make this possible.
Most CAs that were on the ball moved to a form of SHA, but that is
nothing but a delay tactic.
I see this as a big issue. I would find having to go to the post office
every time I needed a stamp insane. By using opaque tokens you could buy
a selection of tokens in advance and dispense them on demand.
The only reason having to go to the post office every time you need to
buy a stamp is insane, is that the post office is a physical entity
you have to travel to.
You've got me there. I still do not see a good reason to mandate
send-time transactions.
Millions of people buy e-postage from the USPS every day, in order to
ship stuff they sell on eBay. They go to the online post office every
time they need to obtain and print a stamp. So there's a real world
example showing that it's not an unworkable way of doing things.
There are also models where you buy a quantity of e-postage and generate
your own stamps without (mint-time) contact with USPS. I don't think it
is un-workable however I don't yet see a compelling reason mandate the
linking a token to a recipient.
I don't know if the USPS makes their e-postage codes dependent on the
address you're sending to, but clearly they *could* without breaking
the way ordinary people use the service or making it unworkable. It
would actually be an interesting experiment to try cutting up two USPS
e-postage labels, switching the bar codes around, and seeing if the
items still got delivered properly...
Thanks
Ben
mathew
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg