XML Voucher: Generic Voucher Language
Note: This ballot was opened for revision 07 and is now closed.
(Steven Bellovin) Discuss
Discuss (2004-11-06 for -)
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?
(Ned Freed) Yes
(Scott Hollenbeck) Yes
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Russ Housley) (was Discuss) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) No Objection
(Ted Hardie) (was Discuss) Abstain
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.