ietf-mailsig
[Top] [All Lists]

Per-user keys not bound to local-part

2005-03-30 12:31:03

On Wed, 2005-03-30 at 09:41 -0500, Andrew Newton wrote:
On Mar 29, 2005, at 9:54 PM, Sam Hartman wrote:
In general I don't think you will find security people in the IETF are
willing to support a scheme in which a single key is given to a large
number of parties.  So, yes, I think portable keys (by which I mean a
key that a mail composer can take with them) will tend to be per-user.

I'm not a security person, but this makes total sense.  The risks with 
one shared key seem to be obvious.

Providing each entity their own key does not require the key be bound to
the local-part of the mailbox address.  The scope of such a key would be
the domain.  Just the domain is significant for abating abuse. If there
is a desire to ensure there is no possibility for local-part collision,
then moving the signing entity using their own private key to an
unprotected local-part sub-domain would address this concern. This does
not mean a user mailbox address must be affected as a result.

There is a provision already within domainkeys that allows a sender to
act as the signer.  This allows signed messages not sent through the
administrative domain, to have their signature keys assigned to a
different sub-domain, which still permits the protection a specific
local-part name space.

An email address like jon(_dot_)doe(_at_)example(_dot_)com, when sent through 
the
administrative domain's servers, could appear to be- 

FROM: jon(_dot_)doe(_at_)example(_dot_)com

If there were a flag within the key that expresses assurance for the
local-part, then the recipient would have increased assurance for the
jon.doe portion of the mailbox address.  When sent using a delegated
key, and there is a desire to prevent local-part name space collision,
the message could be-

SENDER: admin(_at_)guest(_dot_)example(_dot_)com (local-part not assured)
FROM: jon(_dot_)doe(_at_)example(_dot_)com (behavior assured by 
swamp.example.com)

The email address jon(_dot_)doe(_at_)example(_dot_)com is not assured.  There 
could also
be a binary flag that indicates the local-part has not been validated
for the guest.example.com domain. It could also be sent as

FROM: jon(_dot_)doe(_at_)example(_dot_)com (local-part not assured)

but this would reduce risks only for those able to discern a local-part
assurance.

  Personally, relegating remote users to some other
domain seems unacceptable.

I agree.

Again, having the key relegated to a sub-domain need not affect the user
email address.  However, it does change what is assured.  In the case
where the user is not trusted with respect to using the local-part (not
sent through the administered servers or guest), this can be handled by
isolating these cases within a different signature domain, that vouch
for their behavior only.

In general, it would seem bad practice to publish local-part names in
this manner.  It would also make creation of a binary key RR far more
difficult.  It also would stress the RR should there be a desire to move
toward a 2048 bit key still using the txt RR. 

Importantly, 'g=' may encourage per-user keys as a means to express
local-part assurance.  One method that could mitigate a perception of
increased assurances, would be to add a flag within the key that makes
this assertion without requiring a per-user key for doing so.  If the
domain does validate and confirm the local-part of the significant
address, a flag within the key could express to the recipient this
increased assurance without needing to use specific keys for each
local-part.

A separate signature, fingerprint, or some other scheme to confirm the
local-part, would only add to the overhead.  As these keys are likely
far less secure, isolating them within a sub-domain and/or indicating
that the local-part have not been validated would rightfully reduce
assurances provided to the recipient.
  
-Doug










<Prev in Thread] Current Thread [Next in Thread>
  • Per-user keys not bound to local-part, Douglas Otis <=