IRC log of xmlsec on 2007-05-03

Timestamps are in UTC.

12:48:36 [RRSAgent]

RRSAgent has joined #xmlsec

12:48:36 [RRSAgent]

logging to http://www.w3.org/2007/05/03-xmlsec-irc

12:48:49 [fjh]

Zakim, this will be xmlsec

12:48:49 [Zakim]

ok, fjh; I see T&S_XMLSEC()8:00AM scheduled to start 48 minutes ago

12:49:07 [fjh]

Meeting: XML Security Specifications Maintenance WG

12:49:14 [fjh]

Chair: Frederick Hirsch

12:49:20 [fjh]

Regrets: Tony Nadalin

12:49:40 [GregB]

Scribe: Gregory Berezowsky

12:49:42 [klanz2]

klanz2 has joined #xmlsec

12:50:18 [klanz2]

klanz2 has joined #xmlsec

12:50:27 [klanz2]

test

12:51:00 [fjh]

Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0014.html

12:51:54 [Zakim]

T&S_XMLSEC()8:00AM has now started

12:52:01 [Zakim]

+[NRCC]

12:52:13 [fjh]

zakim, who is here

12:52:13 [Zakim]

fjh, you need to end that query with '?'

12:52:18 [fjh]

zakim, who is here?

12:52:18 [Zakim]

On the phone I see [NRCC]

12:52:19 [Zakim]

On IRC I see klanz2, RRSAgent, Zakim, fjh, GregB, trackbot-ng

12:52:20 [tlr]

tlr has joined #xmlsec

12:52:21 [rdm]

rdm has joined #xmlsec

12:52:46 [sean]

sean has joined #xmlsec

12:56:51 [Zakim]

+EdSimon

13:00:08 [EdSimon]

EdSimon has joined #xmlsec

13:00:08 [GregB]

TOPIC: Reconvene & Administrivia

13:01:08 [GregB]

Sean to scribe this afternoon

13:01:13 [rsalz]

rsalz has joined #xmlsec

13:01:13 [tlr]

zakim, who is here?

13:01:13 [Zakim]

On the phone I see [NRCC], EdSimon

13:01:14 [Zakim]

On IRC I see rsalz, EdSimon, sean, rdm, tlr, klanz2, RRSAgent, Zakim, fjh, GregB, trackbot-ng

13:01:53 [tlr]

Present+ GregWhitehead

13:01:58 [tlr]

Present+ JuanCarlosCruellas

13:02:01 [tlr]

Present+ KonradLanz

13:02:05 [tlr]

Present+ FrederickHirsch

13:02:10 [tlr]

Present+ RichSalz

13:02:37 [tlr]

Present+ GregBerezowsky

13:02:42 [GregB]

fjh: We should walk through the plenary details to decide on specifics

13:02:52 [tlr]

Present+ RobMiller

13:02:56 [GregB]

fjh: We should walk through open and closed actions

13:03:32 [GregB]

fjh: We should review the summary emails from yesterday's meeting

13:04:26 [klanz2]

q+

13:05:15 [GregB]

fjh: Do we need schema change for the errata?

13:05:45 [tlr]

http://www.w3.org/2007/xmlsec/Group/track

13:06:29 [jcc]

jcc has joined #xmlsec

13:06:40 [GregB]

TOPIC: Actions Review

13:07:23 [GregB]

ACTION-1 closed

13:07:23 [trackbot-ng]

Sorry... I don't know how to close ACTION yet

13:08:10 [GregB]

ACTION-2 closed

13:08:10 [trackbot-ng]

Sorry... I don't know how to close ACTION yet

13:09:33 [GregB]

ACTION-6 requires additional information in note regarding example from yesterday's presentation

13:12:11 [GregB]

ACTION-10 Austrian governement does not use transforms when they use Type attribute (i.e. the type denotes the input to the digest)

13:16:58 [fjh]

zakim, who is here?

13:16:58 [Zakim]

On the phone I see [NRCC], EdSimon

13:17:00 [Zakim]

On IRC I see jcc, rsalz, EdSimon, sean, rdm, tlr, klanz2, RRSAgent, Zakim, fjh, GregB, trackbot-ng

13:17:40 [klanz2]

The optional Type attribute denotes the item, not its contents.

13:18:08 [fjh]

fjh has joined #xmlsec

13:18:20 [klanz2]

The optional Type attribute denotes the item, not its contents.

13:19:16 [klanz2]

The optional Type attribute denotes the item (post transform), not its contents.

13:19:46 [klanz2]

The optional Type attribute denotes the item (post transform if any), not it's contents.

13:20:39 [grw]

grw has joined #xmlsec

13:20:55 [klanz2]

The optional Type attribute denotes the actually digested item, not it's contents.

13:22:02 [deastlak]

deastlak has joined #xmlsec

13:22:35 [jcc]

q+

13:22:50 [GregB]

ACTION: klanz2 to post E05 discussion to public list

13:22:50 [trackbot-ng]

Created ACTION-14 - Post E05 discussion to public list [on Konrad Lanz - due 2007-05-10].

13:23:34 [tlr]

tlr has changed the topic to: http://www.w3.org/2007/xmlsec/Group/track

13:23:36 [GregB]

http://www.w3.org/2007/xmlsec/Group/track/

13:24:00 [GregB]

ACTION-10 closed

13:24:00 [trackbot-ng]

Sorry... I don't know how to close ACTION yet

13:25:17 [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.

13:26:07 [GregB]

ACTION-11 closed

13:26:07 [trackbot-ng]

Sorry... I don't know how to close ACTION yet

13:26:57 [PHB]

PHB has joined #xmlsec

13:27:08 [GregB]

TOPIC: November Plenary

13:27:09 [GregB]

TOPIC: November Plenary

13:27:55 [tlr]

http://www.w3.org/2002/09/wbs/34786/TPAC07/

13:28:11 [fjh]

latest redline of sig is http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/

13:29:40 [klanz2]

ack klanz2

13:29:45 [klanz2]

q-

13:29:56 [jcc]

q-

13:30:47 [GregB]

Estimating 15 people attendance at plenary

13:31:16 [GregB]

Days preferred: Thursday PM, Friday, all day, Saturday morning, but may not use Saturday

13:33:05 [GregB]

Like to meet with: XML Core

13:33:18 [GregB]

Membership overlap identified: WS Context WG

13:33:53 [GregB]

Chair overlap with WS-Policy

13:36:03 [GregB]

Will allow non-members with prior approval of chair

13:37:58 [GregB]

Questionnaire results: http://www.w3.org/2002/09/wbs/34786/TPAC07/results

13:38:13 [GregB]

TOPIC: Canonicalization Comments

13:39:27 [GregB]

fjh: suggested xml:base and xml:id examples be added

13:40:44 [GregB]

fjh: RFC 3986 is referenced several times, but not hyperlinked. Link should be added.

13:43:34 [GregB]

fjh: See http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html for proposed comments

13:44:27 [fjh]

C14N11 is only applicable to XML 1.0 and XPath 1.0 and is not

13:44:40 [fjh]

applicable to XML 1.1 and XPath 2.0.

13:45:02 [rsalz]

I suggest changing "is not applicable to" to "is not defined for"

13:45:29 [GregB]

(http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0003.html)

13:46:40 [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.

13:48:05 [klanz2]

klanz2 has joined #xmlsec

13:48:14 [GregB]

RESOLUTION: Accept changes proposed in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html

13:48:31 [fjh]

RRSAgent, where am I?

13:48:31 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T13-48-31

13:49:47 [GregB]

GregB has joined #xmlsec

13:50:07 [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."

13:50:14 [fjh]

RRSAgent, where am I?

13:50:14 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T13-50-14

13:50:17 [grw]

grw has joined #xmlsec

13:51:53 [GregB]

fjh: C14N11 Issue and proposal: Unclear handling of unspecified attributes in xml namespace

13:52:03 [GregB]

(http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.html)

13:52:37 [klanz2]

+

13:52:39 [klanz2]

q+

13:53:52 [klanz2]

RFC2119 "SHOULD" throw an error as in

13:53:56 [EdSimon]

q+

13:54:12 [fjh]

ack klanz

13:54:15 [rsalz]

q+

13:54:43 [klanz2]

q-

13:54:47 [fjh]

ack EdSimon

13:54:55 [GregB]

klanz2: this is option 3 with SHOULD instead of MUST

13:55:42 [rsalz]

q-

13:55:51 [fjh]

ack rsalz

13:56:27 [GregB]

rsalz: We should propose #1 or #2 and expect XML core to pick one

13:56:59 [tlr]

q+

13:58:06 [fjh]

ack

13:58:11 [fjh]

ack tlr

13:58:46 [klanz2]

q+

13:59:28 [fjh]

ack klanz

13:59:33 [GregB]

tlr: We should ask XML Core to clarify future use of xml:

14:00:08 [grw]

grw has joined #xmlsec

14:00:42 [tlr]

q+

14:01:35 [GregB]

fjh: should we change 'MUST throw an error' to 'SHOULD throw an error'

14:01:42 [GregB]

... for #3

14:01:50 [tlr]

q-

14:02:02 [fjh]

rich: should for #3 would be ambiguous, so if you decide it is ok then could do #1, then just choose #1

14:03:33 [grw]

q+

14:03:44 [fjh]

Ed, can you see the email - http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0002.html

14:04:09 [fjh]

in favor of #1, or cannot live with #1

14:04:52 [GregB]

12 in favor, 2 did not oppose, but not in favor

14:06:19 [fjh]

q?

14:06:31 [fjh]

ack grw

14:06:35 [EdSimon]

I lean toward option 1 of fjh's C14N11 note.

14:06:35 [PHB]

q+

14:07:36 [PHB]

q-

14:09:38 [klanz2]

q+

14:11:12 [GregB]

straw poll in favour of #2

14:11:15 [EdSimon]

Ed is not in favour of option 2

14:11:38 [GregB]

2 in favour of #2, 2 opposed, the rest indifferent

14:12:21 [fjh]

greg whitehead: benefit of #1 is ability to define transform

14:12:33 [tlr]

q+

14:12:43 [EdSimon]

Ed shares the concern expressed that option 2 may lead to security concerns as mentioned by another participant.

14:12:51 [GregB]

straw poll on #3

14:13:04 [GregB]

1 in favour, 2 opposed

14:13:16 [tlr]

q?

14:13:49 [GregB]

klanz: maybe #1 is acceptable, but its a bet against the future with the potential to render things insecure

14:14:20 [fjh]

ack klanz

14:14:23 [fjh]

ack tlr

14:14:23 [grw]

q+

14:14:55 [rsalz]

My vote in favor of #1 and #2 is more accurately "indifferent"

14:15:10 [GregB]

tlr: transform should be specified when new attributes are introduced

14:15:43 [EdSimon]

Should we require/request that new additions to XML Core include consideration of canonicalization?

14:15:55 [klanz2]

q+

14:16:15 [rsalz]

+1 to EdSimon

14:16:27 [tlr]

+1 as well

14:17:05 [EdSimon]

q+

14:17:30 [GregB]

grw: there is responsibility on the signer; XML Core needs to recognize when they introduce new names

14:17:53 [fjh]

ack grw

14:17:54 [GregB]

... that security, et al needs to be addressed

14:17:58 [fjh]

ack klanz

14:18:10 [fjh]

ack EdSimon

14:19:55 [GregB]

grw: There must be security considerations around the introduction of new names and we just need to be explicit about what is dealt with and what is no

14:19:59 [GregB]

s/no/not/

14:20:11 [fjh]

s/names/attributes in the xml namespace/

14:21:17 [GregB]

fjh: This is a process, not a spec recommendation. Who does that go to?

14:22:03 [tlr]

Need for security review of changes to XML that affect Canonicalization and Signature.

14:22:09 [GregB]

ACTION: Frederick to Raise on XML coordination list the need for XML security considerations with regards to xml namespace additions

14:22:09 [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].

14:22:12 [tlr]

e..g, new attrbutes

14:23:29 [EdSimon]

There should be a security review of any new XML Core features; XML Core should not risk introducing features that introduce security concerns.

14:24:48 [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."

14:25:12 [fjh]

Section 2.4, Document Subsets

14:25:23 [deastlak]

XML namespace attributes other than xml:base, xml:id, xml:lang, and xml:space are treated as ordinary attributes.

14:25:55 [rsalz]

Attributes in the XML namespace other than ...

14:26:31 [fjh]

ttributes in the XML namespace other than xml:base, xml:id, xml:lang, and xml:space MUST

14:26:38 [GregB]

s/are/MUST be/

14:26:39 [tlr]

Attributes in the XML namespace other than xml:base, xml:id, xml:lang, and xml:space MUST be treated as ordinary attributes

14:26:56 [fjh]

s/treated/processed

14:27:43 [GregB]

break. back at 1045EST

14:27:51 [GregB]

s/1045/1040/

14:41:38 [GregB]

... and we're back

14:43:04 [tlr]

http://www.w3.org/mid/4639E78B.1000406@ac.upc.edu

14:43:06 [fjh]

http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0007.html

14:43:23 [GregB]

TOPIC: dsig errata E08

14:44:36 [fjh]

sig draft http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/

14:46:03 [fjh]

section 4.4.3 http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-RetrievalMethod

14:46:54 [klanz2]

q+

14:47:11 [EdSimon]

q+

14:47:36 [rsalz]

q+

14:47:41 [GregB]

klanz: ok with change if we can do it without changing the namespace

14:47:53 [klanz2]

q-

14:48:02 [fjh]

ack EdSimon

14:48:20 [hal]

hal has joined #xmlsec

14:48:20 [GregB]

EdSimon: would like to correct, this is an error, but feels we cannot change the schema without changing the namespace

14:48:30 [grw]

q+

14:48:44 [rsalz]

q-

14:48:47 [rsalz]

+1 to ed

14:48:49 [klanz2]

q+

14:48:49 [GregB]

EdSimon: may break applications where the schema has been signed

14:48:53 [hal]

q+

14:49:12 [GregB]

fjh: schema and DTD contradict each other

14:49:44 [PHB]

q+

14:50:26 [rsalz]

q+

14:50:36 [GregB]

grw: more serious error to have schema that is too restrictive and it may be sufficient to correct it in prose

14:50:45 [fjh]

ack grw

14:51:02 [GregB]

tlr: two issues

14:51:09 [tlr]

q+

14:51:13 [GregB]

tlr: change of part of spec that is expressed as xsd

14:51:14 [tlr]

q?

14:51:24 [tlr]

q+

14:51:40 [tlr]

http://www.w3.org/2000/09/xmldsig

14:52:09 [GregB]

tlr: and second, the actual published xsd file

14:53:06 [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.

14:53:43 [GregB]

tlr: section 1.1 - The schema definition is normative and differs from both the DTD and the text

14:53:53 [sean]

sean has joined #xmlsec

14:54:10 [tlr]

q?

14:54:11 [tlr]

q+

14:54:19 [GregB]

grw: the text can further restrict the schema even though the intent may not be expressed in the schema

14:54:22 [fjh]

ack klanz

14:54:27 [rsalz]

q-

14:54:37 [fjh]

konrad: notes that some may sign their schema, so not supportive of change

14:54:55 [GregB]

klanz: advocates not changing the schema because this will impact those who have signed the schema

14:54:56 [fjh]

ack hal

14:55:18 [GregB]

hal: best practice is to change the name when you make incompatible changes. Which would be the case.

14:55:57 [GregB]

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.

14:56:00 [grw]

+1

14:56:06 [fjh]

ack PHB

14:56:29 [GregB]

PHB: should not change schema; DTD conflict is not an issue (perhaps drop it in the future, anyway)

14:56:51 [GregB]

PHB: All that the schema defines is what will fail validation

14:56:55 [fjh]

ack tlr

14:57:02 [rsalz]

Perhas annotate the schema to indicate the the REC requires the URI attribute even though "shown here as optoinal"

14:57:31 [hal]

s/incompatible changes/changes which are not backward compatible/

14:57:31 [GregB]

tlr: we all agree that the schema is wrong. we all agree that we should not change the schema at the URI

14:57:38 [EdSimon]

I agree with PHB that the DTD should be dropped in the next major revision.

14:58:00 [GregB]

tlr: in cleaning up the spec, should we leave it in, but specify the correct schema with a new URI

14:58:12 [rsalz]

q+

14:58:22 [GregB]

grw: doesn't think it is worth the work

14:58:31 [GregB]

klanz2: +1

14:58:36 [rsalz]

q-

14:58:40 [hal]

q+

14:58:51 [GregB]

rsalz: its ok for the schema to be more loose than the text

14:59:39 [GregB]

q?

15:01:25 [GregB]

tlr: we currently have two elements of normative text that conflict

15:02:11 [GregB]

fjh: we are not chartered for schema changes

15:02:24 [GregB]

deastlak: we do need text explaining the issue

15:03:00 [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.)

15:03:02 [GregB]

fjh: it sounds like we have concensus we do not want to change the existing schema

15:03:11 [GregB]

fjh: it sounds like we all agree we need explanatory text

15:05:46 [GregB]

fjh: should we further clarify that text trumps the schema?

15:05:55 [GregB]

fjh: might break other things, though

15:07:29 [GregB]

tlr: proposes we add text, but raise issue for review with XML Coordination

15:08:23 [GregB]

Donald will produce a draft for section 4.4.3 changes

15:08:43 [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

15:09:21 [GregB]

RESOLUTION: For E08 we have agreed to not change the schema as recommended, but will add explanatory text and review with XML CG

15:09:37 [GregB]

RSSAgent, where am I?

15:09:48 [GregB]

RRSAgent, where am I?

15:09:48 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T15-09-48

15:10:26 [GregB]

fjh: Need to talk about workshop. locations? times? other logistics?

15:10:38 [GregB]

TOPIC Workshop

15:10:49 [GregB]

fjh: Do we need to hash it out today or work it out on list?

15:11:52 [GregB]

tlr: We can look at relevant calendaring and poll who might be interested in hosting

15:12:07 [GregB]

tlr: plan for roughly 50 people

15:13:00 [GregB]

q?

15:13:14 [tlr]

q+

15:13:18 [GregB]

grw: maybe a BOF at the IETF

15:13:22 [GregB]

(IETF 69)

15:13:35 [GregB]

... July 22 week

15:13:49 [fjh]

... in chicago

15:14:05 [GregB]

tlr: BOF would be 2 hours (ish) where a workshop is several days

15:14:12 [GregB]

tlr: planning horizon is too narrow

15:14:38 [GregB]

tlr: could co-locate, but IETF is a pretty full week already

15:15:27 [GregB]

ACTION: jcc to look into hosting workshop

15:15:27 [trackbot-ng]

Sorry, couldn't find user - jcc

15:15:42 [GregB]

ACTION: Juan Carlos to look into hosting workshop

15:15:42 [trackbot-ng]

Sorry, couldn't find user - Juan

15:16:05 [GregB]

ACTION: Juan-Carlos to look into hosting workshop

15:16:05 [trackbot-ng]

Sorry, couldn't find user - Juan-Carlos

15:16:20 [tlr]

ACTION: Cruellas to look into workshop hosting

15:16:20 [trackbot-ng]

Created ACTION-16 - Look into workshop hosting [on Juan Carlos Cruellas - due 2007-05-10].

15:17:09 [tlr]

hal: offering to host at BEA in San Jose

15:20:43 [tlr]

... or in Mass ...

15:20:49 [tlr]

... but assumed we're ruling out Mass ...

15:20:57 [tlr]

fjh: Have you done the freedom trail?

15:21:30 [GregB]

last week august first week of Sept are probably out

15:21:43 [tlr]

hal: assume OASIS adoption forum later in fall

15:23:20 [GregB]

tlr: we need to draft a CFP

15:26:26 [tlr]

ACTION: thomas to draft CFP

15:26:26 [trackbot-ng]

Created ACTION-17 - Draft CFP [on Thomas Roessler - due 2007-05-10].

15:28:43 [GregB]

hal: people should check their calendars for available workshop dates

15:28:47 [deastlak]

PHB and I have come up with a paragraph re RetrievalMethod

15:30:38 [GregB]

fjh: individuals should post to the list ideas regarding the CFP

15:32:26 [deastlak]

NOTE: The schema for the "URI" attribute of RetrievalMethod erroneously omitted the attribute

15:32:39 [deastlak]

use="required"

15:32:51 [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.

15:33:58 [GregB]

RESOLUTION: The above text should be accepted for the section 4.4.3

15:34:19 [GregB]

RRSAgent, where am I?

15:34:19 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T15-34-19

15:34:45 [GregB]

TOPIC: Decrypt Transform

15:35:24 [klanz2]

RE E05: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0008.html

15:35:27 [tlr]

http://www.w3.org/TR/xmlenc-decrypt

15:39:42 [EdSimon]

I get Error 403: Forbidden when trying that link

15:40:38 [EdSimon]

I was referring to the "http://www.w3.org/2007/05/03-xmlsec-irc#T15-34-19" link.

15:41:27 [GregB]

That appears to be true of all the resolution links

15:41:46 [tlr]

rrsagent, make this record public

15:42:12 [fjh]

decrypt transform rec - http://www.w3.org/TR/xmlenc-decrypt

15:43:14 [GregB]

TOPIC: Section 3.2 - Processing Rules

15:44:54 [GregB]

klanz2: it reads like the assumption was that xml:base would only appear at the document 'apex'

15:47:13 [GregB]

fjh: no specification recommendations yet, but a few areas for change:

15:47:23 [GregB]

... section 3

15:47:27 [GregB]

... section 3.1 is the main one

15:48:43 [GregB]

... section 3.4.2: inheriting attributes from the XML namespace: last paragraph would have to change

15:49:01 [GregB]

... a lot of the issues in C14N11 are replicated here

15:49:58 [GregB]

... should we be referencing C14N11 rather than duplicating the canonicalization document

15:50:07 [GregB]

... contents, that is

15:52:53 [tlr]

PROPOSED: replace second bullet to reference to C14N 1.1 handling of document subsets

15:53:23 [tlr]

(Context: definition of decryptXML transform in Decryption Transform, item 2, second bullet point)

15:59:20 [tlr]

http://www.w3.org/Encryption/2002/02-xenc-interop.html#decryption-transform

15:59:24 [GregB]

discussion around finding people who have worked on decypt tranform interop

15:59:40 [GregB]

s/decypt/decrypt;/

16:03:44 [grw]

googling for xml decryption transform

16:03:46 [grw]

http://msdn.microsoft.com/msdnmag/issues/04/11/XMLSignatures/default.aspx

16:05:05 [grw]

http://www.research.ibm.com/trl/projects/xml/xss4j/docs/enc-readme.html

16:05:53 [grw]

http://www.phaos.com/resources/docs/Phaos_XML_1.3/apidoc/com/phaos/xml/transform/DecryptTransform.html

16:11:45 [GregB]

fjh: next step is to get a last call draft; if unable to get an iterop it will remain at CR

16:12:57 [GregB]

fjh: is anyone interested in working on document?

16:13:04 [GregB]

silence

16:16:05 [fjh]

greg whitehead: of interest in processing model where layer handles it below application layer

16:17:36 [GregB]

klanz2: there are issues around this that should go in future charter

16:18:06 [GregB]

klanz2: need well defined behaviour around taking XML out of a context and putting it back into a context

16:19:03 [GregB]

djh: decryption transform seems to serve a useful function, but there aren't too many implementations and there is not a lot of interest

16:19:12 [GregB]

djh: charter calls for a fix, but we have to get it right

16:19:59 [GregB]

grw: lets take the approach of least effort given the level of interest in the problem (incremental changes)

16:21:20 [tlr]

s/djh/fjh/g

16:23:30 [GregB]

tlr: we should get this to a working draft, put it to last call if its ready, and see what the feedback looks like

16:24:26 [GregB]

TOPIC: agenda review and then break for lunch

16:24:52 [GregB]

fjh: discuss chartering and the wiki content

16:25:59 [GregB]

grw: need to defined test cases for sig interop tests.

16:26:26 [GregB]

... requirements for the test cases actually

16:30:22 [tlr]

ACTION: thomas to send e-mail about interop testing dependencies with Core

16:30:22 [trackbot-ng]

Created ACTION-18 - Send e-mail about interop testing dependencies with Core [on Thomas Roessler - due 2007-05-10].

16:30:56 [GregB]

tlr: we have to coordinate with the C14N group because they have to go to rec before we go to proposed rec

16:32:01 [tlr]

tlr: A-SIT is offering to host workshop at TU Graz in September.

16:32:21 [tlr]

... not the first week of September ...

16:32:51 [GregB]

fjh: break until 0130EST

16:33:23 [Zakim]

-[NRCC]

16:56:43 [Zakim]

-EdSimon

16:56:45 [Zakim]

T&S_XMLSEC()8:00AM has ended

16:56:46 [Zakim]

Attendees were [NRCC], EdSimon

17:12:42 [EdSimon]

EdSimon has joined #xmlsec

17:13:11 [EdSimon]

test

17:15:06 [deastlak]

deastlak has joined #xmlsec

17:15:52 [tlr]

tlr has joined #xmlsec

17:25:51 [fjh]

zakim, what is the number?

17:25:51 [Zakim]

I don't understand your question, fjh.

17:26:46 [fjh]

zakim, code ?

17:26:46 [Zakim]

the conference code is 965732 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), fjh

17:27:49 [Zakim]

T&S_XMLSEC()8:00AM has now started

17:27:56 [Zakim]

+EdSimon

17:28:17 [EdSimon]

called Zakim, says I'm the first participant

17:28:19 [Zakim]

+[NRCC]

17:28:28 [fjh]

zakim, who is here?

17:28:28 [Zakim]

On the phone I see EdSimon, [NRCC]

17:28:29 [Zakim]

On IRC I see tlr, deastlak, EdSimon, hal, GregB, klanz2, PHB, fjh, jcc, rsalz, RRSAgent, Zakim, trackbot-ng

17:28:31 [EdSimon]

OK, I can hear now.

17:29:19 [EdSimon]

ok thanks

17:29:52 [sean]

sean has joined #xmlsec

17:29:56 [fjh]

ScribeNick: sean

17:30:16 [fjh]

Topic: Test Case Requirements

17:32:19 [grw]

grw has joined #xmlsec

17:33:11 [sean]

fjh: use merlin test cases (16?) for regression tests

17:33:57 [rdm]

rdm has joined #xmlsec

17:34:59 [fjh]

http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html

17:36:25 [fjh]

c14N test in C14N11 feedback - http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0000.html

17:36:54 [sean]

hal: look through errata to see what tests are needed

17:39:07 [sean]

ACTION: Konrad to get test case for E01

17:39:07 [trackbot-ng]

Created ACTION-19 - Get test case for E01 [on Konrad Lanz - due 2007-05-10].

17:40:13 [sean]

there are existing dname tests, add reference to this

17:40:56 [sean]

fjh: Don't think we need tests for E02

17:40:57 [grw]

http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME

17:41:17 [sean]

fjh: Don't think we need tests for E03

17:41:40 [sean]

fjh: Don't think we need tests for E04

17:43:12 [fjh]

E02 and E03 refer to related work

17:43:25 [fjh]

E04 refers to language without changing behaviour

17:43:33 [sean]

Test case for E05 probably not needed (or practical)

17:44:11 [sean]

fjh: Should be a test for E06 to make sure it is a URI

17:45:02 [fjh]

sig redline - http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/

17:46:18 [fjh]

thomas: test is to use API for base64 encoding of external image, see if URI used properly

17:47:22 [fjh]

Greg Whitehead: Base64 test exists, need to review it

17:47:28 [fjh]

Sean: Yes not well defined.

17:50:06 [sean]

fjh: Don't need tests for E07 & E08

17:50:38 [sean]

tlr: do we test what implementations do w/o URI (E06)

17:54:51 [sean]

tlr: c14n 1.1

17:55:04 [sean]

... build signature with xml:id in correct place

17:55:28 [sean]

... move it to wrong place and check behavior

18:01:47 [sean]

grw: focus on what test cases we need first

18:02:31 [fjh]

greg: test case for 1.0 as default see if 1.1 by mistake

18:03:47 [hal]

test case which checks for correct sig when xml:base is present

18:04:10 [hal]

test case which checks for correct sig when xml:id is present

18:05:11 [fjh]

thomas: generate sig over doc subset, must include c14n11 as final transform

18:06:14 [fjh]

greg: new generators not rely on default c14n

18:10:10 [fjh]

Topic: test using explicit transform during generation for c14n11

18:10:30 [klanz2]

Test case for conversion NodeSetData to OctetStreamData:

18:10:59 [fjh]

zakim, where am I?

18:10:59 [Zakim]

I don't understand your question, fjh.

18:11:03 [klanz2]

Use case: Generate a signature having a reference with some xpath transform selecting NodeSetData

18:11:08 [fjh]

rrsagent, where am I?

18:11:08 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T18-11-08

18:11:28 [klanz2]

then we add a XSLT transform that clearly needs OctetStreamData

18:14:28 [klanz2]

Check on verification: if the resulting signature actually made the use of c14n 1.1 explicit in the chain of transforms

18:22:22 [fjh]

thomas: is it an error to always put C14N11 transform at end of transform list

18:25:09 [fjh]

not an error to use c14n11 for docs with xml:id or xml:base when not using document subsets.

18:28:16 [sean]

grw: verifiers need to be upgraded to use 1.1, generators don't

18:30:33 [sean]

konrad: c14n old impl should not generate new signatures

18:32:56 [sean]

tlr: on receiving side continue to use c14n on old sigs, optionally hold and catch fire if find xml:id or xml:base

18:34:24 [sean]

sean has joined #xmlsec

18:35:53 [sean]

tlr: on sending side, c14n 1.1 is mandatory to convert node-set to octet

18:36:17 [sean]

... c14n 1.0 is should/must not be used if xml:id or xml:base

18:39:48 [sean]

grw: new code able to operate in mode compatible with old code

18:43:56 [sean]

grw: what if ok to do it in old way and doesn't matter/not a risk to you even if wrong

18:44:11 [sean]

... must is too strong

18:46:06 [sean]

tlr: we agree on must implement c14n 1.1

18:48:52 [fjh]

generators that currently rely on implicit use of C14N10 in reference processing model must explicitly use C14N11

18:52:07 [rsalz]

Ratoinale: 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.

18:52:55 [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"

18:54:41 [tlr]

We RECOMMEND that signature generators do not use the default

18:54:41 [tlr]

canonicalization rules of the reference processing model. In

18:54:41 [tlr]

cases in which inclusive canonicalization is desired, we

18:54:41 [tlr]

RECOMMEND that XML-C14N 1.1 be used.

18:55:11 [tlr]

Could go into 6.5, above the algorithm descriptions.

19:01:53 [rsalz]

+1 to tlr's text

19:02:00 [fjh]

rrsagent, where am i?

19:02:00 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T19-02-00

19:02:23 [fjh]

s/Ratoin/Ration/

19:03:16 [Zakim]

-EdSimon

19:03:52 [Zakim]

+EdSimon

19:05:35 [sean]

where do we put new text?

19:05:38 [fjh]

sig spec - http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-c14nAlg

19:07:14 [sean]

tlr: 3.1.1 is the right place

19:09:10 [sean]

tlr: if default c14n is specified should receiver catch fire if sees xml:id or xml:base?

19:09:29 [sean]

s/c14n/c14n 1.0/

19:09:50 [sean]

hal: generate a warning at most

19:11:00 [fjh]

q+

19:14:32 [fjh]

ack

19:14:45 [sean]

tlr: are we going to specify any error behavior in receiver when c14n 1.0 is used

19:15:53 [tlr]

PROPOSED RESOLUTION: include security considerations note for processors that use c14n 1.0 in "unsafe" contexts, but do not specify error handling behavior

19:16:24 [tlr]

s/processors/validators/

19:16:36 [tlr]

RESOLUTION: include security considerations note for validators that use c14n 1.0 in "unsafe" contexts, but do not specify error handling behavior

19:16:47 [fjh]

rrsagent, where am i?

19:16:47 [RRSAgent]

See http://www.w3.org/2007/05/03-xmlsec-irc#T19-16-47

19:17:54 [sean]

hal: have to come up with plausible attack scenario for security note

19:19:55 [tlr]

konrad: 4.3.3.2 should reference change in generation model

19:19:57 [tlr]

tlr: sounds good

19:23:03 [sean]

konrad: 2 test cases for each bullet in 4.3.3.2?

19:25:09 [sean]

tlr: must have xml:id or xml:base to test that c14n 1.1 output is diff. from 1.0

19:26:32 [fjh]

tlr: if you can share additional test cases, please do so

19:31:38 [sean]

TOPIC: Best Practices

19:32:06 [sean]

fjh: not mandatory, but maybe do via wiki w/o too much trouble

19:32:53 [sean]

http://www.w3.org/2007/xmlsec/wiki

19:35:53 [sean]

hal: write down some general categories

19:36:02 [sean]

hal: security considerations

19:36:09 [sean]

hal: interop considerations

19:36:16 [sean]

tlr: perf bottlenecks

19:37:51 [sean]

fjh: people should feel to throw in ideas into wiki

19:38:38 [rsalz]

fjh mentioned what other communities have canonicalization algorithms? probably overlaps with potential workshop participants

19:38:41 [sean]

konrad: what is line between best practices & future work?

19:39:03 [sean]

hal: anything relevant to current specs is useful

19:39:25 [sean]

fjh: if chance of doing it should go in charter

19:39:53 [sean]

tlr: anything that is conformant, go into best practices; otherwise charter

19:41:48 [sean]

TOPIC: ExternalCoordination Page

19:42:28 [sean]

fjh: wiki with list of orgs that do stuff related to xml security

19:42:50 [sean]

http://www.w3.org/2007/xmlsec/wiki/ExternalCoordination

19:43:15 [sean]

TOPIC: Charter Development

19:43:25 [sean]

http://www.w3.org/2007/xmlsec/wiki/CharterDevelopmentForSignatureEncryption

19:44:11 [sean]

konrad: look at slides for c14n1.1 realtion to xml 1.1

19:45:06 [sean]

konrad: add stronger algorithms

19:45:44 [sean]

konrad: performance issues: efficient xml

19:46:11 [sean]

konrad: robustness: how do we do indentation correctly?

19:46:47 [sean]

konrad: in future create more robust signatures that survive longer

19:50:30 [tlr]

yesterday's minutes: http://www.w3.org/2007/05/02-xmlsec-minutes

19:59:29 [PHB]

q+

20:00:18 [fjh]

ack fjh

20:00:22 [fjh]

ack PHB

20:00:52 [sean]

phb: would like to see ECC suites defined as algs

20:02:21 [rsalz]

"NSA Suite B" crypto suite

20:04:27 [fjh]

rsalz: might want to proviide guildelines for new canoncialization algs

20:04:35 [fjh]

thomas: maybe part of our best practices

20:04:41 [fjh]

s/ii/i/

20:04:57 [fjh]

s/nci/nic/

20:07:02 [grw]

if, in future work, we make processing like c14n schema-dependent then we should add explicit schema references as a parameter

20:10:21 [sean]

rich: big problem with affecting installed base w/o changing namespace

20:11:05 [deastlak]

I currently have received a request for ECDSA sigs using RIPEMD160

20:12:03 [fjh]

konrad: look at UDDI schema canonicalization

20:18:17 [sean]

fjh: agenda for next call should be workshop

20:21:25 [fjh]

Members of WG should review their calendars in advance of next meeting to determine constraints on Workshop

20:21:32 [deastlak]

deastlak has joined #xmlsec

20:22:15 [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

20:22:36 [fjh]

Members of WG should review draft call for participation before next call after draft produced

20:22:58 [fjh]

Members of WG should Review Signature red-line after next revsion

20:23:37 [klanz2]

q?

20:24:06 [fjh]

ACTION: Thomas to provide URI for additional algorithms

20:24:07 [trackbot-ng]

Created ACTION-22 - Provide URI for additional algorithms [on Thomas Roessler - due 2007-05-10].

20:27:47 [sean]

donald: how do we want to specify algs in URIs? Do we want to add structure for the different components?

20:28:42 [tlr]

rrsagent, list participants

20:28:42 [RRSAgent]

I'm logging. I don't understand 'list participants', tlr. Try /msg RRSAgent help

20:28:47 [tlr]

zakim, list participants

20:28:47 [Zakim]

As of this point the attendees have been EdSimon, [NRCC]

20:28:48 [sean]

meeting adjourned

20:28:55 [tlr]

rrsagent, please draft minutes

20:28:55 [RRSAgent]

I have made the request to generate http://www.w3.org/2007/05/03-xmlsec-minutes.html tlr

20:29:29 [Zakim]

-[NRCC]

20:29:31 [Zakim]

-EdSimon

20:29:33 [Zakim]

T&S_XMLSEC()8:00AM has ended

20:29:34 [Zakim]

Attendees were EdSimon, [NRCC]

20:35:24 [PHB]

PHB has left #xmlsec

20:42:08 [jcc]

quit

20:42:25 [jcc]

jcc has left #xmlsec

20:50:25 [tlr]

tlr has joined #xmlsec

21:10:44 [rsalz]

rsalz has joined #xmlsec

22:06:41 [tlr]

tlr has joined #xmlsec

22:50:12 [Zakim]

Zakim has left #xmlsec