Kyle,
I have no idea what you're talking about, sorry.
I think the best way to handle that is to go write an
I-D describing what you'd like and then send the URL
here. (Honestly, in my experience it helps a lot.)
S.
On 02/09/2012 03:09 AM, Kyle Hamilton wrote:
Once upon a time in the IETF, there was a mandatory-to-implement cipher.
This cipher was the best-selected at the time, using cutting-edge
technologies.
Time changed. The new mandatory-to-implement cipher came along.
Why haven't we ever considered that maybe S/MIME doesn't have to be
fully authenticated on first contact? Why haven't we considered that
with only a single certificate chain, the user would first have to
communicate his MUA capabilities to his CA and then not upgrade his mail
client without coordination?
Instead, we should have a new header in our email.
X-Secure-MIME-Capabilities:
We could make it contain a base64-encoded representation of what the
Capabilities extension's OCTET STRING would contain. Or we could assign
labels to the various cipher algorithms to make them human-readable.
Instead of thinking along the lines of "only the named recipient will
get it", why don't we start thinking along the lines of "the destination
mailbox will be able to get it"?
From there, it becomes fairly easy. "I must ensure that the symmetric
key used to encrypt the message can be decrypted by all of my user
devices and recovery keys." A procmail recipe could perhaps re-send the
message with additional recipient keys.
At that point, it's "what if I don't have my keys on the device where I
can run procmail?" IMAP becomes a useful tool, as does POP3. They can't
alter messages, but they permit a daemon that can, for example, ensure
that its re(multiply)destined messages make it back into the mailbox
before the original, single-destination message is purged.
This would also allow for additional commands to be sent from the
devices to the keystore, such as "sign this with my corporate key" or
"send this to [email protected] with the best security you know how to
do".
The problem is...?
-Kyle H
On Wed, Feb 8, 2012 at 6:11 PM, Stephen Farrell
<[email protected]> wrote:
<trying to poke things along a bit more actively hat on>
So S/MIME works fine in many cases but does not work well
between random people connected to the Internet, unlike email.
That's a pity.
Its not an easy problem though, XMPP have been trying for a
good while and we don't even seem to have a good solution for
SIP or Diameter which ought be much easier.
I guess if this discussion lead to a way to manage keys that
could work at the same scale as email that would be a major
advance. I don't expect that myself.
And of course, whatever the right answer there (if there
is one) is maybe very different from how we might manage keys
for web servers or MTAs or XMPP servers.
Maybe we ought also think about whether or not the same key
management scheme is right for all those or not as part of
this too and whether we're able to solve all or just some/one
of those problems.
Put another way: maybe it'd be better to tighten the focus
a teeny bit more on this list. Specific suggestions for topics
welcome. Why not start a new thread with your favourite
problem that's worth solving and maybe solveable. (Being the
IETF, we're not very interested in other things in the end:-)
S.
PS: I bet I'm not the only one who can no longer associate
the subject line with the content. Be good to be better at
that since it'll help to try move towards some concrete
outcomes here.
On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote:
Alice has three mobile phones and six laptops.
Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices that
might authenticate Alice.
The same model can even be made to work for confidentiality. Alice can
read her DRM protected Kindle content on any one of those devices.
(Though there may be limits on how many devices the DRM scheme will
permit).
Trying to make S/MIME email work in that scenario is futile. The
sender only tracks one private key for Alice. So Alice has to export
her private key to all her S/MIME clients. Not only is that terrible
security practice, it is too much work. Worse, Alice has to repeat the
process once a year.
That is why I no longer believe that end-to-end is a desirable
quality. A security requirement that does not consider the cost it
imposes versus the risks it mitigates is ideology.
On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent<[email protected]> wrote:
At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
But authentication works in that scenario because the protocols can
allow
each user to have as many keys as they need. The key is not shared
across
devices, the protocols allow for multiple cards per end user
Sorry, I don't understand you comment.
Steve
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
