ietf-mailsig
[Top] [All Lists]

Re: semantics of the signature

2004-10-07 06:55:41

It just can not be that I had the last word.  :-)

Does the silence mean that the model I've proposed below is right?  Or
are folks still just thinking about it?

Dave, you're the guy with the "edit token" on the charter.  What's your
opinion?

Jim





On Wed, 6 Oct 2004, James M Galvin wrote:

    Date: Wed, 06 Oct 2004 11:13:09 -0400 (EDT)
    From: James M Galvin <galvin+ietf-mailsig(_at_)elistx(_dot_)com>
    To: ietf-mailsig(_at_)imc(_dot_)org
    Subject: semantics of the signature


    I was going to reply to a few messages but in the spirit of keeping this
    to a charter discussion, it seemed to me that the question of the
    semantics of the signature is at the core of what this working group
    proposes to accomplish.


    The proposed charter currently says this:

        The MASS working group will specify an Internet mail mechanism for
        transit-time use, to cryptographically authentic the author or
        sender of a message and its content; the working group will
        determine which is used. The working group will determine which
        portions of the Internet mail protocols to modify.


    The primary issue that I am raising is the conflict betweeen the phrases
    "transit-time use" and "authenticate the author or sender".

    If the goal is to authenticate the original author or sender, normally
    called the originator of the message, then I remain completely opposed
    to this working group.  To me that goal is "reinventing" secure email
    (PGP, S/MIME, whatever) and, speaking personally of course, I have not
    seen any compelling reason for doing so.

    On the other hand, if the goal is best represented by the phrase
    "transit-time", I may be in favor of this working.  For the purposes of
    being clear about what I believe can and should be done, let me describe
    a somewhat contrived example.


        Alice is an MTA with a message M that Alice controls.  How Alice
        came to control M is confidential to Alice.  Perhaps an MUA
        submitted M to Alice.  Perhaps another MTA relayed M to Alice.  In
        either case, the initiating side of the connection that gave Alice
        control may or may not have been authenticated.  There is no way to
        know without explicitly asking Alice through some out-of-band means.

        Alice is willing to take responsibility for controlling M.

        Alice needs to relay M to another MTA, let's call it Bob.

        Alice creates a signature to include with M asserting

            a. she currently controls M
        b. she can be contacted if there are issues with the M

        The signature is created with a public-private key pair that belongs
        to the domain in which Alice controls M.  Note that Alice may have
        responsibility for many domains so the choice of domain is
        important.  Especially important is the fact that this signature has
        nothing to do with the content or origin of M.  (Well, not quite,
        since the signature may be applied to a hash of the content and/or
        some amount of the envelope information and/or some amount of the
        headers, but that's a detail for the purposes of this discussion.)

        Alice contacts Bob, sends M and the signature.  These will be
        packaged together according to the technology used to create the
        signature.

        Bob validates the signature.  Assuming it validates Bob now knows
        for certain the immediately preceding MTA that controlled M.

        Bob can now do whatever else Bob wants to do to confirm that M is
        suitable for delivery.  Perhaps Bob has a policy that says all
        messages from Alice can be passed on without further delay.  Perhaps
        Bob does not really know Alice, in which case Bob will perform
        additional checks on M.  Perhaps Bob will perform additional checks
        on Alice.

        If Bob approves of M then Bob continues its delivery.  Details of M,
        the signature, and the validation are logged.  The same message that
        Alice delivered to Bob (M but without Alice's signature) is
        delivered.

        If Bob disapproves of M, Bob knows where to go to complain.  Bob
        could even decide that all future messages from Alice are to be
        discarded.


    This example explains what I meant by "in the small" in a prior message.
    Certainly layers can be wrapped on this up to and including an
    end-to-end signature.  Whether or not such layers are important or
    useful deserves discussion in this working group.  Stopping just short
    of an end-to-end signature is what I meant by "in the large".


    The critical phrase above is that the signature asserts the identity of
    the prior hop that controlled the message.  Nothing more, nothing less.
    It is a "domain-based" identity.  In particular, it does not
    authenticate the sender or author.


    This means that if "layering" is not a requirement, then TLS/SSL is a
    solution.  The deployed TLS/SSL base focuses on authenticating the
    server but it certainly supports authenticating the client.


    S/MIME and PGP are both perfectly capable of being a *PART* of a
    solution to this problem.  They are not a complete solution because the
    standard "profile" for both presume they are operating in an end-to-end
    context, which forces certain assumptions about the identity in use.
    Further, they both operate with "certificates", which forces certain
    assumptions regarding key distribution.

    It is these latter two points that this group needs to decide.  What
    identity do we want to be asserted?  And second, given an identity, how
    are we going to retrieve and distribute the public key it uses.

    We also need to decide what we want the identity assertion to mean.
    I've proposed above that it means only that the MTA "controls" the
    message.  Simple, short, and to the point.

    We can sign anything we want.  The working group needs to come to
    consensus on what it wants to sign.


    A secure email technology requires two inputs: a blob and a public key.
    It produces two outputs: a blob (the same in a signature case, encrypted
    in the confidentiality case) and set of security information.

    Both S/MIME and PGP actually support more than one means of conveying
    that information: security multiparts and something unique to itself.
    Do we need another means of conveying the security information?


    My point is, if you want to create a signature for or encrypt a blob, we
    have several technologies to choose from, at least of two popular ones
    are specific to email, the application context for this working group.

    Our focus needs to be on using one of them.


    On the other hand, perhaps my "contrived" example is way off base, in
    which I need a little bit of education.

    Jim




<Prev in Thread] Current Thread [Next in Thread>