XML Voucher: Generic Voucher Language
RFC 4153

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

Comment (2004-11-05)
No email
send info
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.