Skip to main content

XML Voucher: Generic Voucher Language
RFC 4153

Revision differences

Document history

Date Rev. By Action
2015-10-14
07 (System) Notify list changed from <Donald.Eastlake@motorola.com>,<fujimura@isl.ntt.co.jp>,<terada@isl.ntt.co.jp> to <terada@isl.ntt.co.jp>
2012-08-22
07 (System) post-migration administrative database adjustment to the Abstain position for Ted Hardie
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-09-13
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-09-13
07 Amy Vezza [Note]: 'RFC 4153' added by Amy Vezza
2005-09-07
07 (System) RFC published
2005-02-09
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-07
07 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-07
07 Amy Vezza IESG has approved the document
2005-02-07
07 Amy Vezza Closed "Approve" ballot
2005-02-04
07 (System) Removed from agenda for telechat - 2005-02-03
2005-02-03
07 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2005-02-03
07 Michelle Cotton
[Note]: 'All old discusses have been cleared.  Returning for the additional approvals needed for publication.  This is one of the last two documents needed to …
[Note]: 'All old discusses have been cleared.  Returning for the additional approvals needed for publication.  This is one of the last two documents needed to finish the work of the TRADE working group.' added by Michelle Cotton
2005-02-03
07 Michelle Cotton IANA Comments:
Upon approval of this document the IANA will register 1 XML Namespace and 1 XML Schema.
2005-02-03
07 (System) [Ballot Position Update] Position for Ted Hardie has been changed to Abstain from Discuss
2005-02-03
07 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-02-02
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-01-19
07 Scott Hollenbeck Placed on agenda for telechat - 2005-02-03 by Scott Hollenbeck
2005-01-19
07 Scott Hollenbeck
[Note]: 'All old discusses have been cleared.  Returning for the additional approvals needed for publication.  This is one of the last two documents needed to …
[Note]: 'All old discusses have been cleared.  Returning for the additional approvals needed for publication.  This is one of the last two documents needed to finish the work of the TRADE working group.' added by Scott Hollenbeck
2005-01-18
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2005-01-18
07 Scott Hollenbeck [Ballot Position Update] New position, Yes, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-01-14
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-01-14
07 (System) New version available: draft-ietf-trade-voucher-lang-07.txt
2005-01-10
07 Scott Hollenbeck State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Scott Hollenbeck
2004-11-06
07 Steven Bellovin
[Ballot discuss]
Section 3:
        XMLDSIG is not a"secure communication channel", it's a form
        of object security. 

But …
[Ballot discuss]
Section 3:
        XMLDSIG is not a"secure communication channel", it's a form
        of object security. 

But Section 9 has the wrong security model, I think.  What it needs
to say is something like this:

        If a voucher is being passed among trusted entities, it
        SHOULD be protected by a channel security mechanism such
        as [TLS] or [IPsec].  If the voucher is to be delivered to
        an untrusted party, such as an end user's computer, it MUST
        be digitally signed by [XMLDSIG].  Parties accepting vouchers
        from untrusted parties SHOULD check the validity of the
        signature and SHOULD verify that the particular voucher
        has not been redeemed previously.
       
Note:  I do not see any sort of serial number in the description,
which is going to make that last requirement impossible to fulfill.
I strongly suspect that a serial number field needs to be added to
the XML, with a MUST-grade requirement that it be unique amoung
all vouchers issued with a given issuer name.  That latter could
be relaxed slightly -- i.e., you could bind it to an Issuer/Provider
pair or some such, but that gets very messy.  Stick with a per-issuer
unique serial number (which can be any string; it doesn't have to
be a number).  I do not think that that will change the vtsapi
document, but the authors should re-examine it in this light.  For
example, should an API be added to generate verify the digital
signature?  To check for replays?
2004-11-05
07 Ted Hardie
[Ballot comment]
I've moved from DISCUSS to Abstain on this ballot because the authors did
address the Conditions issue I raised in my initial DISCUSS.  …
[Ballot comment]
I've moved from DISCUSS to Abstain on this ballot because the authors did
address the Conditions issue I raised in my initial DISCUSS.  I remain concerned
that the applicability of this work is less than the existing applicability statement
covers, but I've decided that a shift to abstain is appropriate here.
2004-06-07
07 Scott Hollenbeck State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Scott Hollenbeck
2004-06-07
07 Scott Hollenbeck Note field has been cleared by Scott Hollenbeck
2004-04-29
07 Scott Hollenbeck Intended Status has been changed to Informational from Proposed Standard
2004-03-10
07 Scott Hollenbeck Shepherding AD has been changed to Scott Hollenbeck from Ned Freed
2004-02-16
06 (System) New version available: draft-ietf-trade-voucher-lang-06.txt
2003-12-04
07 Amy Vezza Removed from agenda for telechat - 2003-12-04 by Amy Vezza
2003-12-04
07 Ned Freed State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Ned Freed
2003-12-04
07 Ned Freed
[Note]: 'Some changes are likely to be needed to address IESG<br>concerns, so this document will need to be re-reviewed<br>once it is updated.' added by Ned …
[Note]: 'Some changes are likely to be needed to address IESG<br>concerns, so this document will need to be re-reviewed<br>once it is updated.' added by Ned Freed
2003-12-04
07 Ned Freed Some changes are likely to be needed to address IESG
concerns, so this document will need to be re-reviewed
once it is updated.
2003-12-04
07 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for  by Bert Wijnen
2003-12-04
07 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-12-04
07 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for  by Thomas Narten
2003-12-04
07 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-12-04
07 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-04
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-12-02
07 Steven Bellovin
[Ballot discuss]
The security discussion is inadequate.  Do you need channel security (TLS, IPsec) or object security (XMLDSIG)?  I suspect that the latter is more …
[Ballot discuss]
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?
2003-12-02
07 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for  by Steve Bellovin
2003-12-02
07 Ted Hardie
[Ballot discuss]
Frankly, I have general problems with the scope of this work; it seems to need a
much tighter applicability statement (given that they …
[Ballot discuss]
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.
2003-12-02
07 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for  by Ted Hardie
2003-12-01
07 Ned Freed State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ned Freed
2003-12-01
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2003-11-25
07 Russ Housley
[Ballot discuss]
The Security Considerations are not sufficinet.  They say:

  Security issues for delivering Voucher Components are discussed in
  Section 3.

Section 3 …
[Ballot discuss]
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.
2003-11-25
07 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for  by Russ Housley
2003-11-25
07 Ned Freed Placed on agenda for telechat - 2003-12-04 by Ned Freed
2003-11-25
07 Ned Freed [Note]: 'Four week last call requested' has been cleared by Ned Freed
2003-11-25
07 Ned Freed State Change Notice email list have been change to <Donald.Eastlake@motorola.com>,<fujimura@isl.ntt.co.jp>,<terada@isl.ntt.co.jp> from <Donald.Eastlake@motorola.com>
2003-11-25
07 Ned Freed [Ballot Position Update] New position, Yes, has been recorded for Ned Freed
2003-11-25
07 Ned Freed Ballot has been issued by Ned Freed
2003-11-25
07 Ned Freed Created "Approve" ballot
2003-11-25
07 (System) Ballot writeup text was added
2003-11-25
07 (System) Last call text was added
2003-11-25
07 (System) Ballot approval text was added
2003-11-03
07 Amy Vezza Last call sent
2003-11-03
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-03
07 Ned Freed State Changes to Last Call Requested from Publication Requested by Ned Freed
2003-11-03
07 Ned Freed [Note]: 'Four week last call requested' added by Ned Freed
2003-04-30
07 Ned Freed Shepherding AD has been changed to Freed, Ned from Faltstrom, Patrik
2003-03-03
07 Jacqueline Hargest
Date: Mon, 3 Mar 2003 13:23:38 -0500
To: "'Patrik Faltstrom'" <paf@cisco.com>


Hi Patrik,


There is consensus in the TRADE working group to advance …
Date: Mon, 3 Mar 2003 13:23:38 -0500
To: "'Patrik Faltstrom'" <paf@cisco.com>


Hi Patrik,


There is consensus in the TRADE working group to advance
draft-ietf-trade-voucher-lang-05.txt as a Proposed Standard
and draft-ietf-trade-voucher-vtsapi-05.txt as an
Informational RFC.


See you in San Francisco.


Thanks,
Donald
========================================================
Donald E. Eastlake 3rd, Motorola,
MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA
Donald.Eastlake@Motorola.com, 1-508-851-8280
Two-way-pager: 1-888-809-4679
2003-03-03
07 Jacqueline Hargest Draft Added by Hargest, Jacqueline
2003-02-28
05 (System) New version available: draft-ietf-trade-voucher-lang-05.txt
2002-12-16
04 (System) New version available: draft-ietf-trade-voucher-lang-04.txt
2002-06-17
03 (System) New version available: draft-ietf-trade-voucher-lang-03.txt
2001-11-27
02 (System) New version available: draft-ietf-trade-voucher-lang-02.txt
2001-05-17
01 (System) New version available: draft-ietf-trade-voucher-lang-01.txt
2001-02-21
00 (System) New version available: draft-ietf-trade-voucher-lang-00.txt