IESG Comments on draft-ietf-trade-voucher-lang-05.txt and proposed changes

[Ko Fujimura <fujimura@isl.ntt.co.jp>]

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&dTag=6624&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: fujimura@isl.ntt.co.jp