Subject: RE: Daily activity report
From: [email-masked]
To: [email-masked], [email-masked]
Date: Fri, 27 Feb 2004 16:37:54 -0800
List-Id: <ietf-trade.lists.elistx.com>

It also contains the Beagle virus in the ZIP file which Norton Antivirus did not immediately detect (at least on my PC) so just delete it.

David

-----Original Message-----
From: James M Galvin [mailto:[email-masked]]
Sent: Friday, February 27, 2004 4:33 PM
To: [email-masked]
Subject: Re: Daily activity report

This message was forged.  It was *not* from me.

Jim

On Fri, 27 Feb 2004 [email-masked] wrote:

    Date: Fri, 27 Feb 2004 18:16:30 -0600
    From: [email-masked]
    To: [email-masked]
    Subject: Daily activity report

Date: Fri, 27 Feb 2004 19:33:00 -0500 (EST)
From: James M Galvin <[email-masked]>
Subject: Re: Daily activity report
To: [email-masked]

This message was forged.  It was *not* from me.

Jim

On Fri, 27 Feb 2004 [email-masked] wrote:

    Date: Fri, 27 Feb 2004 18:16:30 -0600
    From: [email-masked]
    To: [email-masked]
    Subject: Daily activity report

Date: Fri, 27 Feb 2004 18:16:30 -0600
From: [email-masked]
Subject: Daily activity report
To: [email-masked]

----------eaxqtewsjtdllwlurovr
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

----------eaxqtewsjtdllwlurovr
Content-Type: application/octet-stream; name="adcac.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="adaabcca.zip"

----------eaxqtewsjtdllwlurovr--

Date: Thu, 19 Feb 2004 22:04:33 +0900 (JST)
From: Masayuki Terada <[email-masked]>
Subject: IESG Comments on draft-ietf-trade-voucher-vtsapi-05.txt and proposed resolutions
To: [email-masked]
Cc: [email-masked], [email-masked]

Hello trade WG list,

We received the following comments on the draft from IESG:

> The security API is inadequate.  It doesn't support things like
> challenge/response, it doesn't support cryptography, it makes no
> provision for the client to authenticate the server (we've already
> seen fake server attacks in the wild; this threat isn't
> hypothetical), it doesn't seem to have a way to convey a user name,
> it doesn't have the right primitives to support TLS, etc.
> 
> The document uses the domain foo.bar in examples rather than the
> domains reserved for such purposes: example.com and example.org.

Of course, security is very important for trading vouchers, and it
must be provided by a VTS (plug-in).  VTS-API is intended to provide
well-abstracted and unified semantic primitives for user (and wallet)
to interact with such a VTS.

And also, I believe that VTS-API provides enough primitives for VTS to
support security, like challenge/response needed in distributed VTS.
We have implemented and demonstrated a voucher wallet (and
issuing/collecting) system with a smartcard-based VTS implementation
at the 54th IETF Yokohama.

The previous draft (-05), however, could have too simple explanation
about securing VTS implementation.  To address the concerns from IESG,
we revised the draft based upon the following considerations:

1) About supporting challenge/response

VTSAgent#prepare() may be used to get a challenge from the receiver of
a voucher (see 5.4.3).  After invoking prepare(), the sender's VTS
plug-in may create the corresponding response and send it to the
receiver by VTSAgent#transfer() (or issue/consume/present), which
(logically) rewrites the ownership of the voucher in the VVS.

The description in the previous draft (-05), however, could be too
simplified and misleading as if the rewriting were always performed
physically upon the central database (in a centralized VTS
implementation).  In the revised draft (-06), we described more
explicitly that the rewrite is logical and it may be performed by
sending the response (corresponding to a challenge) in a distributed
VTS implementation.

2) About supporting cryptography

VTS should support cryptography, but cryptography algorithms/protocols
used in a VTS (e.g. in challenge/response) should be determined by the
provider of the VTS, not a user (of the wallet).  Cryptography should
be encapsulated in a VTS and doesn't appear in the API.

For similar reason to 1), we described explicitly that cryptography
should be used to secure the challenge/response or the authentication
of the user in VTSAgent#login().

3) About provision for the client to authenticate the server

I supposed that this comment discusses client/server authentications
of the centralized VTS implementation in 5.4.1 VTSAgent#login(), since
"server" only appears there in the previous (-05) draft.

In a centralized VTS implementation, a client (i.e. the VTS plug-in)
can be assumed to know the server's address and the authentification
information (e.g. the public key certificate of the server) in a
preference file or a smartcard.  a VTS may use them to prevent fake
server attacks.

However, I agree that it would be better for VTS providers to warn the
fake server attacks in the draft.  Some implementation notes are added
in 5.4.1 VTSAgent#login().

4) About having a way to convey a user name

I'm not sure what this comment would point out, but we add some
comment lines about usernames to the example code.

5) About having the right primitives to support TLS

VTS-API doesn't provide specific primitives to support TLS by same
reason as 3).

However, TLS would be useful and should be recommended to secure
communication channels such as those connect between clients and the
server in a centralized VTS implementation.  TLS is recommended as a
means to secure communication channels in the revised draft.

6) About domain names in the example.

It's my mistake; fixed as the comment.

-----

I believe that the changes made in the revised draft would address all
of the comments from IESG, however, I'd appreciate additional comments
or suggestions if any.

Best regards,

    Masayuki Terada <[email-masked]>
    Security Systems Lab., NTT DoCoMo Multimedia Labs.

Date: Wed, 18 Feb 2004 09:58:01 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-voucher-vtsapi-06.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Voucher Trading System Application Programming Interface (VTS-API)
	Author(s)	: M. Terada, K. Fujimura
	Filename	: draft-ietf-trade-voucher-vtsapi-06.txt
	Pages		: 29
	Date		: 2004-2-18
	
This document specifies the Voucher Trading System Application
Programming Interface (VTS-API). The VTS-API allows a wallet or other
application to issue, transfer, and redeem vouchers in a uniform
manner independent of the VTS implementation. The VTS is a system to
securely transfer vouchers, e.g., coupons, tickets, loyalty points,
and gift certificates; this process is often necessary in the course
of payment and/or delivery transactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-vtsapi-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-voucher-vtsapi-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-voucher-vtsapi-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-voucher-vtsapi-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-voucher-vtsapi-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 17 Feb 2004 22:53:42 -0500 (EST)
From: Donald Eastlake 3rd <[email-masked]>
Subject: I-D ACTION:draft-ietf-trade-voucher-lang-06.txt (fwd)
To: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

Hi,

I believe that the problem which was stopping ID announcements from
being posted directly to the mailing list has been fixed. So future
announcements should appear directly.

Thanks,
Donald
===================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
 Milford, MA 01757 USA                   [email-masked]

---------- Forwarded message ----------
Date: Mon, 16 Feb 2004 15:38:23 -0500
From: [email-masked]
To: IETF-Announce:  ;
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-voucher-lang-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: XML Voucher: Generic Voucher Language
	Author(s)	: K. Fujimura, M. Terada
	Filename	: draft-ietf-trade-voucher-lang-06.txt
	Pages		: 19
	Date		: 2004-2-16

This document specifies rules for defining voucher properties in XML
syntax. A voucher is a logical entity that represents a right to
claim goods or services. A voucher can be used to transfer a
wide-range of electronic-values, including coupons, tickets, loyalty
points, and gift certificates, which are often necessary to process
in the course of payment and/or delivery transactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-06.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-voucher-lang-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-06.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-trade-voucher-lang-06.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Content-return: allowed
Date: Tue, 17 Feb 2004 10:32:40 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: voucher-lang, voucher-api and ecml2 drafts
To: "[email-masked]'" <[email-masked]>

Thanks to Ko Fujimura and Masayuki Terada for updating the
draft-ietf-trade-voucher-lang-06.txt and
draft-ietf-trade-voucher-vtsapi-06.txt!

The first of these is already in the internet-draft directories
and the other shoud appear within a few days. In the mean time,
both are also available linked off of <http://www.iotp.org/>.
(I have been experiencing some problems with that web site
which I am working to clear up.)

An updated ecml2-spec draft should also be available by the
end of this week.

Thanks,
Donald
============================= Donald E. Eastlake III       [email-masked]
 Motorola Laboratories               1-508-786-7554 (work)
 111 Locke Drive                     1-508-634-2066 (home)
 Marlboro, MA 01752 USA

Date: Mon, 16 Feb 2004 19:46:17 +0900
From: Ko Fujimura <[email-masked]>
Subject: IESG Comments on draft-ietf-trade-voucher-lang-05.txt and proposed changes
To: [email-masked]
Cc: [email-masked], Masayuki Terada <[email-masked]>, Ko Fujimura <[email-masked]>

Hello IETF trade list,

We received comments from the IESG on the draft as attached.
To incorporate these comments,  I updated the draft and posted,
today.  So, the updated draft (-06) will be announced in couple
of days.

Major changes from the previous version (-05) are as follows:

(1) We agree with IESG comments on the <Conditions> elements
(See attached) and now we changed it not to allow sub-elements.
We rewrote Section 6.11 <Conditions> as follows:

   The <Conditions> element contains any other restrictions or
   conditions applied. This is intended to cover contracts between the
   issuer and holder of the voucher in natural language form.
  
   An implementation of a wallet system SHOULD provide a means of
   displaying the text in this element.

   The <Conditions> element has no attribute.

   The <Conditions> element is defined by the following schema:

    <element name="Conditions" type="string"/>

Similaly, we added the use of the <Merchandise> element to Section 6.9
as follows:

   This element is intended to be interpreted by a collecting system.
   An implementation of a wallet system does not have to use this
   element. Any restrictions applied should also be described in the
   <Description> element or the <Conditions> elements in natural
   language form to enable users to check the restrictions.

(2) We think that more descriptions are need to clarify the role of
Voucher Component and VTS regarding security. We rewrote Section 9
"Security Considerations" as follows:

   The VTS must provide a means of preventing forgery, alteration,
   duplicate-redemption, reproduction of a voucher, and non-repudiation
   of transactions as described in Section 3.2 of [VTS]. These security
   requirements, however, mainly follow the VTS plug-ins and their
   protocols. This document assumes that the VTS plug-ins are trusted
   and installed by some means, e.g., manually checked like other
   download applications.

   The Voucher Component, however, defines restrictions on VTS Provider
   (or VTS plug-in), and if this information is altered, incorrect VTS
   plug-ins not accepted by the issuer could be used, and a forged
   voucher could be verified as if it were valid. To prevent this
   situation, the Voucher Component should be acquired securely, e.g.,
   downloaded from a trusted party using a secure communication channel,
   such as [TLS], or [IPSEC], or secured by the digital signature of a
   trusted party.

(3) It is not to incorporate IESG comments but we added a registration
request for the vts-lang name space in Section 7 "IANA Considerations"
for consistency with other related documents.

In the previous draft (-05), the name space
"urn:ietf:params:xml:schema:vts-lang" was used. Now (-06), it is
changed to "urn:ietf:params:xml:ns:vts-lang" for consistency with other
similar works
(See http://www.iana.org/assignments/xml-registry-index.html).

That's all. I think these changes cover comments pointed out by IESG.
Please let me know if you have any additional comments.

Regards,

Ko

IESG Comments on draft-ietf-trade-voucher-lang-05.txt:
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTagf24&rfc_flag=0>

 >======================================= >The security discussion is inadequate.  Do you need channel security (TLS,
 >IPsec) or object security (XMLDSIG)?  I suspect that the latter is more
 >applicable, but in either case, an analysis is necessary to demonstrate
 >why.  If either can be used, guidance should be provided on when each
 >type should be used. What security services are necessary? 
Confidentiality?
 >What if the voucher is from an embarrassing organization? Integrity?
 >PRobably.  Non-repudiation?  In that case, object security is needed.
 >But who checks for replays, and how?
 >
 >======================================= >Frankly, I have general problems with the scope of this work; it seems to
 >need a much tighter applicability statement (given that they are defining
 >a "Voucher Component and VTS-API specifications" but not a standard
 >protocol). 
 >
 >I also think this needs a good bit more review by folks who might have
 >to use it, as a lot of seems to be based on assumptions that might or 
might
 >not hold true generally. A good example of this is in the "Conditions"
 >processing (sections 4 &  6.10).  The initial description of the 
Conditions
 >in section 4 says:
 >
 >  Condition Component
 >
 >    Provides any other applicable restrictions. This is intended to
 >    cover contracts between the issuer and holder of the
 >    voucher in natural language form.
 >
 >"Natural language form" implied to me "free text" as opposed to
 >"structured text", but the  description in 6.10 says:
 >
 >  The <Conditions> element may contain any element used to specify
 >  any other restrictions or conditions applied that limit the use of
 >  the voucher. The sub-elements contained in this element are
 >  depending on the application of the voucher and are left to the
 >  other domain-specific specifications. Domain-specific elements can
 >  be extended as sub-elements using [XML-ns].
 >
 >That seems to imply that <Conditions> can be structured in certain 
contexts,
 >but that the structure there might relate only to the context, which 
leaves it
 >a bit up in the air as to whether someone getting a voucher needs to 
preserve
 >markup here.
 >
 >The last line related to <Conditions> is:
 >
 >  If the <Conditions> element is omitted, it will be generally
 >  interpreted that there are no other restrictions or conditions on
 >  using the voucher.
 >
 >If the structure of this is application dependent, the interpretation 
of this
 >pretty much has to be as well.  There is no way to prevent someone from
 >saying "in my application, no conditions will mean there are no conditions
 >under which you can use this".  If this is retained, it seems like it 
has to be
 >given as deployment advice, rather than a default configuration.
 >
 >======================================= >The Security Considerations are not sufficinet.  They say:
 >
 >   Security issues for delivering Voucher Components are discussed in
 >   Section 3.
 >
 >Section 3 says:
 >
 >   The Voucher Component is usually delivered from the trusted VTS
 >   Provider, Issuer or trusted third party using a secure
 >   communication channel, such as [XMLDSIG], [TLS], or [IPSEC].
 >   Delivery of the Voucher Component is beyond the scope of this
 >   document.
 >
 >Since the specification of secure communication channel has been
 >declared out of scope, the Security Considerations should explain
 >the consequences of not using a secure communication channel.
 >
 >======================================= >

--------------------------------------------------------------
Dr. Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)46-859-3814, Fax: +81-(0)46-859-8329
Email: [email-masked]

Content-return: allowed
Date: Thu, 12 Feb 2004 15:41:16 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: IESG Comments on draft-ietf-trade-ecml2-spec-08.txt
To: "[email-masked]'" <[email-masked]>

IESG Comments on draft-ietf-trade-ecml2-spec-08.txt

=================
I think I understand the "Important Note" at the beginning of 2.1.1 - the minimum size values given in the field list are recommendations for the smallest length of the text input buffer for field values that implementers could safely present to users of these forms (i.e. if the buffer were shorter, users would almost certainly want to provide values that exceeded the buffer). However, it took me several readings to arrive at this conclusion, and the text itself could be a lot clearer.

2.1.2, footnote 8: The international access code in the NANP is not "1", it is "011". "1" is the direct distance dialing prefix. And yes, as Steve notes, we have large documents in the IETF (RFC2806 and its bis) that describe the proper representation of telephone numbers.

Finally, along the lines of Russ's Discuss, I'm really surprised that channel security is touted in the Sec Cons rather than object security. For a payment token, I'd think that non-repudiation would be a valuable security property. While non-repudiation is mentioned in the document, it is attributed to an alphabet soup of presumably complementary technologies without any specific indication of where one should turn if this property is desired.

=================
There are standards for representing telephone numbers.  These should be cited....

For certificates, what forms of URL are acceptable?  All?  Is this a pointer to a certificate chain?  What format is the certificate in?

Users don't necessarily use passwords just because they have pre-established accounts.  Nor does a certificate necessarily suffice if there's no prior account setup.

=================
In section 2.2, there is a note giving the ECMA Schema version as:

  (20) URI [RFC 2396]] indicating version of this set of fields.
  Usually a hidden field.  Equal to
  "http://ecml.trade.wg.ietf.arpa/version/2.0" for this version.

This looks like dereferencable URI, but there is no ietf.arpa in
the current DNS, and I know of no plans for one.  I'd suggest
using one of the IANA registries like RFC 3553 params (the 
params namespace registry is present, but unpopulated, see:
http://www.iana.org/assignments/params)

That same section says:

  (26) A URL that can be invoked to inquire about the transaction.
  This is usually a hidden field.

and
    (35) Uniform Resource Locator [RFC 2396].

(referring to:
user certificate          Ecom_User_Certificate_URL          128  (35))

Any limits to the URL schema allowed?  Is this mailto: style, or
http: style in terms of what "inquire about" means?

Lastly, this pair:

  user data gender          Ecom_UserData_Gender                1  (36)

and its list:

  (36) A single capital letter, M=male, Fþmale, N=Neuter,
  H=Hermaphrodite, U=Unknown.

sets off every alarm bell in my California-saturated head.  If this
list is derived from somewhere else and a reference can be given,
fine.  But having the IETF decide that these 5 were the listable
genders seems like a reeeeaaallly bad idea.  Punting this to someone else's
lawyers if at all possible would make me breathe easier.

=================
The first paragraph of the security considerations says:

  The information called for by many of these fields is sensitive and
  should be secured if being sent over the public Internet or through
  other channels where it can be observed.  Mechanisms for such
  protection are not specified herein but channel encryption such as
  TLS [RFC 2246] or IPSec [RFC 2411] would be appropriate in many
  cases.

This discussion should be expanded to cover integrity and authentication.
The specification includes support for digital signatures, and this
feature should be highlighted here.  Also, is there any reason that
an application-layer encryption is not appropriate, such as XMLENC or
CMS?

Content-return: allowed
Date: Thu, 12 Feb 2004 15:30:10 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: No TRADE WG meeting is Seoul, Document Status
To: "[email-masked]'" <[email-masked]>

Hi,

As previous indicated, there is no meeting of the TRADE WG
planned for the next IETF meeting is Seoul, S. Korea.

We currrently have three documents that have been returned
for modification from the IESG with comments:
http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-spec-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-vtsapi-05.txt

You can find all the comments through the IETF ID tracker at
https://datatracker.ietf.org/public/pidtracker.cgi;
however, for ease of discussion on this mailing list, I plan
to repost the IESG comments here.

We need to revise and re-submit these drafts. If we agree
with an IESG comment, then the draft should be changed to
incorporate it. If we don't agree, then the draft should
at least be modified to be clearer and explain our
reasoning so we won't get the same comment back next
time.

Thanks,
Donald
============================= Donald E. Eastlake III       [email-masked]
 Motorola Laboratories               1-508-786-7554 (work)
 111 Locke Drive                     1-508-634-2066 (home)
 Marlboro, MA 01752 USA