VeriSign XML Encryption Thane Plambeck Agenda Application areas for signed and/or encrypted XML Authentication & Validation Services Payment Services Drill down for Payment XMLPay = VeriSign schema for payments XML Encryption Application Scenario Implied requirements for XML Encryption Reactions to Strawman position papers Questions for the group XML in Authentication & Validation Services Goal Make it easier for partners to build PKI-reliant apps Traditional inhibitors Complexity inherent to PKI itself Patents & licensing (RSA, etc...) Need for special PKI toolkits to perform PKIX logic ASN.1 encoding complexity How XML helps Move away from ASN.1 Move toward clients with XML runtimes & base crypto only (I.e. no ASN.1, no complicated PKIX logic) Delegation of trust processing to server-side components XML in Payment Services Goal Enable one schema XML for unified B2C & B2B payment processing, particularly for B2B payment workflow Fairly complicated workflow, several places XML Encryption is desired Traditional inhibitors Legacy payment processing APIs Transactional (ie old) vs data-centered (ie XML) approaches Application Scenario XML Pay XML Pay Today XML Schema & runtime system for Internet Payments Runtime system now in pilot (Ariba, Amex, others) (Sept 2000) Multiple payment types & payment processors Flexible treatment of request authentication XML-DSIG (digital signature) compatible Password-based transport-level authentication also possible Authentication and Signatures supported for buyers and sellers Digital Receipts Transport neutral XML Pay Example I: B2C Use of XMLPay in a consumer Internet B2C credit card payment transaction: XML Pay Example II: B2B Use of XMLPay in a B2B trading exchange: XMLPay Schema Three document suites 1. XML Pay: Core Credit Cards, Purchase Cards, ACH, Internet Checks 2. XML Pay: Register Merchant Signup, configuration, resellers 3. XML Pay: Report Transaction queries, reports XML Pay: Requests XML Pay: Response XMLPay: Transaction Use of XML Encryption in Tender Info Use of XML Encryption in Digital Receipt Interplay of workflow logic and XML Element Names "You've just received encrypted content of some (unfortunately unknown) kind. Would you like to try to read it, or would you like to forward it unchanged?" Versus "You've just received an encrypted (credit card number, ACH routing instruction set, list of payment institutions...)" Strawman Position, I XML Encryption Granularity Absolutely need it at element level Limiting it to entire elements would be OK, but Extending encryption to just element content is attractive. Found no requirement for selective attribute encryption Definitely prefer a true "Encryption Only" specification Sister specification for XML Digital Signature Authorization frameworks, access control issues, trust applications should be out of scope KeyInfo should be merged/fully compatible with XML Dsig work Strawman Position, II Canonicalization Prefer enforced use of Canonical XML even for encryption-only applications Parsers & Schemas Happy to insist that XML encryption applications understand namespaces and the use of XML Schema We anticipate having to change our parsers & schemas to support XML encryption We don't have a requirement to support preexisting parsers, schemas, or XML documents Treatment of Key Information Use XML Dsig wherever possible Strawman Position, III Status of encrypted objects Should be be first class, themselves capable of being referenced and/or signed Referential requirements between EncryptionInfo & EncryptedData Could imagine neither direction required Cryptography (required) AES --- go for it! Triple DES RSA Treatment of Key Information Use XML Dsig wherever possible Questions What is likely interplay between application logic and parser & XML runtime logic for XML Encryption? It's not like S/MIME Is there some middle ground between well-formedness and validity for encrypted XML docs that makes sense to define/describe to help implementers and workflow engines? Ie "validity modulo decryption"