Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

dgustafson1 wrote:
>
> Hi Ed,
>
> Things that are interesting that may not be in your charts:

Thanks for the good points. My comments are inlined.

> Fx = Secure Message Exchange Negotiation
> ----------------------------------------
> Ideally, if a correspondent's email address is known, it should be easy
> to start the exchange of secure messages with that correspondent. It
> should be possible to query the entity's email address for any
> information necessary to initiate exchange of secure message(s). Intent
> is to _not_ require a single, world-readable directory of all potential
> email correspondents and their current email address(es), etc. -- the
> existence of which would likely have disastrous consequences.

The lack of this feature is what problems P13 (Must Pre-Enroll Recipients)
and P16 (Must Send Own Certificate) are about. I preferred to list the problems
rather than the feature because it explains the two parts of the issue, is more
concise and is technologically-neutral. Describing the feature (as above) would
require a longer text, and talking about a directory (for example).

In other words, if the secure email system does NOT have problems P13 and P16,
there is no need to talk about Fx.

> F(x+1) = Secure Message Exchange Recipient Privacy
> --------------------------------------------------
> Conversely, it should be possible for each correspondent to exert their
> personally desired level of control over just who is able to access to
> his/her email address and, particularly, the corresponding security
> profile. Perhaps analagous to Caller-ID, the individual user
> (recipient) can determine which queries receive valid security
> information and which are handled in some other way. Intent is to allow
> desired message exchange but not be forced to spend time handling (mass
> quantities of) unwanted secure messages.

If there is no need to grant access to "valid security information" to the
sender (because P13 and P16 do not exist), then F(x+1) is not needed to protect
the recipient's privacy.

However, you still make another good point: the recipient should not be
forced to spend time handling (mass quantities of) unwanted secure messages.
Which may be even worse if anyone can easily send you a secure message
(because P13 does not exist).

This problem (i.e, allowing the recipient to determine which secure
message to decrypt) is handled by a combination of F8 (Identity
Certificate) viewed before decryption, F10 (Meets Digital Signature Requirement)
to make sure the message is not spoofed even though it is signed, F11 (Authenticates
Sender and Recipient) to make sure the sender is not spoofing a valid credential,
with absence of several P#'s especially P6 (Unverified Sender's Email Address).

P6 is important here because if you can trace the sender (there's no spoofed
sender email address), not only the sender becomes liable but you have now
a fixed, verified target to accept or block.

> F(x+2) = Secure Message Exchange Blocking
> -----------------------------------------
> Ability to "undo" an earlier decision to engage in secure message
> exchange with a particular correspondent or group of correspondents. I
> want to "revoke" my credential specifically with respect to future use
> for communication with certain other correspondent(s).

F(x+2) is not needed for the reasons above -- those correspondents do not
need to access security information from you and you can easily block them.

> Obvously, I don't have a specific solution in mind and have not tried to
> separate these capabilities cleanly. They'll all kind of run together
> at first. Also, I don't care whether public key, secret key, DH key
> exchange, x.509 certificates, or (any other crypto technology) is used
> in any solution.

Yes, that's why the paper uses features and attacks/problems that are
technologically neutral and uses them to create a technologically-neutral
score card, that is also product-agnostic.

> The main point, at the outset, is to define a compellingly service that
> has sufficient benefits to drive the efforts necessary to achieve it's
> development (i.e., as opposed to allocating resources on other
> activities). All of us have been waiting for at least 10 years to start
> using secure email (i.e., as we know it today). A decade of collective
> experience strongly suggests there must be some new thinking before
> things will be able to move ahead.

Yes. The work provides a view to both improve the email security technologies
X.509 / PKI, PGP and IBE, and develop the specifications for new technology
beyond current limitations.

Cheers,
Ed Gerck