XML Security Working Group Teleconference
02 Sep 2008


See also: IRC log


Frederick Hirsch (fjh), Ed Simon (esimon2), Thomas Roessler (tlr), Sean Mullan (smullan), Rob Miller (rdmiller), Juan Carlos Cruellas (jcc), Scott Cantor (scantor), Chris Solc (csolc), Hal Lockhart (hal), Shivaram Mysore (shivaram), Brian LaMacchia (bal), Pratik Datta (pdatta), Kelvin Yiu (kyiu), Bruce Rich (brich), Konrad Lanz (klanz2), Gerald Edgar (gedgar), Magnus Nyström (magnus)
John Wray
Frederick Hirsch
Brian LaMacchia


<trackbot> Date: 02 September 2008

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0003.html


fjh: upcoming scribe assignments...

Reminder: no call on 9/30 or 10/14

fjh: next f2f is at TPAC in Cannes, FR.
... hotel deadline 9/8.
... registration deadline 9/30

<fjh> agenda http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0003.html

<fjh> TPAC Overview: http://www.w3.org/2008/10/TPAC/Overview.html

<fjh> Schedule: http://www.w3.org/2008/10/TPAC/Schedule

<fjh> f2f questionnaire http://www.w3.org/2002/09/wbs/42458/xmlsecearly2009/

fjh: please answer the questionnaire about potential dates for Jan/Feb f2f

RESOLUTION: to approve minutes of 8/26


<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0030.html

fjh: there is a way in schema 1.1 to indicate that you're going to put wildcards everywhere
... "default open content" -- thinks that what would allow adding a sig later to the document

<fjh> http://www.w3.org/TR/xmlschema-guide2versioning/#openContent

fjh: will follow up w/ david

scantor: schema thing is interesting, doesn't change the attribute/xml:id issue
... another point is that wildcard feature is interesting, but from SAML experience there's some resistance to generic wildcards
... proposals to relax schema that much wasn't well received in SAML TC (perhaps because of security focus)
... doesn't fix problems with ambiguous content models
... biggest problems in the past have been with schema normalization

<esimon2> Agree with the concern over using wildcards -- rather Signature/Encryption be specifically allowed or disallowed.

scantor: implementers of DOMs have had problems
... issue opened regarding schema normalization, not sure if it's the same
... as this problem

klanz: on wildcard processing: there's an attribute describing how to process the wildcard
... agree that wildcards are usually not preferred by implementers

<fjh> klanz noted strict requires other schema present for validation, lax tries to find, skip does not proces wildcard content

klanz: tend to throw exceptions on downlevel

<fjh> if application anticipates signing in workflow then can anticipate by putting signature element in schema definition

klanz: ambivalent about wildcards overall

<Zakim> Thomas, you wanted to ask if this is an implementation or a spec issue?

Thomas: how much of this is a specification issue vs. an implementation issue?
... sounds like part of the defined behavior of wildcards would explicitly modify DOMs and thus break signatures
... question of how this needs to be addressed & where
... also though I heard that a lot of implementations won't support wildcards

<fjh> klanz noted some implementations will not support wildcards - implementation conformance question

klanz2: was talking about high-level applications
... profiling down done by particular applications

<fjh> klanz noted for profiling down of extension points

<scantor> the schema spec requires "normalization" of text nodes, which breaks signatures unless applications work-around the problem, or a special transform is used

scantor: was referring to a spec issue
... comes down to what implementations do to make themselves implementation-friendly
... some implementations give you option to ignore that part of spec, or store both normalized and un-normalized forms

<klanz2> +1 to schema normalization transform

scantor: IBM proposed a schema normalization transform

<klanz2> as it would allow, signers to tell if they normalized or not ...

Rob Miller: regarding wildcards and schema, USG is looking at cross-domain sharing of information

scribe: example sharing information between a SECRET network in one domain and a TOP SECRET network in another domain
... one way they try to contain information leakages is to constrain the schema and then perform schema validation on the boundary

<pdatta> is there a link to the schema normalization transform

scribe: thus, wildcards aren't really useful in that scenario
... not a specification issue in their scenario, more of an implementation issue
... also has scenarios where one party stands up data & schema in one domain, doesn't think about sharing initally, then needs to share later
... says one of his XML people claims you could also look at the problem as a "compound document" problem.
... and use NVDL?

klanz: question for Rob -- do you also use extension points?

Rob: has been some talk about that, but doesn't think it's something used widely


XProc pipelining

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0030.html

fjh: looks to me that the work of the XProc WG would be relevant to this WG
... might play 1-2 roles. we might be able to leverage what they're doing in V.Next.
... they will need to take account of signatues
... treated as infoset processing pipelines
... no concept of security processing in the document, starting to talk about it on their mailing list
... could think about signing portions of a pipeline
... they have a use cases/requirements document, includes one signing scenario but that didn't have any signature verification
... will send out some more material on XProc

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0042.html

<fjh> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Aug/0097.html

fjh: they define an encryption step
... XPath 2.0 is essential & required for XProc, may be some security issues here

Signature & Canonicalization Requirements

fjh: senses there's a new direction in the W3C toward Schema 1.1, XProc, etc.

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html

fjh: had some comments last time on adding some section to this document

Magnus: looked at the doc,
... should we broaden the scope to include encryption?
... we need to include encryption requirements

<tlr> +1 to unifying the document to include encryption, in particular as far as ds:keyInfo is concerned

fjh: it should also include keyinfo

<bal> +1 to including encryption & keyinfo also

fjh: charter permits it, but not sure how much we'll do on encryption

tlr: useful to include additional design notes in the doc, need to be careful about how much we commit to at the end of the day

<fjh> our charter clearly allows requirements work on xml security, specifically signature and encryption, but we are also limited by charter to how much we can do on v.next for encryption

tlr: we don't want to run out of energy before we get through everything we've listed as a requirement

<fjh> +1 for requirements on keys and keyinfo

fjh: thinks we can add that in, just wants to be careful how much we commit to for v.Next.
... are we OK with what we have so far as a draft?
... are we OK with the text in the doc? are we just accepting the doc for a checkpoint?

<tlr> gosh, no, that's not close to being final acceptance

shivaram: wants to note that he's started to take a look at the doc and is planning to make some updates by the end of the week

fjh: we've agreed to section heading changes
... we normally agree to changes in the meeting first, then update the doc

shivaram: plans to take comments from the list, integrate into the doc, then let people look at the edits in the doc

fjh: if we edit in place, then we'll need two version: draft and approved

shivaram: we could take one section at a time, iterate on it on the list until people agree

Derived Keys

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0064.html

magnus: follow-up from presentation at the F2F about the use case for KeyInfo with derived key types
... one comment received concerned existing use of derived keys in certain WS-* specs
... and how this proposal relates
... looked at the WS-* specs & associated requirements
... and how well they match against the proposal
... conclusion that WS-Trust & WS-SecurityPolicy not really affected.
... WS-SecureConversation is more interesting
... could in principal make use of the proposal instead of introducing a new token type (as it does)
... proposal like this would have use in real environments
... summary is that keyinfo should be extended to include derive key types

fjh: people should look at this proposal now, we can discuss next week
... no suggestion that WS-SC would change to use this new type, but it provides a concrete use case

magnus: correct
... no suggestion of changes to existing WS-*

<fjh> bal notes that in general being able to tag a derived key is probably a good idea

Long-term Archival

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0001.html

csolc: asked to take a look at the assumptions of long-term archival of signatures
... high-level assumptions first: in the archival world, have to assume that every signature is time-bound and will eventually be unverifiable
... hash function will be broken, algorithm ages/broken, etc.
... people migrate from one digital format to another (often to a standard archival format)
... migration could happen before or after signature generation
... must be able to add supplementary validation information after the document is signed
... incremental validation, ability to add information
... ability to counter-sign portions of the document
... archival service might be the counter-signer for example
... validation chain must remain available for the lifetime of the doc

<gedgar> I have to leave for another meeting, I will be here to scribe next week.

jcruella: some archival formats include space for indicating when the original signature occurred
... can include all the information used to validate the original signature (eg certs, revocation information, original timestamps)
... and then add a new timestamp attesting to the process that the verifier went through
... so sometimes you want to archive the validation information and the fact that validation occurred, as well as signature generation
... have to deal with algorihtms ageing
... put all the information into the supplemental information that then gets timestamped periodically to refresh the overall document
... example: re-generate an archival timestamp every year
... content signatures are also included in the specification

csolc: XAdES does cover a lot of this

fjh: some of the requirements from archival signatures do get directly imported into our work because they're broadly applicable.

jcruella: understand that these are common requirements

fjh: think the question is about scope of our WG?

jcruella: we need some way to have long-term signatures

fjh: there are some high-level requirements we have
... we also must have a usable signature when we're done. not suggesting that we rework XAdES, but just have to make sure that what we import has broad applicability
... what we do need is to look closely & figure out exactly what we do need to import into the core spec
... we can't forget about the core requirements

hal: sees the requirements driving two separate processes
... 1) specs should at least permit and, if possible, optimize, meeting the various requirements we agree on
... 2) in some places where we see things being done over & over again (e.g. derived key) it may make sense to standardize those applications & import into the core

hal: would like to see all the requirements on the table even if conflicting

klanz2: on XAdES, within ds:Object there is ds:QualifiedProperties. if we don't change QualifiedProperties there shouldn't be much harm
... when there are changes to the core specification, XAdES folks will need to look at the impact on XAdES and report back to the group
... some language that refers to processing model & distinguished names, so we'll need to review

Transform processing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html

pdatta: some ideas about performance in transform processing
... some people don't actually check what was signed
... also need a streaming requirement
... should distinguish between "selection transforms" and "canonicalization transforms"

<fjh> pratik noted need to add support in spec to verify what is signed, see what is signed, by reviewing output of what is signed, selection transform

pdatta: has grouped existing transforms into these two buckets

<csolc> fjh did you want to overview workflow signatures.

pdatta: need to limit the transform sequence
... once you have a canonicalization transform, you can't have any selection after that
... once you base64 or c14n, can't select any more

<smysore> Apologies, I have to leave

pdatta: only one xpath transform
... only one enveloped sig transform
... haven't found a use case that extends beyond these limits
... also should use simple xpath
... add two pieces of info: an included & excluded xpath
... only get one included & one excluded
... also restrictions on the types of xpath you can have in included & excluded
... based on streams
... suggesting an even more limited xpath
... to match limitations of streaming

<klanz2> what about, the here()/id() function

pdatta: those are the three sets of changes
... streaming is easier to do

klanz: one current spec that uses c14n in the middle of the chain

<csolc> is there a requirement for streaming to have the signature at the begining of the document?

klanz: DSS (OASIS spec) canonicalizes to transmit the doc so it can be parsed again

<fjh> klanz notes that cannot simply pass selection, have entire doc underneath

klanz: is it possible to split the chain of transforms between client & server processing?

pdatta: needs to look at how DSS uses it, but C14N is just used to compute the digest

klanz: might use exclusive C14N to get a well-defined subset of the document
... should be possible to stream node-set data
... this part of DSS isn't being used yet, but designed for signing GBs of XML...

pdatta: not sure he understands the scenario, can we get details in e-mail?

klanz: uses exclusive-c14N

fjh: a message to the list would be helpful
... goal of ordering the transforms was to avoid octet-stream/node-set conversions

pdatta: no, goal is to identify what is getting signed

<klanz2> http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc159076035

<klanz2> <TransformedData>

<brich> i got a copy of Pratik's proposal

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html

<esimon2> I sent an email re Action-22 about an hour ago to the public list; I know Thomas received it.

csolc: is it a requirment or recommendation that the signatures should be placed up front in the document

<fjh> bal and csolc noted that they did not receive the email for Pratik's streaming item even though they received v2 agenda from the public list.

bal: usually you'd want it up front to avoid two-pass

<fjh> bal noted that in first wg assumption that what would be signed would be small, hence all could be kept in memory

bal: that was assumed to be the common case, anyway

Workflow Scenarios

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0002.html

csolc: data being routed through any workflow is expected to change
... data is expected to be reserialized out at different points in the workflow by different technologies
... signatures have different purposes
... during a workflow your protocol may not be secure
... lifetime of data w/in a workflow is non-determinisitic
... location of data & signature may be significant
... typically there are designated locations for signatures in the workflow, so that the next component knows where to look
... validity of a signature can effect the decision process within a workflow
... requirements include multiple sigs, counter-sigs
... depending on purpose of the signature, some changes might invalidate sig, some changes might *not* invalidate sig, some might just cause warnings
... ability to store metadata along with the signature

fjh: 2 questions. 1) what's the granularity of the workflow?

csolc: there's a portion of the data that's expected to change

fjh: 2) didn't quite understand the warnings vs. invalidating the signature change. why would it be acceptable to break in some cases?

csolc: you can have content that is allowed to change

fjh: you've recorded an updated to the data (refreshed it, for example) and that invalidates the old signature

V.Next Tags

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0019.html

fjh: message on public comment mailing list saying we could make the signatures shorter by eliminating end tags
... response that it wouldn't work because it would mean the output would not be xml

Best Practices

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0054.html

scantor: what should a verifier do? two issues
... 1) incorrect reference to PKIX RFC, but probably just pull the reference b/c it's not relevant
... is the best practices document going to proceed in parallel as a separate document?
... would like to see schema fixed to allow retrieval method to work
... 2) retrieval method: people want to use retrieval method to point to another cert in a document. But to point to another element in the doc the advice is to use xml:id. But there's no id on the certificate
... so you'd have to use transforms to get inside the element.
... which seems wrong and we should fix it.

<klanz2> Re Streaming and DSS(-X):

<klanz2> http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc159076076 :

<klanz2> ... If the document is inside <InlineXML> the document is extracted using exclusive canonicalization.

<klanz2> klanz2: This is usually at the beginning of the chain of transforms.

<klanz2> http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc159076071:

<klanz2> the EnvelopedSignatureTransform would not work if there was a Canonicalization before it. Similar problems apply to transforms using the here() function. If such are to be supported, the use of Base64XML or EscapedXML MAY be required.

<klanz2> klanz2: "ISSUE" is the here() function defined past a Transform returning OctetstreamData

<klanz2> http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc159076035

<klanz2> <TransformedData>

<klanz2> klanz2: This Form of DSS Payload allows to take any prefix of the chain of transforms that returns an octet stream and is therefore to be able to go on wire.

<klanz2> http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc159076059 :

<klanz2> Processing of <TransformedData>

scantor: assume that the overall confusion around id's caused some of the initial confusion
... most of the rest of the doc looked ok, tend to focus on keyinfo

fjh: folks probably need some time to look at Scott's doc & then discuss and put a proposal on the list.

<fjh> ACTION: pratik to review comments from Scott and propose document change, http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0054.html [recorded in http://www.w3.org/2008/09/02-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-53 - Review comments from Scott and propose document change, http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0054.html [on Pratik Datta - due 2008-09-09].

Completed Actions

fjh: regarding ACTION-12, don't recall what we were trying to achieve with this action.

jcruella: there were a lot of e-mails on this topic, maybe a suggestions by Thomas that something could be done to clarify the relationship
... we could open an issue on this if you like

fjh: sounds like a good idea. We need to clarify the text on what "type" means

ACTION-12 Closed

<trackbot> ACTION-12 Review archive from maint. group to revisit type issue closed

ACTION-25 closed

<trackbot> ACTION-25 Give feedback on xml schema best practice in xml-cg closed

<klanz2> Re Schema and Wildcards: http://www.w3.org/TR/xmlschema-1/#Wildcard_details

ACTION-34 closed

<trackbot> ACTION-34 Set up questionnaire for next meeting closed

fjh: please fill out the questionnaire

ACTION-40 closed

<trackbot> ACTION-40 Solicit and contribute long-time archival requirements closed

ACTION-41 close

ACTION-41 closed

<trackbot> ACTION-41 Solicit and contribute requirements and assumptions from workflow scenarios closed

ACTION-44 closed

<trackbot> ACTION-44 Send email on ordering and layering of xml signatures closed

ACTION-46 closed

<trackbot> ACTION-46 Arrange CVS access for Brad Hill closed

fjh: <reviewing open action items>

ACTION-5 closed

<trackbot> ACTION-5 Check how the formal OASIS liasion is working. closed

fjh: discussion of ACTION-22 (review of EXI docs)

esimon2: sent a message to the mailing list during the first half of the meeting

fjh: we might want to have primitives defined in EXI for signature & encryption?

esimon2: wouldn't be acceptable in actual implementations to use "normal" XMLDSIG within EXI docs. So people might not want to create a full-blown "normal XML" signature
... question will come up "how do I create an EXI-compliant" signature (in EXI format)?
... all sorts of interesting complexity.

<pdatta> I need to drop off

<klanz2> http://www.w3.org/2001/xml.xsd

scantor: top-level attribute types aren't necessarily legal

<scantor> the issue is that attributes may exist but are only allowed to appear in an element if the element's content model says they can

fjh: reminds Rob (and everyone else) about open action items
... any other business people are concerned about?
... think we're ajourned

Summary of Action Items

[NEW] ACTION: pratik to review comments from Scott and propose document change, http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0054.html [recorded in http://www.w3.org/2008/09/02-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/09/16 13:55:13 $