J. Wren Hunt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Ian G wrote:
| So now I have to figure out how to find a cert for
| this email address. Now given that it took like
| 10 minutes of clicking around by an expert in the
| CA's business to do with the one cert I've got, I'm
| not hopeful!
|
| Especially as there is no button to create a cert.
|
You are more than welcome to create a self-signed cert. But surely you
are aware of the ramifications of such an approach. That's why we've
been bashing our collective heads for these past months on Root CA
policies eh - a shared common root?
Right, but considering that this is *email*
and CAs are simply some optional extra to do
with commercial users (and we saw what they
want) then when it comes to *email* there is
no need to bash anyone's head over any issue.
In email, you and I know each other and we
don't need any CA to tell us that.
Later on, as an option,
we may very well want to go to the CA and
ask for "a third opinion" just like one might
go to the doctor and ask for a "second opinion"
if one is diagnosed as due to kick the bucket
tomorrow. But this should be strictly optional,
the email application should be built on self-
signed certs as a primary principle.
(Now, browsing is a completely different app
so these comments don't necessarily apply.)
|My personal policy (and recommendation) would be
|to never sign email, because it has no clear
|meaning. At least in OpenPGP it is undefined
|what the meaning is, by definition!
That's news to me! People sign using OpenPGP all the time!
Yes, exactly. Let me clarify: In S/MIME,
I recommend not signing because I don't as
yet understand what it means (and according
to Simson Garfinkel et al's paper posted
yesterday, there's little hope that the users
know what it means).
So what does it mean?
In OpenPGP, there is no defined meaning to
signing in the code or spec, so it means
... whatever the signer wanted it to mean.
Which is *safe*. Sign away, it's whatever
you want it to mean.
So, what does it mean in S/MIME? We know
it's not 'undefined' because there are CA
signed certs involved....
And the RFC2633 says S/MIME provides:
"authentication, message integrity and non-repudiation
of origin (using digital signatures)"
Or somesuch. (I haven't read it, I just found
it by accident.) Maybe there's a better one
somewhere in that doc, but that doesn't satisfy
and it's got a red flag in it - non-reputation.
So the conclusion should be the same as what the
lawyers say - "don't sign anything you don't
understand."
|So this would result in encryption being denied.
|That's ludicruous! Is that in the standard?
Well yeah, that's why it's called "public-key" encryption. You somehow
have to have your correspondent's public-key before encrypting to him.
No, public key encryption does not require that
you need to use the signed email feature to distro
the keys. You can use ordinary email, you can
use key servers (in fact that's what x.509
assumed, a worldwide 'telephone directory' for
all the people onthe planet or somesuch), you
could use biz cards with barcodes...
What specifically I am referring to there is that
the S/MIME application has decided to make its
operation *dependent* on signed emails. That's
not good, neither from an architectural pov nor a
meaning pov (as described above).
Most usually this is done via sending a signed-message beforehand. You
may opt to have him ftp/telnet/ssh/carrier-pigeon the key, but
nonetheless you gotta have it.
Right, so send an email with the key. Just don't
force it to be a signed email, or don't hide the
key exchange such that users are encouraged to
"turn on siging" so as to get the key exchange.
Coming back to the here and now ... I suppose the
workaround is to turn off signing, and send an
empty signed email to anyone you want to communicate
with. OK, I can live with that!
But it does make S/MIME much more clunky and less
likely to deploy.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
