See also: IRC log
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
<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
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: 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.
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)
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
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
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.
<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.
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
<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.
<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