W3C

- DRAFT -

XML Security Futures Workshop

25 Sep 2007

Agenda

See also: IRC log

Attendees

Present
Frederick Hirsch, Konrad Lanz, Juan Carlos Cruelas, Bruce Rich, Mike McIntosh, Hugo Krawczyk, Gilbert Pilz, Hiroki Ito, Brad Hill, Rob Miller, Jeannine Schmidt, Henry Thompson, Scott Cantor, Sean Mullan, Gary Truong, Michael Leventhal, Steven Williams, Pratik Datta, Corinna Witt, Jeff Hodges, Jimmy Zhang, Symon Chang, Phillip Hallam-Baker, Thomas Roessler, Ed Simon (via phone)
Regrets
Chair
Frederick Hirsch , Thomas Roessler
Scribe
Henry S. Thompson, Stephen D Williams, Brad Hill

Contents


Introduction

FH: The purpose of this workshop is not to do the work here, but to decide if and how to take work forward -- how much interest is there in participating in a follow-on to the XMLSec Maint WG -- what would the charter look like, what issues we would addresss
... We will use IRC to log and to provide background info
... Please consider joining the XMLSecMaint WG
... Weekly call, interop wkshp on Thursday
... Thanks to the members of the WG who reviewed papers for this workshop

ThomasRoessler: Existing WG has a limited charter, maintenance work only

<esimon2> I can hear very well, thanks.

ThomasRoessler: ALso chartered to propose a charter for a followon WG
... We won't draft a charter at this workshop, but we hope to produce a report which indicates support and directions
... That in turn will turn into a charter, if the outcome is positive
... Which then goes to the Advisory Committee for a decision
... The timescale is next year and beyond

TR: [walks throught the agenda]

TR: Slides which are on the web, drop URI here; otherwise send in email to ht@w3.org and tlr@w3.org

Brad Hill, Complexity as the Enemy of Security

<tlr> http://www.w3.org/2007/xmlsec/ws/slides/04-hill-isecpartners/Overview.pdf

TR: Questions of clarification

FH: Restricting to only a few transformations?

BH: Yes, restrict to just small well-known set

SC: Mostly to implementations, rather than specs
... Need to reduce the attack surface of implementations
... so we need an implementors guide, right?

BH: Right

KL: XSLT should default to _dis_able features, not _en_able

Sebastian Gajek, Lijun Liao, and Jörg Schwenk, Towards a Semantic of XML Signature

Presented by Michael McIntosh

<tlr> http://www.w3.org/2007/xmlsec/ws/slides/07-gajek-rub/

<esimon2> Ed's comment: If the structure of a document is important to the meaning of the document (as shown in the examples), then signing by ID (which is movable) is insufficient.

BH: How would you compare doing a hashed retrieval compared to ???

<esimon2> Presentation highlights the need to rethink the XPointer functionality.

<ht_> [scribe didn't get the question]

MM: Apps certainly need to interact better with signature processing
... Need for overlapping signatures implies a need for a signature object model, so you can iterate over all the signatures and treat them independently

<esimon2> Ed says: I don't know that apps need to interact with signature processing better; rather, apps need to ensure the signatures they use sign all the critical information -- content as well as structure.

TR: Open up discussion of security vulnerabilities, other than crypto

MM: It's a pain that I have to encrypt the signature block

MM: DigestValue should be optional

MM: presence of DigestValue means that plaintext guessing attack is possible if plaintext encrypted
... therefore, would have to encrypt the signature as well ...

FH: why is that painful?

MM: tried xml enc?

Konrad: having digest necessary for manifest procesing

Scott: should be optional to have digests

Konrad: also verification on constant parts that are archived separately etc...
... Know of manifest use in electronic billing context ...

<klanz2> http://www.iaik.tugraz.at/teaching/11_diplomarbeiten/archive/scheibelhofer.htm

<klanz2> Signing XML Documents and the Concept of “What You See Is What You Signâ€

scott: need profiles *and* implementation guidelines

frederick: asks about clarifying what implementation guide is versus profiling

Scott: need to have hooks in code that enable best practices to be followed ,implementation guide
... for example, saying signature is valid isn't enough if you are not sure what has been signed, hooks may be needed for this

<esimon2> Ed: I am OK with just listening in and typing comments on IRC. No need to complicate things for others on my account.

Symon: policy can be used to limit what is done with xml security, anohter approach to avoid problems

<FrederickHirsch> discussion as to whether xmlsig spec is broken

<esimon2> The XSLT 2.0 specification mentions a number of security considerations dealing with issues raised earlier.

<esimon2> Agree with Konrad.

Hal Lockhart, XML Security - Issues and Requirements

slides

hal: notes various issues have been document in ws-security, ws-i basic security profile and other places

frederick: also liberty alliance work

klanz2: false negatives will be perceived very badly
... need to focus on what you see is what you sign, then false negatives main issue

hal: agrees

hal: challenge is interface between applicatoin and security processing to get proper security for applciation

henry thompson: liaison issues - schema, processing model wg,
... say to validate you must decrypt, perhaps ...

<esimon2> I agree, I think, with Henry re his comments about XPointer to help resolve the ID issue.

... re id issue , maybe new xpointer scheme?

scott: +1 to klanz, concern about false positivies, issues for adoption

scott: most xml processing is not schema aware, xsi:type is not visible to processing

ht: would issue be solved if sig re-worked to be signing of Infosets

klanz: tradeoff performance & infoset signing

PHB: could use some examples of difference between infoset and current signing approach. What is really different.

Shai Halevi, Hugo Krawczyk, Michael McIntosh, XML Signature Enhancements to Support Randomized Hashing

http://www.w3.org/2007/xmlsec/ws/slides/11-mcintosh-ibm/

Hugo Krawczyk presenting

<MikeMc> the slides for this session are at http://www.ee.technion.ac.il/~hugo/rhash/

hugo: post-wang trauma, how do we deal with it...

<MikeMc> actually - the papers are there - not the slides - sorry

hal: any attacks for which we need to check whether random strings are diferent?

hugo: critical for the signer to check that these strings are different

hal: if random value same for every signature, then can do offline attacks

mike: every time you create new signature, you create new value

hal: how important is it to the verifier that this is the case?
... suppose there's no real signer, just a blackhat sending messages ...
... do you have to keep track of fact that he sends same random number? ...

hugo: if you don't find 2nd preimage on one-way function, then attacker can't

hal: thinking about guessing attack or so
... there are attacks against CBC if IV isn't always different ...

hugo: uniqueness of randomness per signature is not requirement
... requirement is that the attacker must not know randomness that legitimate signer is going to use ...
... question is a valid concern, though ...
... in this case, there's no more to it ..

phb: fuzzy about what security advantage is ...
... we're nervous about hash functions for which malicious signer can create signature collisions ...
... that's attack we're concerned with ...
... randomness proposal makes this the same difficulty as the legitimate signer signing document, and attacker tries to do duplicate ...
... how does this make anything more secure against malicious signers? ...

hugo: technique does not prevent legitimate signer from finding two messages that have same hash value ...
... legitimate (not honest) signer could in principle find two messages that map to same hash value ...
... can't be case if hash function is collision resistant ..
... if it isn't, problem could in principle occur ...
... if you receive message with signature, then signer is committed to that signature ...
... (example) ...
... point is: every message that has legitimate signature commits signer ...
... note that hash function might be collision-resistant, but signature algo might not be ...

hal: attack is to get somebody to sign a document, and have that signature make something else

phb: ok, now i get it
... more relevant to XML than certificate world ...

"not *any* randomness" backup slide

phb: what I can see as attractive here is -- once SHA3 discussions -- ....
... instead of having standard compressor, have compressor, MAC, randomized digest all at once ...
... with parameters ...

frederick: time!

hugo: re nist doc, it applies to any hash function
... exactly like CBC and block cyphers ...

mcIntosh on implementing it

scribe: implemented preprocessing as Transform

(occurs after c14n on slide)

Konrad Lanz, Dieter Bratko, Peter Lipp, RSA-PSS in XMLDSig

http://www.w3.org/2007/xmlsec/ws/slides/08-lanz-iaik/

hugo: rsa-pss doesn't solve same problem as previous randomization scheme ...
... orthogonal problem ...

konrad: ack

<FrederickH> second hash function in diagram for RSA-PSS

tlr: asks about unique urls for two different randomizations, yet could they be combined?
... e.g. RSA-PSS vs Randomized hashing as described by Hugo...

tlr: these are two different randomization schemes, they're orthogonal to each other, yet both affect the same URI space to be addressed
... so the proposed integrations can't be integrated ...

konrad: maybe can share randomness between two approaches

hugo: want randomness in different places from ops perspective; streaming issue

sean: why did tls not adopt RSA-PSS

hugo: inertia, people also are staying with SHA-! versus SHA-256

phill: tls different in terms requirements it is meeting. Documents different than handshake reuqiremnets

konrad: moving defaults...
... time for that

Sue A. Roddy, XML Cryptographic Security and Suite B

http://www.w3.org/2007/xmlsec/ws/slides/17-roddy-nsa/

Jeanine Schmidt presenting.

jeanine: Crypto Suite B algorithms ...
... regrets from Sandi ...

<FrederickH> use of 1024 through 2010 by NIST, indicates potential key size growth issue

<FrederickH> ecc offers benefits for key size and processing

looking for convergence of standards in suite B

<FrederickH> NSA would like to see Suite B incorporated in XML Security

<FrederickH> DoD requirements aligned with this

details could be worked out in collaboration

hugo: specifically saying key agreement is ECDH?

jeanine: yes, preliminarily

hugo: IP issue behind not talking about ECMQV?

jeanine: yeah, that's an issue ...
... but ECDH might be more appropriate algorithm for XML ...
... whether one or both is a question for future work ...

hugo: Can you make this analysis available?

jeanine: this is something that should be worked out betw w3c and nsa
... preliminary recommendation ...

tlr: w3c would need to mean "community as a whole"

frederick: I hear "nsa could participate in WG"?

jeanine: yes

phb: ECC included with recent versions of Windows ...
... doesn't believe they've licensed that from Certicom ...
... given MS's caution in areas to do with IP ...
... maybe ask them how they navigate this particular minefield ...
... if there is a least encumbered version ...
... then will follow the unencumbered path ...

hal: what is involved here in terms of spec?

jeanine: primarily identifiers

frederick: some unifying effort for identifiers might be needed

konrad: spirit of specs is to reuse identifiers

frederick: also recommended vs required

<FrederickH> rfc 4050 has identifiers

sean: in RFC 4054, there's already identifiers for ECDSA with SHA-1

phb: keyprov would like to track down as many of algo ids as possible
... if you have uncovered any (OIDs, URIs), please send a link

hal: start with gutmann's list

frederick: please share with xmlsec WG

<sean> http://www.faqs.org/rfcs/rfc4050.html has URIs for ECDSA-SHA1

frederick: what is next step for NSA at this point -- see what happens here?

jeanine: yes

Phillip Hallam-Baker, Next Steps for XML Signature & Encryption

http://www.w3.org/2007/xmlsec/ws/slides/02-baker-verisign/Overview.pdf

Result: many variations to test, many configurations for analysis, deviation from specification
Proposal: Quantum Profiles
Unique URI for profile that fully specifies choices at each level.
Discrete options combinations, modes are more complicated.
Negotiation of specific combinations.
URIs that are intentionally opaque, not sub-parsed.

sdw: a possible analogy is font strings in X11

konrad: would be useful to have uri's that indicate strength (eg weakest key length)

Partial ordering of profiles may make sense, but might not be good.

Meeting certain requirements, such as for a country, may be more of a private profile, possibly including country name, for instance.

Hugo: Are you making similar proposals in other groups such as IETF?

Phillip: This is something that I would like to take up in other groups. The problem with IETF is that we're dealing with protocols that already have slots for OIDs and it would be difficult to see how to go forward with ASN-based infrastructure and change.

Where picking profiles, CFIG and other groups would likely participate to define OIDs, etc. for certain coherent suites.

How is that approach applicable to signature? We are already in A-la-carte situation.

Juan Carlos Cruellas, Giles Hogben, Nick Pope, The importance of incorporating XAdES extensions into ongoing XML-Sig work

<tlr> http://www.w3.org/2007/xmlsec/ws/slides/03-cruellas-etal/Overview.pdf

Defines XAdES forms that incorporates specific combinations of properties.

Use of these profiles allows much later use and auditing of signed data.

Supports signer, verifier, and storage service.

Signature policy identifier references specific rules that are followed when generating and verifying signature.

Includes digest of policy document.

SignatureTimeStamp verifies that signature was performed earlier.

CompleteCertificateRefs has references to certificates in certpath that must be checked.

Has change been made to change countersignatures to include whole message rather than just original signature?

Don't believe that has been done yet.

Report in ETSI summarizes state of current cryptographic algorithms and makes certain recommendations.

Only minor changes to the standards are in process.

Can individuals use these signatures with the force of laws?

Depends on legal system: Rathole.

<esimon2> Thanks.

Sean Mullan, Position Paper

slides

DOM provided good implementation but has performance issues

Event processing requires one or more passes.

Two passes, 1+, cache all elements with ID, or use profile-specific knowledge

Signature information needed before data vs. signature data etc. needed after data.

Can't do with current XML Signature standards.

XML DSig Streaming Impl.: STaX, JSR 105 API, exclusive C14N, forward references, enveloping signatures, Bas64 transform

sean: recommend best practices for streaming implementations

hal: integrity protecting data stream?
... example is movie

ht: w3c xml pipelining language wg

steve: xml fragments are can be used in streaming, but can sign/integrity protect fragments

?? The combination of streaming and signature is odd -- you can't release the beginning of the document until you've verified the signature at the end

pratik: streaming is for performance, rationale for doing it

<FH> one point I was making is that sometime you do not need integrity protection for streaming, e.g. in cases where it is ok to drop data

HT: Following on, it's precisely for that reason that not doing signature generation is at least odd, since in that case you surely can ship the beginning of the doc while still working on the signature

brad: +1 to pratik, value of streaming is performance

various: Dispute the relevance of signature to streaming XML and/or dispute the value of streaming at all

HT: Requirements on XML Pipeline to support streaming of simple XML operations, interesting to understand how to integrate some kind of integrity confirmation _while_ streaming XML

<sdw> Streaming is important in memory constrained or bandwidth / processing constrained applications.

scott: notes adoption in scripiting languages an issue, using c library not good enough

jeff: example is use of XMLSig is barrier to saml adoption in OpenID

<FH> Peter Gutmann, "why xml security is broken" http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt

Scott: Liberty Alliance worked at producing xml signature usage that addresses many of the threats discussed...
... need simpler way of conveying bare public keys ...
... eg pem block

Jeff Hodges, Scott Cantor, Issues with XML-Signature Syntax and Processing, and Rectifying Approaches

<tlr> http://www.w3.org/2007/xmlsec/ws/slides/15-hodges-neustar/

scott: Retrieval method point to KeyInfo or child, issue with spec

<FH> simplesign - sign whole piece of xml as a blob

Ed: I agree with the above. If the XML is not going to be transformed by intermediate processes, one can just sign the XML as one does text. And use a detached signature.

<bhill> have seen this approach successfully in use with XML in DRM and payment systems as well

<esimon2> What is needed is perhaps a packaging convention like ODF and OOXML use.

<MikeMc> how is this different from PKCS7 detached? is it the embedding of the signature in the signed data?

<esimon2> I would have to review PKCS7 detached but I would say the idea is quite similar.

konrad: need XML Core to allow nesting of XML, e.g. no prolog etc

jeff: using for protocols is different use case than docs, sign before sending to receiver

jimmy: how aboutnamespaces?

jeff: well, we don't care.

jimmy: has to be processed in context of original XML

mike: Why not PKCS#7 detached?

<bhill> re: PKCS#7 - average Web-era developer doesn't like ASN.1

<bhill> XML is successful and text wrangling is simple in any scripting language

cantor&hodges: this is for an as simple as possible use case
... point is, people tend to back off from XML Signature in certain use cases ...
... perhaps find a common way for the very simple cases ...

mike: well, there's a simple library, and then there's been 90% of the way to an XML Signature gone

sdw: want to emphasize that there are a number of different situations where you just simply...
... want to encrypt a blob ... or sign it ...
... and be able to validate later without necessarily having complexity ...
... not only protocol-like situations (WS being a good example) ...
... but also in cases where you have sth that resembles more a traditional signed document ...
... store in a database, that way, archival ...

scott: what may be needed to solve my problem is basically a lot more ID attributes than schema (?)

scott: more id atttributes in xml sig schema might be helpful...
... there is room for improvement here for the ID attributes ...
... with more of these, a lot of referencing is likely to become possible ...

konrad: xml:id?

scott: might be a rationalization here
... if I want to say "this key is the same as that key", ...
... looks like you need to reference keyInfo and then find the child with XPath ...
... which seems to be a heck of a lot of work ...

konrad: historic context -- at the time, wary of using mechanisms, hence "reference + transform" element

<tlr> (unminuted discussion about xpath vs id attributes)

scott: standard minimal version of xpath?
... preferably not implement the whole pile of work ...
... all of this is begging the question: ...
... ought to be standardized profiles for different problem domains ...

Ed: ID is simple, but flawed for apps. XPath can be complicated but applications, including XML Signature, can profile its use for specific uses.

<bhill> +1 for minimal XPath

<tlr> ... without standardized profiles for specific problem domains, a bit too much ...

<sdw> We called our implementation of "Simplified XPath" Spath.

<tlr> sdw, is that publicly visible anywhere?

<sdw> Not currently.

<esimon2> I am interested.

Discussion and summary

<FH> basic robust profile

<FH> bulk signing - blob signing

<FH> use specific?

<FH> metadata driven implementation

<FH> brad - like policy

konrad: can this be done with / expressed as a schema?

FH: policy implies a general language vs. a hard/closed specification for a profile

tlr: difference between runtime and non-runtime profiles

<esimon2> I believe the next version of XML Signature and XML Encryption should have an attribute designating the profile. I have also pondered whether this should not even be in XML Core.

tlr: implementation time avoids unwanted complexity - teach how to do this with use case examples

scott: implementers want to build a general library and constrain behavior, rather than many implementations

phb: profile reuse: catalog, wiki

michael leventhal: robust is misleading, ease more important than flexibility, more performance and interop fundamentals over flexibility

jz (?): keep spec understandable and as short as possible

brad: be able to limit total resource consumption even in languages like Java and .Net where platform services to limit low-level resource usage do not exist

konrad: some of these issues belong to Core, not just XML Security

fh: need to support scripting languages like Python

bhill: implementation guidelines to partition attack surface, order of operations

tlr: wrapping countermeasures

eric: possible to make it easier to verify than to sign?

konrad and jimmy: what is the scope/charter?

tlr: exploring interest, from profiling to deep refactoring

fh: how to really do see what you sign?

hal: processing model vs. structural integrity protection

tlr: id based vs. structure based approaches. how do they fit together?

scott: middle ground?

hal: remove troublesome features vs. educate on risks

tlr: tactical vs. long-term concerns

scott: id has lots of problems not discussed today, e.g. id uniqueness in the context of protocol layering

scott: has been said that "id-ness" is impossible without a DTD

<ht> http://www.w3.org/TR/xml-id/

scott: xml world needs to get on same page about what an id means (tlr: vs XPointer barename)

<ht> http://www.w3.org/TR/xptr-framework/#shorthand

hal: uniqueness, id in content so add/remove can break signature, positional attacks

scott: how to know what is an id

ht: spec exists now, didn't at the time

ht: can provide a way to re-ground XMLDsig in what an id is

ht: clause 4: sometimes an id is externally known (app specific, e.g. XHTML)

scott: what people want is layered, independent processing. not possible

jimmy: put id issue into overall context of other xml working groups - need broader analysis of big picture

jimmy: xml is a tree, not a list, id considered harmful

<bhill> scott disagrees, tlr kills as rathole - how to do ids without whole id-ness thing, specific XPointer type?

scott: ids defined as signature metadata - this is an id in signature context

konrad: uniqueness problems?

ht: uniqueness of ids not a well-formedness property, only a property of validation

<esimon2> Ed: Can use ID where the "tree-ness" of XML is not important (often is important). Where tree-ness is important, one needs a tree language --> XPath (perhaps profiled).

ht: XPointer defines what a pointer means, doesn't require validation, therefore not an error if not-unique. Pointer foo is the first foo

<ht> Note that we are all behaving, as we have for years, that ....#foo identifies the XML element with identifier foo, but this is strictly speaking not true until RFC3023bis comes out :-(

<esimon2> Can use Xpointer and ID together (e.g. /Signature/Object[@ID='obj1']

eric: annotate attribute to tell processor what an id is

<esimon2> Sounds like xsl:key in XSL

michael: would change how xml works outside of scope of signature, hard to get apps to play along

konrad: best practices guidance? use xpath for dereferencing instead of doing transformation

<klanz2> use xpath transformation, allowing in some best practices for an xpath transformation to be treated as if it was dereferencing an ID according to the xpointer framework not having to change the current xmldsig spec

fh: key retrieval management, KeyInfo underspecified, difficult to use

fh: do people understand it?

hal: have a reasonable way to handle naked keys as a single binary/b64 value vs. self-signed cert

hal: (was speaking on behalf of scott, who has left)

<MikeMc> I suspect Scott's issue would be address by adding a new <RSAKeyValue><PEMValue>

tlr: nsa suite b, randomization [ rsa-pss, rmx ], mandatory algorithms

tlr: important - what's next after SHA1?

tlr: dealing with mandatory algorithms as they fail, changing defaults over time

phb: XKMS for symmetric keys? ready for the quantum computer PKI doomsday?

phb: adaptations to make XKMS like Kerberos, need to specify subject/target tuples vs. just target

konrad: define future altorithims in style used for RSA-PSS

fh: key-length issues?

scott: protocol to re-encapsulate/re-encrypt broken cryptosystems

various: long term archival issues, DSS, LTANS, XADES

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/10/17 21:42:31 $