OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses


A recipient can have access to the
sender's signing certificate (in fact
will need to have access in order to
check the signature!)

An XMLDsig signature may have a KeyInfo element
containing the sender certificate. The pkcs7 structure
for a signature may likewise have a certificate 
within. Out of band exchanges (e.g, using CPPs
and CPAs) are also possible.

The security point (not universally agreed
upon as far as I can tell) is that it would be
best if a "From" address agree with the
email address in the signer's certificate.

Some software may enforce that constraint that 
the "From" header value match the cert. value,
but other software may say that what matters
is the signature itself, and more or less
ignore the value of the "From" header. This is
why the situation is an interoperability trap.

To attain interoperability with the "stricter"
software implementations, given that Messaging
requires use of "From,"  we probably need
a way to mark an agreement that the signing
certificate have the same value as that in
the "From" header.

However, we might choose to handle this 
particular matter under the
still imcomplete SecurityPolicy element.
By version 2.0, if no other specifications seem
able to specify policies such as these,
we will probably need to invent a notation
to handle the policies we have identified
pertaining to the small security details
involved in collaborations. So far I am still
hoping another more dedicated security
group will produce something we can use.

Dale Moberg

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, January 03, 2002 10:21 AM
To: Dale Moberg
Cc: Robert D Kearney; ebxml-cppa
Subject: RE: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses



Dale,

I think that you are suggesting that the SMTP "from" address be included
in
the CPA so that a message receiver can verify that the "from" address is
the expected one.  However, the security point, as I understand it, is
that
the "from" address must be the same as in the signing certificate.  That
means that the message recipient should compare the "from" address in
the
message to the address in the signing certificate.  Will a recipient
have
access to the sender's signing certificate?

************************************************************************
*************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
************************************************************************
*************



Dale Moberg <dmoberg@cyclonecommerce.com> on 01/03/2002 10:40:20 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    Robert D Kearney/Watson/IBM@IBMUS, ebxml-cppa
       <ebxml-cppa@lists.oasis-open.org>
Subject:    RE: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses



Comments in line.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, January 02, 2002 4:03 PM
To: Dale Moberg
Cc: Robert D Kearney; ebxml-cppa
Subject: RE: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses



Marty>
It seems to me that the SMTP "from" address is local deployment
information
that is of no use to the other party, so there is no need to put it in
the
CPP or CPA. In other words, your alternative "from an installation
value"
is the right answer.

Dale> I disagree that there is _no_ use, but it is a small usage
that crops up in the security area.

When using SMIME signature techniques and SMTP transport, a common
controversy is what to do when a "from" value does not match an email
address contained in the signing certificate. Some wish to ignore the
discrepancy, some wish to have a warning, and some wish to reject the
message as failing authentication. I would imagine the same kind of
issue would impact XMLDsig-- at least the conditions for conflict
("from" header and certificate attribute) are present. So I think
that the "from" information, while not pivotal information, like
the "mailto" URL would be, is nevertheless involved in the
party-to-party
interface, in the security aspect of that interface. So an agreement may
be needed on what "from" value is to be used. I agree that we still have
no clean and sharp basis for distinguishing purely
local deployment configuration information from
that information impacting interoperable interfacing
at the messaging level, and so we always have to handle it
on a case by case basis. I think that the "from" info could
need an agreement. I also think the earlier point that ebXML Messaging
requires using "from" headers makes it eligible for CPPA inclusion


I might also note that the SMTP "from" address is not necessarily the
same
email address that the party uses for receiving messages (the one that
is
in its delivery channel), so the original question is equally valid for
SMTP in both directions.

Dale> I agree, though, in practice a good guess would be to use the To
address
in the mailto URL as the value for "from" (unless told otherwise by
direct data entry,
etc)


Regards,
Marty

************************************************************************
*************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
************************************************************************
*************



Dale Moberg <dmoberg@cyclonecommerce.com> on 01/02/2002 05:14:20 PM

To:    Robert D Kearney/Watson/IBM@IBMUS, ebxml-cppa
       <ebxml-cppa@lists.oasis-open.org>
cc:
Subject:    RE: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses



Hmmh. If there is a missing "from" address in the
CPA (such as in your case of SMTP one way, and
HTTP back), then the CPA could not be used to
populate that required informational item.

The "from" element is, of course, a 'sending'
feature rather than a 'receiving' feature in
a delivery channel, and the original
goal had been to focus on defining channels
by receiving characteristics only. This has
not worked out too well, and this could be
another gap.


Currently, the sending software would have to figure out
a way to get this value (from a user wizard, from
an installation value, from a certificate's field, from
an alternative PartyId that happened to have
rfc821 addresses, and so on. Do you think we
should fix this? Where would be a good place
to stick the info? Under the SendingProtocol
element? Someplace better occur to you?

Dale


-----Original Message-----
From: Robert D Kearney [mailto:firefly@us.ibm.com]
Sent: Wednesday, January 02, 2002 3:00 PM
To: ebxml-cppa
Subject: [ebxml-cppa] SMTP Needs "to" and "from" e-mail addresses


The CPP/A document describes an Endpoint element for SMTP containing an
e-mail address (page 38?).  According to the Messaging Specifications,
any
bXML over SMTP requires both "to" and "from" lines in the SMTP header.
It
is not clear from the description that if the sending protocol is SMTP,
that there has to be a "from" e-mail address somewhere in the CPA.  In
fact, if one direction is SMTP and the other is HTTP, I don't see that
there is a place for two e-mail addresses.  Can someone clarify what
happens in this case?

Bob Kearney


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC