- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 4 May 2007 17:52:12 -0400
- To: public-xmlsec-maintwg@w3.org
Draft minutes from our face-to-face meeting on 3 May are available
online:
http://www.w3.org/2007/05/03-xmlsec-minutes
I'm including a text version below.
Regards,
--
Thomas Roessler, W3C <tlr@w3.org>
% lynx -dump 03-xmlsec-minutes.html
[1]W3C
- DRAFT -
XML Security Specifications Maintenance WG
3 May 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Ed Simon
Frederick Hirsch
Konrad Lanz
Juan Carlos Cruellas
Phill Hallam-Baker
Greg Whitehead
Greg Berezowski
Sean Mullen
Don Eastlake
Hal Lockhart
Rob Miller
Thomas Roessler
Rich Salz
Regrets
Tony Nadalin
Chair
Frederick Hirsch
Scribe
Gregory Berezowsky, Sean Mullen
Contents
* [4]Topics
1. [5]Reconvene & Administrivia
2. [6]Actions Review
3. [7]November Plenary
4. [8]Canonicalization Comments
5. [9]dsig errata E08
6. [10]Decrypt Transform
7. [11]Section 3.2 - Processing Rules
8. [12]agenda review and then break for lunch
9. [13]Test Case Requirements
10. [14]test using explicit transform during generation for c14n11
11. [15]Best Practices
12. [16]ExternalCoordination Page
13. [17]Charter Development
* [18]Summary of Action Items
_________________________________________________________________
Reconvene & Administrivia
<GregB> Sean to scribe this afternoon
fjh: We should walk through the plenary details to decide on specifics
fjh: We should walk through open and closed actions
fjh: We should review the summary emails from yesterday's meeting
fjh: Do we need schema change for the errata?
<tlr> [19]http://www.w3.org/2007/xmlsec/Group/track
Actions Review
<GregB> ACTION-1 closed
<GregB> ACTION-2 closed
<GregB> ACTION-6 requires additional information in note regarding example
from yesterday's presentation
<GregB> ACTION-10 Austrian governement does not use transforms when they use
Type attribute (i.e. the type denotes the input to the digest)
<klanz2> The optional Type attribute denotes the item, not its contents.
<klanz2> The optional Type attribute denotes the item, not its contents.
<klanz2> The optional Type attribute denotes the item (post transform), not
its contents.
<klanz2> The optional Type attribute denotes the item (post transform if
any), not it's contents.
<klanz2> The optional Type attribute denotes the actually digested item, not
it's contents.
<GregB> ACTION: klanz2 to post E05 discussion to public list [recorded in
[20]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action01]
<trackbot-ng> Created ACTION-14 - Post E05 discussion to public list [on
Konrad Lanz - due 2007-05-10].
<GregB> [21]http://www.w3.org/2007/xmlsec/Group/track/
<GregB> ACTION-10 closed
<trackbot-ng> Sorry... I don't know how to close ACTION yet
<fjh> this is the text in question in 4.3.3.1 - The Type attribute applies
to the item being pointed at, not its contents. For example, a reference
that identifies an Object element containing a SignatureProperties element
is still of type #Object. The type attribute is advisory. No validation of
the type information is required by this specification.
<GregB> ACTION-11 closed
<trackbot-ng> Sorry... I don't know how to close ACTION yet
November Plenary
<tlr> [22]http://www.w3.org/2002/09/wbs/34786/TPAC07/
<fjh> latest redline of sig is
[23]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
<GregB> Estimating 15 people attendance at plenary
<GregB> Days preferred: Thursday PM, Friday, all day, Saturday morning, but
may not use Saturday
<GregB> Like to meet with: XML Core
<GregB> Membership overlap identified: WS Context WG
<GregB> Chair overlap with WS-Policy
<GregB> Will allow non-members with prior approval of chair
<GregB> Questionnaire results:
[24]http://www.w3.org/2002/09/wbs/34786/TPAC07/results
Canonicalization Comments
fjh: suggested xml:base and xml:id examples be added
fjh: RFC 3986 is referenced several times, but not hyperlinked. Link should
be added.
fjh: See
[25]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.h
tml for proposed comments
<fjh> C14N11 is only applicable to XML 1.0 and XPath 1.0 and is not
<fjh> applicable to XML 1.1 and XPath 2.0.
<rsalz> I suggest changing "is not applicable to" to "is not defined for"
<GregB>
([26]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0003.
html)
<tlr> C14N11 is applicable to XML 1.0 and defined in terms of the XPath 1.0
data model. It is not defined for XML 1.1.
RESOLUTION: Accept changes proposed in
[27]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.h
tml
<fjh> RESOLUTION: accept proposed text as C14N comment "C14N11 is applicable
to XML 1.0 and defined in terms of the XPath 1.0 data model. It is not
defined for XML 1.1."
fjh: C14N11 Issue and proposal: Unclear handling of unspecified attributes
in xml namespace
<GregB>
([28]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.
html)
<klanz2> RFC2119 "SHOULD" throw an error as in
klanz2: this is option 3 with SHOULD instead of MUST
rsalz: We should propose #1 or #2 and expect XML core to pick one
tlr: We should ask XML Core to clarify future use of xml:
fjh: should we change 'MUST throw an error' to 'SHOULD throw an error'
... for #3
rich: should for #3 would be ambiguous, so if you decide it is ok then could
do #1, then just choose #1
<fjh> Ed, can you see the email -
[29]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.h
tml
<fjh> in favor of #1, or cannot live with #1
<GregB> 12 in favor, 2 did not oppose, but not in favor
<EdSimon> I lean toward option 1 of fjh's C14N11 note.
<GregB> straw poll in favour of #2
<EdSimon> Ed is not in favour of option 2
<GregB> 2 in favour of #2, 2 opposed, the rest indifferent
<fjh> greg whitehead: benefit of #1 is ability to define transform
<EdSimon> Ed shares the concern expressed that option 2 may lead to security
concerns as mentioned by another participant.
<GregB> straw poll on #3
<GregB> 1 in favour, 2 opposed
klanz: maybe #1 is acceptable, but its a bet against the future with the
potential to render things insecure
<rsalz> My vote in favor of #1 and #2 is more accurately "indifferent"
tlr: transform should be specified when new attributes are introduced
<EdSimon> Should we require/request that new additions to XML Core include
consideration of canonicalization?
<rsalz> +1 to EdSimon
<tlr> +1 as well
grw: there is responsibility on the signer; XML Core needs to recognize when
they introduce new names
... that security, et al needs to be addressed
grw: There must be security considerations around the introduction of new
attributes in the xml namespace and we just need to be explicit about what
is dealt with and what is not
[INS: fjh: :INS] This is a process, not a spec recommendation. Who does that
go to?
<tlr> Need for security review of changes to XML that affect
Canonicalization and Signature.
<GregB> ACTION: Frederick to Raise on XML coordination list the need for XML
security considerations with regards to xml namespace additions [recorded in
[30]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action02]
<trackbot-ng> Created ACTION-15 - Raise on XML coordination list the need
for XML security considerations with regards to xml namespace additions [on
Frederick Hirsch - due 2007-05-10].
<tlr> e..g, new attrbutes
<EdSimon> There should be a security review of any new XML Core features;
XML Core should not risk introducing features that introduce security
concerns.
<fjh> Any attribute in the XML namespace that is neither a Simple
Inheritable Attribute (xml:lang and xml:space as defined above), or xml:id
or xml:base shall not receive special treatment in the processing of
Document Subsets. Specifically, no special processing shall be performed to
provide inheritance when processing a document subset."
<fjh> Section 2.4, Document Subsets
<deastlak> XML namespace attributes other than xml:base, xml:id, xml:lang,
and xml:space MUST be treated as ordinary attributes.
<rsalz> Attributes in the XML namespace other than ...
<fjh> ttributes in the XML namespace other than xml:base, xml:id, xml:lang,
and xml:space MUST
<tlr> Attributes in the XML namespace other than xml:base, xml:id, xml:lang,
and xml:space MUST be processed as ordinary attributes
<GregB> break. back at 1040EST
<GregB> ... and we're back
<tlr> [31]http://www.w3.org/mid/4639E78B.1000406@ac.upc.edu
<fjh>
[32]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0007.h
tml
dsig errata E08
<fjh> sig draft [33]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
<fjh> section 4.4.3
[34]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-RetrievalMethod
klanz: ok with change if we can do it without changing the namespace
EdSimon: would like to correct, this is an error, but feels we cannot change
the schema without changing the namespace
<rsalz> +1 to ed
EdSimon: may break applications where the schema has been signed
fjh: schema and DTD contradict each other
grw: more serious error to have schema that is too restrictive and it may be
sufficient to correct it in prose
tlr: two issues change of part of spec that is expressed as xsd
<tlr> [35]http://www.w3.org/2000/09/xmldsig
tlr: and second, the actual published xsd file
<EdSimon> Until we can change the namespace, I believe we have to live with
the schema error. Do not want to break applications that sign the schema
along with the data. The XML Sig spec should indicate the error.
tlr: section 1.1 - The schema definition is normative and differs from both
the DTD and the text
grw: the text can further restrict the schema even though the intent may not
be expressed in the schema
<fjh> konrad: notes that some may sign their schema, so not supportive of
change
klanz: advocates not changing the schema because this will impact those who
have signed the schema
hal: best practice is to change the name when you make changes which are not
backward compatible. Which would be the case.
hal: We could leave this as a major future revision. Possibly note in the
spec that we are aware of the issue and explain why it has not been changed.
<grw> +1
PHB: should not change schema; DTD conflict is not an issue (perhaps drop it
in the future, anyway)
PHB: All that the schema defines is what will fail validation
<rsalz> Perhas annotate the schema to indicate the the REC requires the URI
attribute even though "shown here as optoinal"
tlr: we all agree that the schema is wrong. we all agree that we should not
change the schema at the URI
<EdSimon> I agree with PHB that the DTD should be dropped in the next major
revision.
tlr: in cleaning up the spec, should we leave it in, but specify the correct
schema with a new URI
grw: doesn't think it is worth the work
klanz2: +1
rsalz: its ok for the schema to be more loose than the text
tlr: we currently have two elements of normative text that conflict
fjh: we are not chartered for schema changes
deastlak: we do need text explaining the issue
<EdSimon> The text can be more specific than the schema...but the schema
should reflect the text as closely as possible. (This is a general comment
and does not change my position above sbout NOT changing the current
schema.)
fjh: it sounds like we have concensus we do not want to change the existing
schema
fjh: it sounds like we all agree we need explanatory text
fjh: should we further clarify that text trumps the schema?
fjh: might break other things, though
tlr: proposes we add text, but raise issue for review with XML Coordination
<GregB> Donald will produce a draft for section 4.4.3 changes
<rsalz> Note that the schema marks this attribute as optional. Because this
does not invalidate any legitimate signatures, and because invalid
signatures would be found by processing rules, the difference will not be
reconciled to avoid the risk of breaking current documents and
implementations
RESOLUTION: For E08 we have agreed to not change the schema as recommended,
but will add explanatory text and review with XML CG
Workshop
fjh: Need to talk about workshop. locations? times? other logistics?
fjh: Do we need to hash it out today or work it out on list?
tlr: We can look at relevant calendaring and poll who might be interested in
hosting
tlr: plan for roughly 50 people
grw: maybe a BOF at the IETF
<GregB> (IETF 69)
<GregB> ... July 22 week
<fjh> ... in chicago
tlr: BOF would be 2 hours (ish) where a workshop is several days
tlr: planning horizon is too narrow
tlr: could co-locate, but IETF is a pretty full week already
<tlr> ACTION: Cruellas to look into workshop hosting [recorded in
[36]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action06]
<trackbot-ng> Created ACTION-16 - Look into workshop hosting [on Juan Carlos
Cruellas - due 2007-05-10].
hal: offering to host at BEA in San Jose
... or in Mass ...
... but assumed we're ruling out Mass ...
fjh: Have you done the freedom trail?
<GregB> last week august first week of Sept are probably out
hal: assume OASIS adoption forum later in fall
tlr: we need to draft a CFP
<tlr> ACTION: thomas to draft CFP [recorded in
[37]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action07]
<trackbot-ng> Created ACTION-17 - Draft CFP [on Thomas Roessler - due
2007-05-10].
hal: people should check their calendars for available workshop dates
<deastlak> PHB and I have come up with a paragraph re RetrievalMethod
fjh: individuals should post to the list ideas regarding the CFP
<deastlak> NOTE: The schema for the "URI" attribute of RetrievalMethod
erroneously omitted the attribute
<deastlak> use="required"
<deastlak> (The DTD is correct.) However, this error only results in a more
lax schema which permits all valid RetrievalMethod elements. Because the
existing schema is embedded in many applications, which may include the
schema in their signatures, the schema has not been corrected to be more
restrictive.
RESOLUTION: The above text should be accepted for the section 4.4.3
Decrypt Transform
<klanz2> RE E05:
[38]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0008.h
tml
<tlr> [39]http://www.w3.org/TR/xmlenc-decrypt
<EdSimon> I get Error 403: Forbidden when trying that link
<EdSimon> I was referring to the
"[40]http://www.w3.org/2007/05/03-xmlsec-irc#T15-34-19" link.
<GregB> That appears to be true of all the resolution links
<fjh> decrypt transform rec - [41]http://www.w3.org/TR/xmlenc-decrypt
Section 3.2 - Processing Rules
klanz2: it reads like the assumption was that xml:base would only appear at
the document 'apex'
fjh: no specification recommendations yet, but a few areas for change:
... section 3
... section 3.1 is the main one
... section 3.4.2: inheriting attributes from the XML namespace: last
paragraph would have to change
... a lot of the issues in C14N11 are replicated here
... should we be referencing C14N11 rather than duplicating the
canonicalization document
... contents, that is
<tlr> PROPOSED: replace second bullet to reference to C14N 1.1 handling of
document subsets
<tlr> (Context: definition of decryptXML transform in Decryption Transform,
item 2, second bullet point)
<tlr>
[42]http://www.w3.org/Encryption/2002/02-xenc-interop.html#decryption-transf
orm
<GregB> discussion around finding people who have worked on decrypt;
tranform interop
<grw> googling for xml decryption transform
<grw>
[43]http://msdn.microsoft.com/msdnmag/issues/04/11/XMLSignatures/default.asp
x
<grw>
[44]http://www.research.ibm.com/trl/projects/xml/xss4j/docs/enc-readme.html
<grw>
[45]http://www.phaos.com/resources/docs/Phaos_XML_1.3/apidoc/com/phaos/xml/t
ransform/DecryptTransform.html
fjh: next step is to get a last call draft; if unable to get an iterop it
will remain at CR
fjh: is anyone interested in working on document?
<GregB> silence
<fjh> greg whitehead: of interest in processing model where layer handles it
below application layer
klanz2: there are issues around this that should go in future charter
klanz2: need well defined behaviour around taking XML out of a context and
putting it back into a context
fjh: decryption transform seems to serve a useful function, but there aren't
too many implementations and there is not a lot of interest
fjh: charter calls for a fix, but we have to get it right
grw: lets take the approach of least effort given the level of interest in
the problem (incremental changes)
tlr: we should get this to a working draft, put it to last call if its
ready, and see what the feedback looks like
agenda review and then break for lunch
fjh: discuss chartering and the wiki content
grw: need to defined test cases for sig interop tests.
... requirements for the test cases actually
<tlr> ACTION: thomas to send e-mail about interop testing dependencies with
Core [recorded in
[46]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action08]
<trackbot-ng> Created ACTION-18 - Send e-mail about interop testing
dependencies with Core [on Thomas Roessler - due 2007-05-10].
tlr: we have to coordinate with the C14N group because they have to go to
rec before we go to proposed edited rec
tlr: A-SIT is offering to host workshop at TU Graz in September.
... not the first week of September ...
fjh: break until 0130EST
<EdSimon> test
<EdSimon> called Zakim, says I'm the first participant
<EdSimon> OK, I can hear now.
<EdSimon> ok thanks
<fjh> ScribeNick: sean
Test Case Requirements
fjh: use merlin test cases (16?) for regression tests
<fjh> [47]http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
<fjh> c14N test in C14N11 feedback -
[48]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.h
tml
hal: look through errata to see what tests are needed
<scribe> ACTION: Konrad to get test case for E01 [recorded in
[49]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action09]
<trackbot-ng> Created ACTION-19 - Get test case for E01 [on Konrad Lanz -
due 2007-05-10].
there are existing dname tests, add reference to this
fjh: Don't think we need tests for E02
<grw> [50]http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
fjh: Don't think we need tests for E03
... Don't think we need tests for E04
<fjh> E02 and E03 refer to related work
<fjh> E04 refers to language without changing behaviour
Test case for E05 probably not needed (or practical)
fjh: Should be a test for E06 to make sure it is a URI
<fjh> sig redline - [51]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
<fjh> thomas: test is to use API for base64 encoding of external image, see
if URI used properly
<fjh> Greg Whitehead: Base64 test exists, need to review it
<fjh> Sean: Yes not well defined.
fjh: Don't need tests for E07 & E08
tlr: do we test what implementations do w/o URI (E06)
... c14n 1.1
... build signature with xml:id in correct place
... move it to wrong place and check behavior
grw: focus on what test cases we need first
<fjh> greg: test case for 1.0 as default see if 1.1 by mistake
<hal> test case which checks for correct sig when xml:base is present
<hal> test case which checks for correct sig when xml:id is present
<fjh> thomas: generate sig over doc subset, must include c14n11 as final
transform
<fjh> greg: new generators not rely on default c14n
test using explicit transform during generation for c14n11
<klanz2> Test case for conversion NodeSetData to OctetStreamData:
<klanz2> Use case: Generate a signature having a reference with some xpath
transform selecting NodeSetData
<klanz2> then we add a XSLT transform that clearly needs OctetStreamData
<klanz2> Check on verification: if the resulting signature actually made the
use of c14n 1.1 explicit in the chain of transforms
<fjh> thomas: is it an error to always put C14N11 transform at end of
transform list
<fjh> not an error to use c14n11 for docs with xml:id or xml:base when not
using document subsets.
grw: verifiers need to be upgraded to use 1.1, generators don't
konrad: c14n old impl should not generate new signatures
tlr: on receiving side continue to use c14n on old sigs, optionally hold and
catch fire if find xml:id or xml:base
... on sending side, c14n 1.1 is mandatory to convert node-set to octet
... c14n 1.0 is should/must not be used if xml:id or xml:base
grw: new code able to operate in mode compatible with old code
... what if ok to do it in old way and doesn't matter/not a risk to you even
if wrong
... must is too strong
tlr: we agree on must implement c14n 1.1
<fjh> generators that currently rely on implicit use of C14N10 in reference
processing model must explicitly use C14N11
<rsalz> Rationale: new (1.1-aware) generates must generate "more secure"
signatures that explicitly use c14n1.1 transform. An old receiver will fail
to validate because they do not recognize the 1.1 transform.
<rsalz> The new generator can then generate the old-style signature, but it
should (must?) explicitly specify 1.0 c14n; old recievers will work, and new
receivers will recognize the signature as "less secure"
<tlr> We RECOMMEND that signature generators do not use the default
<tlr> canonicalization rules of the reference processing model. In
<tlr> cases in which inclusive canonicalization is desired, we
<tlr> RECOMMEND that XML-C14N 1.1 be used.
<tlr> Could go into 6.5, above the algorithm descriptions.
<rsalz> +1 to tlr's text
where do we put new text?
<fjh> sig spec -
[52]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-c14nAlg
tlr: 3.1.1 is the right place
... if default c14n 1.0 is specified should receiver catch fire if sees
xml:id or xml:base?
hal: generate a warning at most
<fjh> ack
tlr: are we going to specify any error behavior in receiver when c14n 1.0 is
used
<tlr> PROPOSED RESOLUTION: include security considerations note for
validators that use c14n 1.0 in "unsafe" contexts, but do not specify error
handling behavior
<tlr> RESOLUTION: include security considerations note for validators that
use c14n 1.0 in "unsafe" contexts, but do not specify error handling
behavior
hal: have to come up with plausible attack scenario for security note
<tlr> konrad: 4.3.3.2 should reference change in generation model
<tlr> tlr: sounds good
konrad: 2 test cases for each bullet in 4.3.3.2?
tlr: must have xml:id or xml:base to test that c14n 1.1 output is diff. from
1.0
<fjh> tlr: if you can share additional test cases, please do so
Best Practices
fjh: not mandatory, but maybe do via wiki w/o too much trouble
[53]http://www.w3.org/2007/xmlsec/wiki
hal: write down some general categories
... security considerations
... interop considerations
tlr: perf bottlenecks
fjh: people should feel to throw in ideas into wiki
<rsalz> fjh mentioned what other communities have canonicalization
algorithms? probably overlaps with potential workshop participants
konrad: what is line between best practices & future work?
hal: anything relevant to current specs is useful
fjh: if chance of doing it should go in charter
tlr: anything that is conformant, go into best practices; otherwise charter
ExternalCoordination Page
fjh: wiki with list of orgs that do stuff related to xml security
[54]http://www.w3.org/2007/xmlsec/wiki/ExternalCoordination
Charter Development
[55]http://www.w3.org/2007/xmlsec/wiki/CharterDevelopmentForSignatureEncrypt
ion
konrad: look at slides for c14n1.1 realtion to xml 1.1
... add stronger algorithms
... performance issues: efficient xml
... robustness: how do we do indentation correctly?
... in future create more robust signatures that survive longer
<tlr> yesterday's minutes: [56]http://www.w3.org/2007/05/02-xmlsec-minutes
phb: would like to see ECC suites defined as algs
<rsalz> "NSA Suite B" crypto suite
<fjh> rsalz: might want to provide guildelines for new canonicalization algs
<fjh> thomas: maybe part of our best practices
<grw> if, in future work, we make processing like c14n schema-dependent then
we should add explicit schema references as a parameter
rich: big problem with affecting installed base w/o changing namespace
<deastlak> I currently have received a request for ECDSA sigs using
RIPEMD160
<fjh> konrad: look at UDDI schema canonicalization
fjh: agenda for next call should be workshop
<fjh> Members of WG should review their calendars in advance of next meeting
to determine constraints on Workshop
<fjh> Members of WG should also provide on mailing list input on desired
location of workshop, benefit of reaching parties, e.g. west coast versus
europe
<fjh> Members of WG should review draft call for participation before next
call after draft produced
<fjh> Members of WG should Review Signature red-line after next revsion
<fjh> ACTION: Thomas to provide URI for additional algorithms [recorded in
[57]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action10]
<trackbot-ng> Created ACTION-22 - Provide URI for additional algorithms [on
Thomas Roessler - due 2007-05-10].
donald: how do we want to specify algs in URIs? Do we want to add structure
for the different components?
meeting adjourned
Summary of Action Items
[NEW] ACTION: Cruellas to look into workshop hosting [recorded in
[58]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action06]
[NEW] ACTION: Frederick to Raise on XML coordination list the need for XML
security considerations with regards to xml namespace additions [recorded in
[59]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action02]
[NEW] ACTION: klanz2 to post E05 discussion to public list [recorded in
[60]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action01]
[NEW] ACTION: Konrad to get test case for E01 [recorded in
[61]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action09]
[NEW] ACTION: thomas to draft CFP [recorded in
[62]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action07]
[NEW] ACTION: Thomas to provide URI for additional algorithms [recorded in
[63]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action10]
[NEW] ACTION: thomas to send e-mail about interop testing dependencies with
Core [recorded in
[64]http://www.w3.org/2007/05/03-xmlsec-minutes.html#action08]
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [65]scribe.perl version 1.128 ([66]CVS
log)
$Date: 2007/05/04 21:48:48 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0014.html
3. http://www.w3.org/2007/05/03-xmlsec-irc
4. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#agenda
5. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item01
6. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item02
7. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item03
8. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item04
9. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item05
10. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item06
11. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item07
12. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item08
13. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item09
14. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item10
15. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item11
16. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item12
17. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#item13
18. file://localhost/home/roessler/W3C/WWW/2007/05/03-xmlsec-minutes.html#ActionSummary
19. http://www.w3.org/2007/xmlsec/Group/track
20. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action01
21. http://www.w3.org/2007/xmlsec/Group/track/
22. http://www.w3.org/2002/09/wbs/34786/TPAC07/
23. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
24. http://www.w3.org/2002/09/wbs/34786/TPAC07/results
25. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html
26. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0003.html)
27. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html
28. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.html)
29. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.html
30. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action02
31. http://www.w3.org/mid/4639E78B.1000406@ac.upc.edu
32. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0007.html
33. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
34. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-RetrievalMethod
35. http://www.w3.org/2000/09/xmldsig
36. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action06
37. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action07
38. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0008.html
39. http://www.w3.org/TR/xmlenc-decrypt
40. http://www.w3.org/2007/05/03-xmlsec-irc#T15-34-19
41. http://www.w3.org/TR/xmlenc-decrypt
42. http://www.w3.org/Encryption/2002/02-xenc-interop.html#decryption-transform
43. http://msdn.microsoft.com/msdnmag/issues/04/11/XMLSignatures/default.aspx
44. http://www.research.ibm.com/trl/projects/xml/xss4j/docs/enc-readme.html
45. http://www.phaos.com/resources/docs/Phaos_XML_1.3/apidoc/com/phaos/xml/transform/DecryptTransform.html
46. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action08
47. http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
48. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html
49. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action09
50. http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
51. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
52. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-c14nAlg
53. http://www.w3.org/2007/xmlsec/wiki
54. http://www.w3.org/2007/xmlsec/wiki/ExternalCoordination
55. http://www.w3.org/2007/xmlsec/wiki/CharterDevelopmentForSignatureEncryption
56. http://www.w3.org/2007/05/02-xmlsec-minutes
57. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action10
58. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action06
59. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action02
60. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action01
61. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action09
62. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action07
63. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action10
64. http://www.w3.org/2007/05/03-xmlsec-minutes.html#action08
65. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
66. http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 4 May 2007 21:53:42 UTC