See also: IRC log
Date: 12 May 2009
<trackbot> Meeting: XML Security Working Group Teleconference
<trackbot> Date: 12 May 2009
Scribing 12 May am - Sean, pm Gerald
Scribing 13 May am Brian, pm Pratik
Scribing 2 June Magnus
< fjh:> next mtg june 2
<tlr> new wg chartering new apis
<tlr> public-device-apis@w3.org
<tlr> http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/
RESOLUTION: minutes 5th May approved
http://www.w3.org/2009/05/05-xmlsec-minutes.html
add best practices to avoid xslt extensions and to prefer XPath Filter
<fjh:> updated best practices draft
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0008.html
<smullan> ACTION: magnus to update derived key draft to point to schema [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-278 - Update derived key draft to point to schema [on Magnus Nyström - due 2009-05-19].
http://www.w3.org/2008/xmlsec/wiki/RoadmapandPublicationStatus
<tlr:> before proposed draft need to show interop
<tlr:> tlr: call for impl at candidate rec
<bal> bal: can we jump to cand rec in july? enough impl experience?
<bal:> do we have 2nd wd then last call or just last call?
..... probably too many changes to skip 2nd wd
<tlr> "undisclosed location"
<bal:> need a draft before august
...go to last call in July, wd in June
< tlr:> interop needs to happen before proposed rec
summary, wg can have interop up to proposed rec, with stability as a risk
could have new WDs end of June, then Last Call end of July
additional interop in August/September
http://www.w3.org/2008/xmlsec/wiki/RoadmapandPublicationStatus
<tlr:> pull publications of WDs into early-mid June
... tlr needs stable drafts first week of june
<bal:> keep 1.1 docs separate from 2.0 docs
<tlr:> during next 2 weeks get necessary changes in
... prepare for publication ...
... ... use june 2 call to ratify changes
... ... leaves a week to prepare for pub
<fjh:> fjh: sounds like a good plan
Plan - agree to changes for 1.1 at this F2F, implement changes in next two weeks
Approve implementation of changes on 2 June and make publication request on 2 June
adjustments if needed by email or 9 June
publication 11 June or 16 June.
publication is WD
then Last Call end of July
defer some interop until August, eg JDK 7
< pdatta:> added some ECC test vectors
<fjh:> fjh: signature properties updated
... widgets signature in last call
<scribe> new wd of signature properties was published
http://www.w3.org/TR/2009/WD-xmldsig-properties-20090430/
http://www.w3.org/2008/xmlsec/wiki/Interop
<smullan> ACTION: pdatta to create interop matrix [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-279 - Create interop matrix [on Pratik Datta - due 2009-05-19].
Sean summarizes status of interop, tested new algs or those who changed status
some testing of ecc but not everyone [has tested]
no testing of ocsp, raw der encoded key, plan to do
rsa sha 2, hmac sha 2 3way success and c1n10 or exclusive
two way on c14n11
two way on ecc algorithms, but not key value format. only named curves
tlr: 2 impls is formal criteria
fjh: would be good to get other impls
tlr: purpose of interop is to have an agreed set of mandatory algs
<scantor: > if c14n 2.0 is changing, hard to justify implementing 1.1
... produce more test vector coverage instead
<fjh:> new c14n could be viewed as big improvement but mostly compatible - can we swap it into dsig 1.1?
<Scott:> attractive but may not be true with most impls
<klanz2> well inclusive is used implicitly, so hard to be dropped after all
<fjh: > issues with some impls not supporting c14n 1.1
... could we include new c14n in dsig 1.1?
... but probably doesn't make sense so will stick with original plan
scott asks that we produce test vectors for both 1.0 and 1.1 to encourage testing
also mentions confusion with new 4050 syntax
sean produced tests for both 1.0 and 1.1 c14n
Scott: may get wider testing with c14n 1.0
konrad may be doing interop a bit later as well as scott
<fjh:> covered all 3 variants of c14n
... what about key sizes? should we say anything?
; <fjh:> widgets draft requires key to be min 2048 bits unless signature lifetime is less than year
; <hal:> might be better to specify in different doc
scantor: maybe best practices doc?
issue: provide recommendation regarding key length for signature a la widget signature, either in signature 1.1 or best practices
<trackbot> Created ISSUE-121 - Provide recommendation regarding key length for signature a la widget signature, either in signature 1.1 or best practices ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/121/edit .
<sean> notes that better to test longer key lengths in interop testing, to detect problems
< pdatta: still need to do the EC key Values for interop testing
<smullan> ... what key lengths do we want to interoperate on? done 2048 and 1024, how about longer?
bal: ECC tests complete with old key value format, so algorithms are correct
fjh: what about encryption - we need test cases if we want to put out drafts at same time
bal: rfc 4050 compat is done
... exc c14n is done
<smullan> aes keywrap with padding still in progress at ietf
<smullan> derived key magnus to produce test cases, testing in ietf
<smullan> ACTION: magnus to produce test cases for derived keys [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-280 - Produce test cases for derived keys [on Magnus Nyström - due 2009-05-19].
fjh: plan to publish enc and signature 1.1 at same time
bal and pdatta need more time to check if they can interop for encryption 1.1
klanz to interop in July or earlier
interop testers are checking on when they might test the new XML Encryption algorithms
AES Keywrap with padding (XML Encryption) still in Progress in IETF
RFC4050 compatibility and Exclusive C14N included in interop completed to date
scantor asks if we can address schema validation issues for 4050
<scribe> new type is ECKeyValue
ECKeyValue vs ECDSAKeyValue
scott: thinks we would rather not see spec reference rfc 4051
pdatta: question for interop is should we test both or only one
current test vectors use old key value format
scott suggests we need to test with new format
<tlr> +1 to test with new format
<magnus> +1 for testing with new format.
pdatta still to produce some ECKeyValue signatures
Opinions that we are ok with what we have to go to next WD
tlr: concern if nobody has implemented some optional features
... for going to rec
... can go to last call
AES keywrap testing maybe by year end, but possibly longer
pdatta: EC signatures toolkit generated ASN.1 encoded signatures
<bal> that's correct. See section 6.4.3, the two values in the signature (r, s) are just concatenated & base-64 encoded
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0007.html
scott: key point what the optimization points are and many impls have done that
... if you can define alg that covers the common uses cases don't need optimizations
try to find an old apache impl without optimizations that we can use to compare performance numbers
scott notes should say that can implement spec without looking for edge optimizations rather than earlier spec
scott notes should detail rationale and changes
ACTION: sean to try to find an old apache impl without optimizations that we can use to compare performance numbers [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-281 - Try to find an old apache impl without optimizations that we can use to compare performance numbers [on Sean Mullan - due 2009-05-19].
issue: explain why performance improvements and rationale, relationship to earlier
<trackbot> Created ISSUE-122 - Explain why performance improvements and rationale, relationship to earlier ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/122/edit .
fjh: should decide that we should produce new c14n spec today
scott: one of the work items was to change the whole way c14n was expressed
fjh: sees pratik's proposal as a new version of c14n
scott: wasted effort to produce a new spec aligned with old model?
pratik: one approach is to constrain existing alg , other approach is completely new syntax
fjh: 3 things on table: 1) use subtrees, 2) transform simplification, declarative syntax
... 3) use existing transform model profile and constrain so you end up with what 2 is trying to do
new algorithm would be written with respect to abstract parameters (e.g. excl vs incl) and then we would make it concrete later once the signature syntax is finalized
bal: 4) stream the bytes out and don't worry about them changing on wire
agreement to generate performance numbers for naive implementation
scott: understand the edge cases but is someone standing up for them?
bal: has never really seen anyone ask for signing arbitrary nodesets
konrad: thinks nodeset boils down to this node is in this node is out, problem lies more in esoteric nodesets
... what it boils down declaring which parts of the document belongs in nodeset or not
fjh: can we go with pratik has proposed?
konrad notes that a change could harm existing implementations, hence prefers nodesets
<tlr> fwiw, there's a C# implementation
konrad: abstract away from nodeset model use lists ...
scantor notes that there are very few implementations
sean notes existing implementations will continue to exist, not an issue for transitioning
konrad: list of elements, which attributes should be in/out is more powerful
<esimon2> I would like to see XML Signature and XML Encryption implemented in other languages than C* and Java but one also has to compare with what's happened with PKCS.
scott: are you saying a set oriented model would be powerful and easier to implement than nodeset
konrad: granularity should be on element
... shouldn't lose namespace context
konrad: use case was on mailing list
konrad: ebxml
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0008.html
<klanz2> <Reference URI="#xpointer(//*[@authenticate='true'])">
pratik: ebxml can work with only subtrees
<klanz2> just do this with an XPath Filter
scott: large documents is an issue with arbitrary nodesets
requirements - performance in common cases, implementation simplicity, minimum dependencies, streamability
need for supporting edge cases is not clearly supported
konrad argues test on each node for selection
pratik: making list and running thru list is expensive
konrad: easiest thing to say input to c14n and each node is in or out can be derived from trees or lists
discussion of suitability of tree walk using test function on each node
sean asks about iterators instead of nodesets
<klanz2> +1 to iterators on the granularity of an element and namespace nodes and inheritable attributes will always be returned
<klanz2> then there could be a sub iterator for "standard" attributes
konrad: konrad: iterators allow you to do scoping, lists, xpath expressions
konrad suggests we can define generic iterator construct that can then be profile with regards to test function, e.g. xpath filter, subtree etc
fjh: how do we change pratik's model with this concept?
konrad: doc input, output iterator
pratik notes that with exclusions there would be unnecessary walk
pratik: do we have to iterate over whole doc to get to the test used in the iterator?
... need to find out what is signed, subtree model solves that
scott: yes as long as we remove xslt
tlr: xslt is optional feature, discussing step that would take away using xslt, result would be signing
transformation input
<klanz2> what is persistent
if your processing is based on transform result, that is only thing you should ever depend on
<klanz2> the output is transient
<klanz2> is the displayed XSLT output in Explorer/Firefox persistent
<klanz2> or is it transient
<klanz2> @tlr, what you say is true when you deploy the XSLT implementation signed with the signature
<klanz2> I consider it infeasible to deploy XSLT proc with every signature
<klanz2> I don't quite understand why we mix XSLT with C14n?
<klanz2> I mean the discussions
<klanz2> the problems are independent
<klanz2> \//*[@authenticate='true']
tlr: xslt is octet stream only transform
<klanz2> you could intermingle data, with other data
fjh: is this just a counterexample
hal: redaction is an important case
konrad: xacml assertions can be scattered across document
<klanz2> displayable data
scott: ability to come up with new ways to sign things is goind to be undermined by retaining xslt support
<klanz2> are we talking XSLT or C14n now ...
scott: need to solve problem of what is signed, pratik's model solves that, konrads' doesn't
bal: xml dsig is an xml format of a signature
pratik:xslt know what it does, can make assumption if known xslt
<klanz2> how do you translate a value "true" to a value "wahr" without XSLT
fjh: lets just think about c14n
<klanz2> Let's go back to C14n that's a good idea
can translate to different languages in dsig at the moment
<smullan> can use a manifest and only process one
<scott: > scott: whole issue with c14n proposal keeps coming back to selection
fjh: if selection allows more flexibility than more complexity
scott: debate over selection is another topic
<klanz2> ;-)
fjh: pratik has proposal to improve model of c14n to improve performance
<tlr> (a) do we need a transform model that can deal with octet-streams
<tlr> (b) what is the complexity that we need to enable in transforms of nodesets
<tlr> a list of non-overlapping subtrees
Scott: ... set of subtrees can be viewed as set of c14n steps
scott: can't express c14n alg w/o understanding selection model and how it applies
konrad: disagree, can start at root and iterate
scott: you can separate c14n from selection because the input is a nodeset
<klanz2> Xpointer ;-)
<klanz2> a node set is not as arbitrary as it might seem to be
scott: unless you define c14n only on element then questions remain about selection
<klanz2> http://tools.ietf.org/html/rfc4051#section-2.3.1
<klanz2> [RFC3447],
<klanz2> section 8.1.1, -> should be 8.2.1
break lunch for 45 min
<Gerald-e> SCRIBE: Gerald Edgar
<Gerald-e> SCRIBNICK: Gerald-e
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0021.html
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0013.html
an example in the appendix, the XML signature object example, go to the XML sig specification, one of the examples contains meaningless information
http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/
http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/#sec-Object
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-Schema
Simon: in Section 9 - examples so called valid example the XML object example link - this is not an example. the cononicalizetion algorithm is incorrect
... the c14n algorithm needs to be updated in this example. This example is using a transformation "#null"
... this example was completed before version 1.0 of the specification
Fredrick: proposed a resolution to remove this example
RESOLUTION: to remove this example as proposed by Ed from 1.1 and write errata for the second edition
ED: a proposal for a link to a directory of examples
Brian: to pull DTDs from the specification
<esimon2> Specifically, I propose linking to a folder of non-normative examples.
RESOLUTION: to remove DTD definitions and related information from 1.1 and the second edition
Brian: to change section 9 to use Schema
RESOLUTION: remove examples and RDF from section 9 and rename section for schema only
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0018.html
Fredrick: add SHA256 to Second Edition , to add it into the second edition.,
Thomas: an errata can be proposed to be included or an errata can be normative
Thomas: it can be part of the review process or it can be a new feature
... a proposal to include SHA 256 at a proposed change. Errata as a preview of what will be in 1.1
Magnus: this does not have to be identical with 1.1
proposed resolution - the WG agrees with adding a 2nd Edition XML Signature proposed erratum item for SHA-256, wording to be agreed on the list
RESOLUTION: the WG agrees with adding a 2nd Edition XML Signature proposed erratum item for SHA-256, wording to be agreed on the list.
<magnus> Some suggested text for 1.1:
<magnus> SHA1 (Only when compatibility with previous versions of this specification is a requirement; SHA-1 SHOULD NOT be used when there is no such requirement)
<magnus> This specification defines several possible digest algorithms for the DigestMethod element, including REQUIRED algorithm SHA-256. Use of SHA-256 is strongly recommended over SHA-1 because recent advances in cryptanalysis (see e.g. [SHA-1-Analysis]) have cast doubt on the long-term collision resistance of SHA-1. Therefore, SHA-1 support is REQUIRED in this specification only to support interoperability with implementations of prior versions of this specificati
Brian: at this time SHA-1 is required, this would be deprecated
..?: for interoperability SHA-1 might be required
s/\?/hal
Brian: this indicates what should be developed. To use SHA-256
discussion of whether sha256 should be mandated and sha-1 not
hal suggests change to "use of SHA-256 or a stronger algorithm ...
Hal: a proposal that people should use SHA-256 or somthing larger or stronger
Magnus: to state that SHA-256 is required and SHA-1 is required only for backward compatibility
<tlr> so, the difference is "mandatory to implement" vs "recommended to use"
Hal: an implementation should not be required to implement SHA-1
?: There is confusion about what is required for implementations
There is confusion about removing SHA-1 and how this will affect applications using software based on implementations based on the standard
Magnus: to put in text stating that this is required but deprecated
recommended use sha256 for new signatures due to issues with sha1
exception is local policy decision
Thomas: this is mandatory to implement, but it is not recommended. Acceptance of SHA-1 is a local policy decision.
<tlr> 1. Implementation mandatory
also add text to best practice document
<tlr> 2. Use for signing deprecated
<tlr> 3. acceptance of sha-1 signatures is a local policy decision
Hal: this is a requirement for implementers of the spec. This i
Fredrick: we need to make a decision
RESOLUTION: keep
SHA-1 as Required due to compatibility required
... specify sha256 with all other schemes where we currently
use sha-1
... add note in best practices to build new applications to
avoid use of SHA-1
<tlr> s/mandate use/mandate implementation/
<tlr> second resolution is: specify use of sha256 with all other schemes where we currently use sha-1
<tlr> ACTION: thomas to check on state of DSA-sha256 [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-282 - Check on state of DSA-sha256 [on Thomas Roessler - due 2009-05-19].
<tlr> +1 to pushing out sha-1 from 2.0
<tlr> ACTION: thomas to update algorithm xref draft to note new status of sha-1 [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-283 - Update algorithm xref draft to note new status of sha-1 [on Thomas Roessler - due 2009-05-19].
issue: how in 2.0 to disallow SHA-1 when algorithm URI currently defined
<trackbot> Created ISSUE-123 - How in 2.0 to disallow SHA-1 when algorithm URI currently defined ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/123/edit .
magnus notes just not include in list of algorithms in 2.0
magnus notes even without 2.0 of encryption we may need to remove SHA-1 from Encryption 2.0
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0019.html
Section 6.4.2 of XML Signature defines the RSA-* signature algorithms,
but seems to refer to the ASN.1 BER algorithm designator for SHA1
regardless of the hash algorithm that is used.
RFC 4051 (from which we leverage the algorithm identifier and definition) asks for the correct designator to be used.
Thomas: in RFC 4051 RSA applied to padding applied to hash
<esimon2> Have to leave for the afternoon; back tomorrow morning.
<tlr> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/
<tlr> 6.4.2
Thomas: The question is what will be implemented and the test vectors.
"hash" is the SHA1 digest of the data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC
etc from text of 1.1 signature
Thomas: There is a question of ambiguity.
Brian: a suggestion to cut this section
<bal> I suggest we reword to something like this: The SignatureValue content for an RSA signature is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature scheme]. (And end it here, but update the RFC to the current RFC).
<tlr> Cut at "As specified..."
<tlr> Add sentence: "Computation of the signature will require concatenation of the hash value and a constant string determined by RFCfoo. Signature computation and verification does not require implementation of an ASN.1 parser ."
Brian: we had talked about this earlier.
<tlr> PROPOSED RESOLUTION: accept tlr's proposed rewording
<tlr> PROPOSED RESOLUTION: accept tlr's proposed rewording; update reference to RFC2437's successor
RESOLUTION: accept tlr's proposed rewording; update reference to RFC2437's successor
<tlr> magnus: note that "recognition of OIDs" might just be for the time being
bal notes new reference 3447
<bal> RFC 3447
<tlr> ACTION: thomas to implement resolution concerning SHA-1 OIDs in 6.4.2 of XML Signature [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-284 - Implement resolution concerning SHA-1 OIDs in 6.4.2 of XML Signature [on Thomas Roessler - due 2009-05-19].
TOPIC Algoritm cross reference
http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0062.html
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0009.html
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0010.html
Fredrick: The widget group agreed to include ECC in their spec.
<magnus> simon@josefsson.org (Simon Josefsson) on Monday, May 11, 2009 wrote: Certicom will, upon request, provide a nonexclusive, royalty free patent license, to manufacturers to permit end users (including both client and server sides), to use the patents in schedule A when implementing any of these protocols, including those requiring third party certificates provided the certificate is obtained from a licensed Certificate Authority
Hal: software vendors need to addess Suite B to address US Government customers
Brian: any signature that is generated with the Widget spec will be compliant with 1.1
... done...
Discussion of the release of 1.1
Fredrick: to publish 1.1 on 2 June, but there is still the issue of elliptic curve.
thomas notes there is opportunity for formal objection during document transition, including objection, rationale and remedy
he also notes that objection can be raised during AC review
<tlr> http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews
Discussion of the standards process and potential objections of including ECC with its potential IPR implications.
We will have a formal majority to move forward.
Fredrick: we need to move forward
Thomas: are people willing to formally object?
........ to make a decision on 9 Jume
Is ECC required? or is it should?
ECC needs to be REQUIRED for sussessful interoperability
question - whether people formally object to a must of ecc algs, formally object against a should
Thomas: The question is, will people formally object?
... the idea is to produce the docment and prompt responses and perhaps objections.
Queries of the positions on requiring ECC
<tlr> frederick: Will make decision on 2 June. Will circulate proposed resolution on list, give heads-up, so people can determine what their positions are.
frederick: note can stay till last call, if needed?
-- no objections --
<tlr> bal: note can't be in lc, but can stay in a second WD
Fredrick: no agreement at this time
Fredrick: can we accept what Pratik has created?
Scott: can we accept the selection methods?
http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
Transform simplification
declarative syntax of node selection
Scott: how abitrary is the capability to extract oft of an XML structure? how do we subset a document.
1. subtree inclusion, exclusion and reinclusion per pratik proposal
Scott: hot to exclude sections, and how to address text nodes (this is addressed as an element)
2. element centric test function
Scott: name space is in the context of the document.
discussion of node selection and sub trees
note that we agree on having context for namespace nodes, rather than copies in both
both proposals have this approach
inclusion of pratiks proposal has the benefit of avoiding unnecessary walk of other parts of document
function offers extensibility with pluses and minuses
scott notes function model seems simpler, since clear how function provided to each note
chris notes walking entire tree at end for serialization, walk anyway
Fredrick: using the declaritive aspects as a layer in order to optimise better.
discussion of whether able to optimize when using tree walk with fucntion approach
wg is seriously considering what konrad had suggested, comparing with subtree, reviewing
Hal: Use the original thinking of using w3c constructs. of a layered architecture
I suggest a declarative syntax could indicate intent which could then be implemented using lower level layer of either function tree walk or subtree approach or combination
this is getting abstract, how can we compare proposals concretely
pratik notes function approach is more complex, since it is open and not clearly and simply defined
Brian: Layering, to define a core, lowest level with no transforms
.... a larger layer that might include xPath
.... Brian is speaking of profiling the spec
layer no transforms, selection via subtree, funcion, xslt, custom transforms different profiles
scribe: but need to minimize attack surface
Scott: how do we simplify C14N?
Brian: how do we address everything that might be sent across the wire?
... how do we defend against XML rewriting on the wire?
Hal:<\cite> we are speaking of optimization in terms of software, we also need to address hardware.
and how well the specification could be implemented in hardware.
Scott: what are the parameters of C14N? What is the API for this function? do you address with nodes and node sets?
Sean: yes..
... can we have a single transform that addresses both C14N and selection of a subtree? we might optimize both?
Discussion of transforms and C14N as a transform
option is to make pratik's declarative proposal as single allowed transform in 2nd edtition transform model
this allows other cases to be handled with traditional transform chains, unless spec profiled to disallow
then this single transform allows significant optimization
proposed way forward:
1. use existing 2nd edition transform chain, perhaps augmenting Reference with attribute to indicate new version
2. Frame Pratik's proposal as new transform, if used MUST be only transform used.
3. if this new transform used then output is directly hashed, input limited TBD
4 this transform combines selection and canonicalization but no other transforms, that is removed from proposal
5 can use old transform model unless profiled out
6 provide profiles/conformance statements
input of new transform is none, all input is specified as children of the Reference element in the transform simplification proposal
hence would need two variants of ds:Reference or typed ds:Reference
current inputs of transforms are nodesets and octet streams
question, can we have a transform with an input that is subtrees
sean notes could have new transform take empty nodeset
or ignore input completely
I add
scott notes if we can avoid changing code that is good
sean preference for minor api changes
I believe konrad mentioned earlier defining new Reference element
so have ds:Reference ds2:ReferenceFast
<scantor> schema is http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/xmldsig-core-schema.xsd
<scantor> or not
wg thinks it can define a new schema that is backward compatible, maybe
proposal define new reference element with single transform implementing transform simplification
RESOLUTION: direction is to define new reference element with single transform implementing transform simplification
plus signed info, schema,
keyinfo cleanup
reduce attack surface, simplify implementation, improve performance, reduce spec dependencies
note that for references that meet constraints old ds:References could also use the new processing as if they were new references
without mandating change to the syntax as written
RESOLUTION: new signature specification for 2.0 includes all material, including new reference element and transform
question does w3c support conformance clauses for specification and minimum conformance
issue: does w3c support conformance clauses for specification and minimum conformance levels, how to do properly
<trackbot> Created ISSUE-124 - Does w3c support conformance clauses for specification and minimum conformance levels, how to do properly ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/124/edit .
scott notes outside specs need to be able to reference appropriate conformance statements
ACTION: Pratik to write a draft of an XML Digital Signature 2.0 specification [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-285 - Write a draft of an XML Digital Signature 2.0 specification [on Pratik Datta - due 2009-05-19].
http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
<scribe> new transform reference might require some extensibility to support known extensions such as STR and various WS* stuff
issue of critical extensions
need discussion of parameters for canonicalization to make improvements, eg whitespace handling etc
should we look at EXI parameters again
?
ACTION: Scott to remove references to DTDs from the sepcification [recorded in http://www.w3.org/2009/05/12-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-286 - Remove references to DTDs from the sepcification [on Scott Cantor - due 2009-05-19].