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 |