ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Since the semantics of this signature are different from any of the
others (this is really a signature from the domain owner, or his/her
proxy, indicating permission to use an address in their domain), another
type of signature is required anyway.
Given that specifications exist for how to use S/MIME at the domain
level, this
appears to be false.
I still think that the semantics of an S/MIME signature are subtly
different. A user-granularity MASS signature, for example, doesn't
attest to the identity of the sender as does an S/MIME signature, but
that the sender is authorized by the domain (it could be the subject's
administrative assistant, for example, that is actually sending the
message). And applying a MASS signature for example.com doesn't say
that's who you are, but instead that you have authorization from
example.com to send a message.
Mind you, I happen to think another type of signture is indeed
required here,
but not because the domain owner is the one signing things.
Even if you do this as a
multipart/signed MIME part, the signature needs to be different from
S/MIME, PGP, etc. for that reason (in addition to the need to bind with
some subset of the message headers).
Protecting outer headers is indeed a reason not to use any of the
existing
schemes. (I do note that encapsulation can be applied to reuse
existing schems,
but IMO this is a really bad approach.)
Agreed.
Once again, this isn't necessarily an end-to-end scheme.
Actually, the draft charter sort of says this. At one point it refers to
"transit time use", at another it refers to "short term protection". The
problem is that this still leaves end-to-end mechanisms in scope, and
people on
the list have been pushing for things that are closer to end to end
and further
away from long hop.
The "transit time use" and "short term protection" phrases refer to the
lifetime of the keys rather than whether they're end-to-end or not.
Can someone give me a good definition of "long hop"?
Intermediaries
that modify the message SHOULD re-sign it.
Change that to a MUST (for compliant intermediaries) and recognize the
fact
that such intermediaries are currently the rule, not the exception,
and we'd
pretty much be in agreement. But I see no consensus behind this
approach on
the list.
Agree that for a compliant intermediary it's a MUST. I was using SHOULD
in the context of what the overall system needs to support; one hopes
that the intermediaries are compliant but they MAY NOT be and IMO
authentication should work reasonably (I know this is qualitative) in
the presence of non-compliant intermediaries.
-Jim