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