<trackbot> Date: 13 May 2009
<trackbot> Meeting: XML Security Working Group Teleconference
<trackbot> Date: 13 May 2009
fjh: plan to publish another
round of working drafts in June
... we will have a resolution on June 2 to approve the publication of the new round of drafts
... we also plan to have a resolution on ECC on June 2
... plan is to have last call WD for XMLDSIG and XMLENC end of July
... reviews the new agenda for today
... any concerns about the reworked agenda?
Magnus will now walk us through edits he's made...
<magnus> Digest Required 1. SHA1 (DEPRECATED; see below)
magnus: first change in Section
6.1: SHA-1 listed as REQUIRED but DEPRECATED
... HMAC-SHA1 also REQUIRED but DEPRECATED
<magnus> 6.2 Message Digests 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 for backwards-compatibility reasons.
mullan: "Deprecated" can mean different things to different people
hlockhar: does w3c have an official definition of deprecated?
tlr: thinks the thing being said
here is that use of the algorithm is being deprecated
... doesn't think we're hitting any of the official w3c rules
... could say "use discouraged"
scantor: like "use discouraged"
(sense of room: everyone like "use discouraged" better)
magnus: similar changes in XMLENC
... also added SHA384
... which was missing from XMLENC
... notes that the Message Authentication section lists XMLDSIG as "Recommended"
<magnus> 5.7 Message Digest Message digest algorithms can be used in AgreementMethod as part of the key derivation, within RSA-OAEP encryption as a hash function, and in connection with the HMAC message authentication code method as described in [XML-DSIG].) 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 R
<magnus> Identifier: http://www.w3.org/2000/09/xmldsig# (RECOMMENDED) XML Signature [XML-DSIG] is OPTIONAL to implement for XML encryption applications. It is the recommended way to provide key based authentication.
(discussion as to why Section 5.8 is in the spec)
fjh: why do we need this section here??
scantor: related to a portion of the encryption spec
magnus: leave the message authentication section for now?
accept Magnus's edits to XMLDSIG and XMLENC
... to accept Magnus's edits concerning SHA-1 to XMLDSIG and XMLENC (making SHA-1 "use discouraged" in both documents)
ISSUE: add C14N1.1 to the list of canonicalization algorithms in Section 5.9 of XMLENC
<trackbot> Created ISSUE-125 - Add C14N1.1 to the list of canonicalization algorithms in Section 5.9 of XMLENC ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/125/edit .
<fjh> Canonical XML 1.1 (omits comments)
<scribe> ACTION: Magnus align XMLENC 1.1 with XMLDSIG 1.1 [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-287 - Align XMLENC 1.1 with XMLDSIG 1.1 [on Magnus Nyström - due 2009-05-20].
ISSUE: Clarify XMLENC Section 5.8 (Message Authentication)
<trackbot> Created ISSUE-126 - Clarify XMLENC Section 5.8 (Message Authentication) ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/126/edit .
scantor: if it's not trying to
explain some part of the functionality of the XMLENC spec, it
should come out
... can't tell what the purpose of that section is
hlockhar: we appear to be listing
things at two different levels
... we don't have equivalent things in Signature pointing to Encryption
fjh: make reconciliation of this section part of ACTION-287
<trackbot> ACTION-270 -- Magnus Nyström to compare text of IEFT encryption to that in current draft -- due 2009-05-31 -- PENDINGREVIEW
<trackbot> ACTION-271 -- Brian LaMacchia to compare text of IEFT encryption to that in current draft -- due 2009-05-31 -- OPEN
<fjh> sections 5.6.2 and 5.6.3
<fjh> close action-271
<trackbot> ACTION-271 compare text of IEFT encryption to that in current draft closed
magnus: Thomas had asked why we
have this very explicit description of key wrapping in our
specs when they exist in IETF specs
... action was to compare our text w/ IETF text and make sure they're equivalent before removing from our text and just pointing to the IETF specs
... having compared the text, the descriptions give the same output (although described with different variable names)
scantor: it's spelling out the algorithm in the RFC
fjh: what would the proposal be?
magnus: tlr raised this on the
main mailing list
... proposal would be to just refer to the IETF RFCs
... edits would be to remove the algorithm descriptions from sections 5.6.2 and 5.6.3 and replace with a shorter pointer to the corresponding RFCs
<scribe> ACTION: Magnus make updated to 5.6.2 and 5.6.3 to remove the explicit algorithm descriptions and add references to the IETF RFCs [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-288 - Make updated to 5.6.2 and 5.6.3 to remove the explicit algorithm descriptions and add references to the IETF RFCs [on Magnus Nyström - due 2009-05-20].
<trackbot> ACTION-270 compare text of IEFT encryption to that in current draft closed
scantor: the more I read section 5.8 on message authentication, the more unrelated it seems
fjh: suggest taking a look at the
work EXI did in specifying C14N options.
... to see if there's anything there we can take advantage of
esimon2: looked at this a while ago, don't think it had anything related to the fidelity options
scantor: in schema at least,
lexical form means what's in the doc
... could have an option during c14n where you adopted rules from the schema normalization process (not sure you'd want this)
fjh: example: 1/0 for true/false?
... first question: do we want to call this piece "canonicalization" going forward?
... is it something else?
... in particular, we're probably not going to reuse the original algorithms
<esimon2> The work I did with EXI was to review the EXI use cases as they pertained to XML Signature and XML Encryption. There was no specific focus on the fidelity options. Link to my report here: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/att-0025/EXI_Use_Case_Review.html
scantor: it it more helpful or confusing to relate the new work back to the original algorithm?
pdatta: was planning to call it canonicalization
scantor: given that this is going to drop into the existing spec, is it right to call it canonicalization?
fjh: thinks we can defer that question for now
esimon2: thinks that there will be a need for something called "EXI Canonicalization"
fjh: we're kind of doing both
... mixing discussion of "new" C14N with the EXI C14N work
<esimon2> My comments referred to the EXI c14n work.
scantor: is it worth considering
identifying the content that carries QNames
... could be a piece of schema-awareness
pdatta: thinks it's not just
qnames in content
... well-known prefixes
hlockhar: why does it matter?
<fjh> an example would be helpful
<esimon2> Sort of a general comment...I'm uncomfortable with how XML applications can use qualified names within content without markup indicating the qualifier is a qualifier.
bal: I don't believe it's our job to do a canonicalization algorithm for EXI in this group
<esimon2> It certainly is valid to distinguish between what is "our" job and what is "their" job, but we also need to be ready to co-ordinate across groups where necessary.
hlockhar: an alternate view is that EXI is a valid, alternate serialization of XML and XMLDSIG should support every valid serialization.
<fjh> issue: should XML Security WG consider supporting and/or defining EXI canonicalization
<trackbot> Created ISSUE-127 - Should XML Security WG consider supporting and/or defining EXI canonicalization ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/127/edit .
hlockhar: a lot of vendors have
adopted this algorithm where they "pre-process qnames"
... in practice what we've discovered is that the model that the app knows the data it wants to preserve is false
<esimon2> Hal's comment is why I expressed my "general comment" above.
hlockhar: before calling DSIG the
app does a pre-scan, looks for another with a prefix, adds that
to the exclusion list
... users of DSIG turn out not, in practice, to be aware of the data to be preserved
scantor: two ways to think about
the prefix list
... 1) "here's the list of prefixes I want you to treat differently"
... 2) "here are the nodes with values I want you to treat as qnames"
fjh: why is that easier than just providing the prefix list?
scantor: you have the problem of having to scan the document
<esimon2> I consider the fact that XML apps can use/need to use qualified names that are not clearly marked up to be a core XML issue that needs to be fixed (within the XML group).
scantor: issue is whitespace is
... usually whitespace is mixed (sometimes significant, sometimes not)
... in web services it's often insignificant but sometimes is
...example: in SAML you could probably get away with making whitespace always insignificant, but you don't know about whitespace in the body of a SOAP message
... so in most cases you're forced to treat the whitespace as significant
fjh: so this is like the qname stuff
scantor: we should debate having the option if it's going to be rarely used
pdatta: in practice, even if whitespace is significant, does it need to be normalized?
scantor: place where we run into
"really not significant" whitespace is mixed content
... usually it's got either text or elements
hlockhar: text mixed with child elements
scantor: most of the time, mixed
context is not true
... none of the whitespace outside of the element tags is relevant
scantor: if you know the schema
you will know if there's mixed content
... can also have one text node w/ leading whitespace
(fjh & scantor have a long, in depth conversation on the various types of element/whitespace configurations)
<esimon2> The need for XML canonicalization is if there is a possibility that the XML instance will be be run through an XML intermediary processor that might alter the binary of the XML instance. If whitespace is significant, there has to be a standard way of knowing that so that intermediary processors know what they must preserve. If the preceding is not true, then XML canonicalization is not necessary.
fjh: you could just flag whether mixed content is expected to be there.
<esimon2> Thanks Frederick. I don't have anything to add to my written comments unless people want to comment on my comments.
scantor: the whole
scanning-the-document issue was for exclusion not
... if you're serializing, adding a few tests isn't a big deal
<csolc> can we have a list of namespaces that don't support mixed content. then if we encounter a node in that namespace that contains a text node and an element then we know we can just skip the text node
I agree with Ed's comments
I would like us to have a mode where we can avoid diving into the complex canonicalization if the sender and verifier know there isn't going to be any intermediate processors
scantor: there is no real impact on performance if you have a hash list of nodes that expect to have mixed context
<esimon2> In response to Brian (bal), I would say that if there is no intermediate processor, no c14n is necessary -- the XML can be, and is being, treated as opaque binary (as it should be).
<fjh> scott notes can list nodes that have qnames as well as nodes that have mixed content, then can apply to nodes when serializing as part of canonicalization
<klanz2> Started on my ACTION: http://www.w3.org/2008/xmlsec/Drafts/c14n-note/
pdatta: you could have a list of namespaces not nodes
scantor: doesn't think that'll be the right level of granularity
esimon2: don't think there's an
issue with whitespace.
... only need c14n if your signed data is going to be processed by an intermediate processor
esimon2: if you have an
intermediary processor, then every intermediate needs to know
if the whitespace is significant
... don't think there's a lot that needs to be said about whitespace
scantor: i don't agree with that
klanz2: could someone please
bring me up to speed on what happened since yesterday?
... i've started to draft a langage about what c1n should or shouldn't do in the meanwhile
<fjh> review these minutes - http://www.w3.org/2009/05/12-xmlsec-minutes.html
klanz2: coming back to
whitespace, it has two meanings
... 1) pretty-printing: there for editing/display
... could be preserved but not signed
esimon2: if there's no intermediary processor then you don't need c14n
<fjh> if xml:space is ignored, then is it indeterminate as to what is done
scantor: there's always an
... the serializer is an intermediary processor
<klanz2> Yes you sign in an abstraction
<csolc> +1 to scott's comment
<fjh> signing then serialization which might include indentation
<fjh> noted by scott
esimon2: Office OpenXML example
<fjh> bal notes cannot default to assume no changes will happen, need explicit agreement
<klanz2> re whitespace: http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=96
<klanz2> Signer, should be conservative in what they consider as being the Information they want to have
<klanz2> Intermediaries, are invited to process signatures with whatever tools they find appropriate. Be
<klanz2> conservative in what you have to touch for processing, especially do not touch signed documents
<klanz2> and use opaque containers (subsection 3.2.3 on page 57). If yet available <xml> ... </xml>
<klanz2> (subsection 4.1.1 on page 79).
fjh: I think I understand that it's indeterminate b/c it depends on how you serialize
<klanz2> Intermediaries and verifiers, do not touch what was meant to be signed, and hence has been
<klanz2> signed or the signature breaks.
<klanz2> * Verifiers, only what is signed (i.e. DigestInput) should be shown as signed or processed as
fjh: and if we're talking about hardware, we have to be explicit about the workflow
scantor: if you design the system correctly you can make it robust, but you don't always have that control and we have lots of user evidence to the contrary
<esimon2> <Manifest xmlns:opc="http://schemas.openxmlformats.org/package/2006/digital-signature"> <Reference URI="/word/document.xml?ContentType=application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"> <DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1 /> <DigestValue>6r+1JTYqIdwPWIYlSe5X8Qv9KuM=</DigestValue> </Reference>
<esimon2> from http://openxmldeveloper.org/articles/2391.aspx
scantor: you might be signing over a serialization
<fjh> issue is that after creating signature value can serialize SignedInfo even for detached signatures, and can change spaces breaking signature verification
<klanz2> You go up and down the Layers all the time http://www.w3.org/2008/xmlsec/Drafts/c14n-note/XML-Layers.jpg
scantor: it's probably not sufficient to put a flag in that says "trim whitespace"
pdatta: but that might be sufficient for a lot of users
<fjh> issue is also that for non-detached signatures can get problem when serializing xml after generating signature value
<fjh> pratik asks list of nodes, namespaces or all
<esimon2> xml:space intro: http://www.simonstl.com/xmlprim/xmlupdate/atts.html
esimon: wondering about the xml:space attribute
scantor: have never seen xml:space used
<fjh> do we need statement in XML Signature with a MUST regarding xml:space
scantor: thinks it needs to be baked into schemas to be useful
klanz2: aren't we then safe to assume we can throw whitespace away?
tlr: only seen it used in some
... XHTML is a counter-example
... <pre> for example
<fjh> issue:: add clarification in XML Signature regarding serialization impact with whitespace after generating signature value
<trackbot> Sorry, bad ISSUE syntax
<fjh> issue: add clarification in XML Signature regarding serialization impact with issue:: add clarification in XML Signature regarding serialization impact with
<trackbot> Created ISSUE-128 - Add clarification in XML Signature regarding serialization impact with issue:: add clarification in XML Signature regarding serialization impact with ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/128/edit .
tlr: xml:space isn't the rescue here
<tlr> xml:space is a red herring here.
scantor: 2 values are default
... so it doesn't help
fjh: added an issue about this.
we need clarifying text in the doc
... signature should mention it.
<klanz2> Every whitespace before and after a tag is purely for the readability of XML as such, even whitespace
<klanz2> between a tag and the beginning of text or multiple whitespace at the line end before and after a line
<klanz2> break should be considered indentation and hence not signed. Nevertheless processors shall leave it
<klanz2> unchanged. This is true unless the xml:space attribute is set to "preserve" in which case whitespace is
<klanz2> intended to be understood as carrying information and shall be signed.
<klanz2> Well isn't this currently true for XML? No, but it should be10.
<klanz2> A clear and common understanding about this would make XML securer and XMLDSIG a lot more
scantor: do we have anything in best practices?
<klanz2> flexible, because signatures would be more robust and thus better support actually signing the real
<klanz2> information electronically (subsection 2.1.2). Less signatures would break and hence less decisions
<klanz2> would have to be taken despite a broken signature, which could legally still be ok. It would further
<klanz2> make what is discussed in the following sections redundant.
<esimon2> From the XHTML schema...
<fjh> I suggest we consider what chris mentioned, possibility list of namespaces related to mixed content and whitespaces
<esimon2> <xs:element name="pre"> <xs:annotation> <xs:documentation> content is "Inline" excluding "img|object|big|small|sub|sup" </xs:documentation> </xs:annotation> <xs:complexType mixed="true"> <xs:complexContent> <xs:extension base="pre.content"> <xs:attributeGroup ref="attrs"/> <xs:attribute ref="xml:space" fixed="preserve"/> </xs:extension> </xs:complexContent> </xs:complexType
<fjh> could be simply another hash
<klanz2> could you type this to the chat
tlr: an api that sees a
canonicalization step should warn a developer if there's a
subsequent serialization step
... might be worth adding to best practices
... are we creating more complexity by adding more flags/
<esimon2> Note from the XHTML schema for the <pre> element that the xml:space attribute is defined as "preserve" so I do not see how this is considered an exception.
fjh: we seem to have a serious problem that people aren't aware that we have a serious ssue
<klanz2> dogmatic statement in the XML
<klanz2> whitespace before and after a tag is purely for the readability of XML [?] as such XML processors MUST preserve it however. Unless otherwise indicated [?] it does not carry information and hence SHOULD not be signed.
<klanz2> . . . expectation about indenting and re-indenting XML for signed documents.
tlr: adding something to best practices is the best place for this
klanz2: we need a prominent location to put something because whitespace is a pain
what is sign should not include any whitespace unless it's explicitly included
esimon: referring back to tlr's
example, schema for xhtml posted above, and it does use the
... the fact that people don't use the xml:space attribute is unfortunate.
scantor: seems like the intent
was to assume whitespace *wasn't* significant unless it was and
that's certainly not the case in practice
... no one knows what xml:space=default means
... in practice
esimon: i'm a fan of schema-aware
... xml schema is defined by w3c
<fjh> I think the important issue related to serialization should be noted in Signature specification and best practices
esimon: and there will be info in the scheme that defines (or is relevant to) the canonical form
fjh: i'm still stuck on why we
shouldn't add something into the spec
... about being careful after serialization
esimon: that seems fine
<klanz2> ScC14n ... too complex ... unfortunately no implementations available ... overkill ... would need to be parameterize able (i.e. don't go into schema assessment) ...
fjh: something belongs in the signature spec
scantor: seems like the canonicalizer needs to be xml:space aware
<fjh> this is an important issue, signature spec should say that serializing upon generating signature value should use uniform whitspace handling
<csolc> what we need is xml:space="trim"
<fjh> issue: C14N should notice xml:space
<trackbot> Created ISSUE-129 - C14N should notice xml:space ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/129/edit .
<klanz2> This section provides a recommendation for removing whitespace if it is
<klanz2> insignificant (not to be confused with ignorable whitespace) to the
<klanz2> data objects. Pure whitespace nodes should be considered insignificant
<klanz2> by default on signature creation and reflected, by putting the following
<klanz2> Transform as the last transform before canonicalization
scantor: +1 to csolc's comment
<klanz2> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<klanz2> <XPath>not(self::text()) or not(normalize-space(self::text())="" and
fjh: could we add an xml:space=trim?
<fjh> ACTION: fjh propose text on serialization issue for xml signature 1.1 [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-289 - Propose text on serialization issue for xml signature 1.1 [on Frederick Hirsch - due 2009-05-20].
scantor: maybe coming around to
the notion of removing whitespace-only nodes
... maybe that's a good starting place for people
<klanz2> text above for a section 18.104.22.168.1 Whitespace Removal in data objects referred by Reference would also retrofit this for XMLDSIG 1.0/1.1
scantor: my point about the qname
issue is that enumerating prefixes is less effective than
...xsi: only way that certain specs allow substitution (those that don't do element substitution)
... way to extend schema
... its value is a qname
... can't enumerate the prefix
... it's an attribute
<klanz2> what about prefix re-declarations
tlr: how common are qnames outside of attribute values?
<fjh> concern is both qnames in content and attributes
<klanz2> Look at our XPath Filter!!!!!!
hlockhar: in the standards world we've gone around hammering people "don't use qnames in content"
<klanz2> It uses prefixes!!!! Look at our XPath Filter!!!!!! in content!!!!!
esimon: xmldsig uses qnames in content
<klanz2> http://www.w3.org/2008/xmlsec/Drafts/c14n-note/ look at I)
<fjh> issue: how does canonicalization deal with xsi:type
<trackbot> Created ISSUE-130 - How does canonicalization deal with xsi:type ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/130/edit .
scantor: thinks it would be a good idea to add a "watch out for xsi:type" to c14n
<tlr> First law of XML canonicalization: Any assumption, however flawed, will be made in at least one XML format.
klanz2: would like to advocate
for a pragmatic approach
... if you have some form of inclusive c14n
<tlr> Second law of XML canonicalization: All attributes are special.
klanz2: you can make a pragmatic approach
scantor: so you want every level of the document to be well-formed?
<trackbot> ACTION-261 -- Thomas Roessler to update xmlsec-algorithms draft to include aes key wrap with padding uris -- due 2009-04-27 -- OPEN
<tlr> close ACTION-261
<trackbot> ACTION-261 Update xmlsec-algorithms draft to include aes key wrap with padding uris closed
fjh: we have a few options on the
... 1) we have pratik's proposal
... 2) we have xml:space
... 3) we have listing nodes vs. namespaces for dealing w/ mixed content
scantor: is there a difference between mixed content (text nodes between element nodes) and text that is the value of an element
scantor: 4) as a library author,
the default/safe thing for me to do is to turn on all the
options in (1), and in that case we *must* end up with a robust
... if turning on all the options doesn't give us a robust c14n alg then we've failed
pdataa: should we list out the various problems we've had w/ canonicalization?
pdatta: divide into two groups: whitespace & qnames
<fjh> start with
...whitespace: dom serialization. has indentation
... includes whitespace
scantor: the perception by people using these specs & tools is that whitespace is not significant, and then they are shocked to find out that the whitespace is significant
hlockhar: we're dealing with a number of intractable problems.
<fjh> inconsistency in XML environment
hlockhar: how far do we go to
insulate people from incorrect use of the specs?
... they're generating whitespace that is significant
scantor: reading xml:space, seems
like intent was to tell processors when the whitespace is
... complete opposite from the way xml is typically treated
<klanz2> it's never too late to do the right thing ;-)
scantor: if you see the xml:space
attribute, listen to it, otherwise go ahead and feel free to
... if you're going to serialize this thing separately, be careful
<fjh> in xml signature should we say that whitespace is not significant unless xml:space is stated
fjh: why can't we use signature to do the right thing?
pdatta: xml:space is not a widely-used attribute
scantor: would be easier to use xml:space if they didn't have to be declared in schema
<esimon2> Yes, to what fjh said.
<fjh> pratik suggests using something else in our spec
pdatta: copy/paste issue with documents
<fjh> pratik notes this loses spacing as well
pdatta: is there agreement that the signature should be preserved across copy/paste?
<fjh> pratik notes this is similar to soap networking intermediary issue
scantor: what you're describing sounds impossible
<fjh> bal notes get signed email, copy xml and save to disk. Later want to verify the signature
<esimon2> xml:space is very widely used. It is part of the XHTML schema and, in my view, that makes it part of every XHTML instance which today is much of the Web.
<fjh> bal notes not a subset. could work, fail clearly, or be hard to understand depending on implementation
<fjh> bal notes could relate to unicode, whitespace, tabs
<tlr> esimon, in order to know what value for xml:space is inherited from the schema, you have to be schema-aware.
<fjh> pratik notes c14n requires utf-8, but hal notes serialization need not be
<tlr> I'm not disputing that you can handle whitespace well when you're schema-aware
pdatta: biggest problem with
copy/paste is whitespace issue
... that's the one we can do something about
<fjh> scott asks if line feed in middle of whitespace could be an issue
pdatta: usually when you do a copy-paste the editors only do something with the leading whitespace
klanz2: I've seen a lot of text blocks indented as a whole in XML
scantor: write out a DSIG, base64 has a lot of indenting
<fjh> scott notes this happens when signing KeyInfo
scantor: most of the base64
problems got dealt with by fixing the tools
... we put stuff in best practices to deal with it
... run into a lot of whitespace/indentation with those data blocks
pdatta: qnames in content
scantor: problems with qnames in content
<esimon2> If data is inherently bound to an XML Schema, then XML processing (including signing, encrypting, canonicalization, etc.) should be schema aware. That, to me (though I know it is a minority opinion), is a basic XML requirement.
scantor: the approach of defining the nodes (attributes or elements) that are known to have qnames in content is more scalable
scantor: can't think of a reason why a c14n alg shouldn't be xsi:type-aware
<tlr> esimon, the "minority opinion" aspect is precisely the problem here. ;)
<fjh> scott also suggests certain things like xsi:type should be "baked in"
<klanz2> to build this in by default ScC14n failed over this
scantor: when you look at element
& attribute names, you know that certain prefixes are
... could go further, let signer declare what namespaces are being used
... in response to Konrad's comment: we're not talking about changing the existing c14n algs
fjh: agreement we reached yesterday was that we could continue to have the existing transform model & define a new transform built on Pratik's proposal that combined the simplified selection syntax w/ an option-based canonicalization model.
smullan: we had to go this way to avoid changing the existing node-set input model
esimon2: I hold an "extremist
... believes that we should be schema-aware
... proper processing of xmldsig needs to be schema-aware
... if you're not schema-aware then you're missing part of the story
... w3c working groups shouldn't be ignoring what other groups are doing
fjh: is it pragmatically possible to be schema-aware?
klanz2: yes, if you're able to
turn it off
... we have to find a trade-off where the right default is.
... we can't do it in a default mode
scantor: you can't be a little
... and we're a little-aware
<tlr> it's called EXI
scantor: "let me give you a
node-list with nodes that need this option..." -- that's a
... you don't normally have all the schemas on hand
fjh: scott noted that schema is brittle, not all is implement,
<fjh> scott noted schema is brittle, not always implemented, extensions are not always available
fjh: unpopular, non-performing
<fjh> scott notes that we are trying to convey schema like information but limit the amount
scantor: if we want to be schema-aware, we're not trying to do that w/ pratik's proposal
<fjh> scott notes to avoid issues with schema aware in general
scantor: there's an existence
proof for that
... we allow for it via the extension point
... regarding xsi:type, it exists in this grey area -- it comes from the schema spec but it's used as an extension mechanism is apps that normally don't assume schema processing
... while it is a schema thing, it is used in a non-schema context
... and maybe that was a horrible, no good, very bad thing, but it's done
fjh: so where does this leave us
pdatta: we had a couple
... per scott's suggestion, dealing w/ qnames in content
... an xsi:type attribute always has a qname in content
... also, if you give it a list of nodes which have qnames
scantor: it's partial schema
... no different than what we do with the inclusive prefix list
fjh: but this is more specific
<fjh> it says where the nodes are
<fjh> pratik plans to add these to proposal
pdatta: and you can search through the document looking for prefixes
<fjh> 1. be xsi:type aware, 2. support nodelist for nodes using QNames , 3. incorporate search for prefixes used
<klanz2> re schema assessment: http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=99 at the bottom
<fjh> will put multiple options in the proposal
klanz2: there should be granularity to allow options to be turned on and off
fjh: pratik's proposal doesn't go into defaults
scantor: even if there aren't defaults, we would need to make such recommendations
<klanz2> preserve everything by default, was wrong in the first place ... when reading what was written for xml:space in the XML spec
<fjh> 4. add xml:space awareness to proposal
<klanz2> ScC14n rightfully claims that this is in contrary to the intent of XMLNS.
<klanz2> Note that the prefix functions only as a placeholder for a namespace name. Applications
<klanz2> should use the namespace name, not the prefix, in constructing names whose scope extends
<klanz2> beyond the containing document. (XMLNS section 4 )
<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=62 at the top
<fjh> pratik notes json - xml - json loses prefixes
<fjh> pratik notes might be useful to rewrite prefixes either as URIs or as n1,n2 etc
<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=63 Namespace Prefix Desensitization
<fjh> bal notes URIs would not be well formed and n1 n2 could not guarantee sort order
klanz2: I think we have to be respectful that at the end of the day everything is dealt with in schema-centric c14n
scantor: ...we're trying to tease scc14n into a set of options that we can turn on and off
pdatta: prefix rewriting was already considered in the original spec
<tlr> +100 to scantor
<klanz2> ScC14n annotates the Schema what parts contain QNames
<tlr> I'm all for drawing that line. In concrete.
fjh: we'll talk about Magnus's
issues after lunch and the RFC issues
... suggest we continue with this discussion until 12:30
... and then break for lunch
klanz2: why are we trying to put all of this in canonicalization?
fjh: we're talking about pratik's more transform simplification transform proposal
klanz2: at the end of the day you have to specify some sort of iterator
scantor: but we're not doing
... subtrees with inclusions and exclusions
klanz2: what do you use to serialize those subtrees?
scantor: that's what we're
... that's what the selection process does
... these are the subtrees that you're supposed to output
... namespace context is inherited from the document
klanz2: only simplification is to inherit the namespace context only once
pdatta: we are not putting in a lot of implementation details in the specification.
<klanz2> and the code to inherit it once is the same code as inheriting it n times
pdatta: we want to create a declaration of what is desired and leave it up to the implementation to figure out how to do it
klanz2: transform primitives are in parallel to the original transform model
<fjh> konrad notes the approach from Pratik is acceptable
klanz2: not sure if there's any change in complexity if you inherit once or n times
<fjh> scott notes concern of well-formedness not an issue if final result is hash, per this proposal
<esimon2> Re namespace normalization, I like (my) idea of using a base64-based version of the actual namespace. Such a namespace qualifier is universal and unique and reversible to the original namespace. More info on page 14+ of http://www.w3.org/2007/xmlsec/ws/slides/18-edsimon-xmlsec/
<klanz2> but where is the difference to the processing model you just put it into the Canonicalization, it's not gone ...
<fjh> current topic is prefix rewriting and use in transform simplification model
<scantor> we're not saying that it's gone, we're saying that the totality will be vastly easier to implement from scratch
<klanz2> It should be added here that XML technologies can even be an enabler to sign information as opposed
<klanz2> to just signing data. Classes of XML documents to be signed can be accompanied by a Schema defining
<klanz2> the allowed syntax. An additional description defining the semantics of the allowed elements, attributes
<klanz2> and their interrelation complete a language definition. Such syntax and semantic definitions can be
<klanz2> published and secured by signatures themselves. Hence a kind of closure to the process of signing
<klanz2> information would be achieved using XML technologies consistently.
<scantor> and in a perfect world, we'd use schemas that way, but that's not reality
<klanz2> Progress needs a vision ...
<scantor> pushing XML Schema at this point isn't a viable vision
<klanz2> I'm not pushing Schema, I'd just not rule it out ...
<scantor> I think we can not rule it out by pointing out that using schema-aware c14n as it was proposed is still possible
<scantor> maybe we should even publish it as part of the 2.0 deliverables if its submitted
<fjh> bal notes one end is to have robust c14n to detect semantically equivalent xml
<fjh> bal notes at other end, want to avoid performance cost for that , such as in single hop case, hence want to turn this off
<fjh> bal notes transform simplification proposal might achieve this
<fjh> bal asks what is the point if we do not achieve the robustness goal
<fjh> issue: is semantic equivalence robustness in requirements document
<trackbot> Created ISSUE-131 - Is semantic equivalence robustness in requirements document ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/131/edit .
<klanz2> Minimal Canonicalization (MC14n)
<klanz2> obsoleted by RFC3275 which does not contain MC14n any more.
<esimon2> FWIW, Ed's Robust C14N Presentation: http://www.w3.org/2007/xmlsec/ws/slides/18-edsimon-xmlsec/
<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=64 Complexity / Robustness trade-off
correct, MC14N was an original proposal as part of the original XMLDSIG 1.0 work
and it was dropped later
for lack of support
<klanz2> it does not plug well
scantor: no object/preclusion to bringing scc14n to the group, but it hasn't been well-received in the past
<klanz2> re schema assessment: http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=99 at the bottom
<fjh> scott notes that a definition of schema aware c14n could be listed as another c14 alg to plug into existing xml signature
esimon2: by scc14n, not referring to just the IBM spec that was put out by them
esimon2: the question of whether two xml docs are equivalent is not well-handled by the xml specs
<klanz2> I have a hard stand in the Core Group arguing for things like that
esimon2: how do you tell if two
xml fragments are equivalent?
... hard to tell
pdatta: performance cost, code complexity cost
<fjh> pratik notes performance is xpath, nodesets
<fjh> bal notes also security vulnerability attack surface cost
<klanz2> @pratik, I don't see a huge cost saving by inheriting a context (namespaes, inheritable attributes) only once than n times, especially not in the case where the algorithm handling n-inhertance actions handles the use case instance of a subtree (with exclusions)
<fjh> scott notes semantic risk, option makes purchase order a become b
<klanz2> ... because there it handles the exact inheritance action once
magnus: new scheme for public key
... original proposoal is based on encrypt/decrypt
<fjh> presentation in pdf at http://lists.w3.org/Archives/Public/public-xmlsec/2009May/att-0032/Key_Encapsulation.pdf
<fjh> on slide 5
magnus: generate symmetric key,
encrypt symmetric key with public key, derive key from
symmetric key, encrypt with derived key
... protect against possibility that key transport mechanism is not as strong as public key mechanism
bal: there is crypto graphic advantage of using KDF
<fjh> X9.44 is base document
bal: few key derivations schemes
that NIST has proposed
... SPF 108 KDF 2
... currently we have key agreements and key transport
... add new category of Key encapsulation
fjh: is this stable?
magnus: not very new
<brich> the link in the presentation is broken...http://www.rsa.com/rsalabs/node.asp?id=3D2147
magnus: going forward it is prudent to include this - currently it is the best encryption
<fjh> magnus notes some of this has been under review for 8 years
magnus: it is not tied to any particular public key scheme
scantor: can this be plugged into current schema without schema changes
magnus: it can be plugged into KeyInfo
bal: what is SMIME doing
magnus: SMIME has identifier for hybrid method
<fjh> bal notes like cipher suite, need to define public alg, symmetric, kdf, etc
magnus: might not require changes to existing schema
<fjh> question is this an extension or require changes to current 1.1 schema. If not could go in 1.1
scantor: can it fit into EncryptedKey
magnus: EncryptedKey will have KeyInfo, this can be inside KeyInfo
<scribe> ACTION: magnus to investigate how to fit in Key Encapsulation, possibly put it in 1.1 [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-290 - Investigate how to fit in Key Encapsulation, possibly put it in 1.1 [on Magnus Nyström - due 2009-05-20].
pdatta: how would this fit in with DerivedKey proposal
<trackbot> ACTION-290 -- Magnus Nyström to investigate how to fit in Key Encapsulation, possibly provide proposal for 1.1 -- due 2009-05-27 -- OPEN
magnus: probably not use any of
the DerivedKey schema
... if the key derivation does not use any params, then you don't need the DerivedKey, can just be specified as a URI
RESOLUTION: if it doesn't cause a breaking change then we adopt Key Encapsulation for 1.1
<klanz2> need to make more edits
<klanz2> will do with in the running week
<klanz2> thx for that
<fjh> tlr notes this draft will go to the IETF after our WG approves it. Waiting for edits from Konrad
<fjh> tlr notes will go as individual submission
<fjh> no urgency on this item, or linkage to WG w3 publication plans
tlr: taking up where 4051 left
<fjh> tlr notes have to keep rfc alive
<klanz2> Maybe an error in RFC4051 is of substance to us http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0029.html
klanz2: small error in RFC
... section number is different
tlr: make an errata
<fjh> tlr notes if we update references in XML Signature we have to avoid potential error along these lines
<klanz2> Should read: This error seems to be caused by the fact that RFC2437 8.1.1 is now
<klanz2> RFC3447 8.2.1 .
<tlr> ACTION-158: note change of section numbers between 2437 and 3447
<trackbot> ACTION-158 Take pass through references in Dsig Core - update, split into normative/informative notes added
scantor: somebody was doing schema validation, they noticed problems in InclusiveNamespaces schema was broken
<tlr> E02 2002-10-03 (Error)
<tlr> In section 4 Use in XML Security, the data type of the PrefixList attribute value is specified as NMTOKENS in both the DTD and Schema. This does not permit "non-zero-length sequences," or the occurrence of the '#default' token in the attribute value because of the "#" character. Consequently, the type of this attribute value should be CDATA in a DTD and/or xsd:string in a XML Schema.
<klanz2> exc-c14n (second edition)
scantor: there is already an errata for it, do we fold in the errata into the new version
<fjh> tlr group notes group is charted to produce new edition for maintenance
tlr: we are chartered for maintainence changes, so we could do this kind of edits
scantor: errata doesn't have a fix, but has a couple of suggested fixes
<fjh> E02 2002-10-03 (Error)
<fjh> sean notes Java api went by errata
scantor: that is what list of string is (i.e. space separated strings)
<klanz2> is there an XSD file published?
tlr: short term solution edit the errata
<klanz2> is there an XSD file published? or is the schema only availiable from the spec?
<scribe> ACTION: scantor to draft a proposed fix for E02 for exc c14n [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-291 - Draft a proposed fix for E02 for exc c14n [on Scott Cantor - due 2009-05-20].
fjh: shouldn't be difficult to edit the document to incorporate the errata
<fjh> discussing whether we need F2F before TPAC
<fjh> need to review last call comments and answer
<fjh> plan to do 1.1 stuff online and use TPAC for 2.0
<Zakim> tlr, you wanted to propose a next step
<fjh> plan to let 1.1 stay in CR as necessary to achieve full interop
ACTION-142 they haven't finalized new DSA algorithms
<klanz2> what is the remaining agenda?
ACTION-174 Pratik to update best practices document before publishing
<trackbot> ACTION-259 -- Konrad Lanz to propoal for the C14N spec change -- due 2009-04-14 -- CLOSED
<klanz2> I listen
<scribe> ACTION: tlr to update Section 5.6 in Encrpyption for issue 99 [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-292 - Update Section 5.6 in Encrpyption for issue 99 [on Thomas Roessler - due 2009-05-20].
<klanz2> r, s
<fjh> konrad asks if issue if not same lengths
<klanz2> what happens if r and s have a different length
klanz2: for DSA signatures what happens if R and S do not have same lengths, how do you split them up?
bal: if they don't have same lengths, pad them
<klanz2> leading zeros for the shorter of the two would solve the issue
<klanz2> so you can always seperate at the halve
bal: R and S have to be 20 bytes
<klanz2> r is a random it can be anything
<klanz2> so I2OSP operation does not specify that
<klanz2> okay then let's make it explicit
tlr: make is clear in the spec
<fjh> I2OSP operation defined in the RFC 2437 [PKCS1] specification with a l parameter equal to 20.
<fjh> bal notes this says they are the same and 20 each
magnus: R and S cannot be less than 20, if you do it means you haven''t followed the DSA spec
<fjh> fifteen minute break
<fjh> start again at 3:15 et
<fjh> all marked completed
<scribe> ACTION: fjh to update Associate product list in Open Actions tracker to include all docs [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-293 - Update Associate product list in Open Actions tracker to include all docs [on Frederick Hirsch - due 2009-05-20].
<klanz2> The implicitness of fixed lengths for R and S seems to be in http://tools.ietf.org/html/rfc4051#section-2.3.6 , I knew there was something around this ... and it's now clarified in http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/#sec-ECDSA, so tlr do you think it's worth mentioning alongside with thze other RFC4051 issue?
ACTION-77 will take a long time to make this change
<trackbot> ACTION-77 -- Sean Mullan to update best practices document for section titles -- due 2008-10-14 -- OPEN
<fjh> suggest we defer this one until someone available to make the change
<fjh> agree with desire
<trackbot> ACTION-103 -- Juan Carlos Cruellas to provide updated email on best practices issue -- due 2008-11-11 -- OPEN
<fjh> I will update this offline
<fjh> switch order of BP 1 and 2, rename BP 1
<fjh> "Mitigate denial of service attacks by validating the references (that
<fjh> might imply potentially dangerous operations ) only after the
<fjh> verification of SignedInfo has been completed"
<fjh> Best Practice 1: Mitigate denial of service attacks by executing potentially dangerous operations only after authenticating the signature
<fjh> note that best practices in document are not ordered
<fjh> proposal add after step 1 in best practice 1, see Best Practice 2
<fjh> proposal do not reorder best practices
<fjh> RESOLUTION: update best practice 1 to refer to best practice 2 in step 1, do not reorder and no other changes
<fjh> action fjh update best practices for this
<trackbot> Created ACTION-294 - Update best practices for this [on Frederick Hirsch - due 2009-05-20].
<fjh> action fjh update best practices to update best practice 1 to refer to best practice 2
<trackbot> Created ACTION-295 - Update best practices to update best practice 1 to refer to best practice 2 [on Frederick Hirsch - due 2009-05-20].
<fjh> action-294 closed
<trackbot> ACTION-294 Update best practices for this closed
<tlr> ACTION-foo: asdfasdf
<scantor> ACTION-103: addressed with http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0030.html
<trackbot> ACTION-103 Provide updated email on best practices issue notes added
<tlr> close ACTION-103
<trackbot> ACTION-103 Provide updated email on best practices issue closed
<esimon2> À la prochaine, Ed
<trackbot> ACTION-128 -- Konrad Lanz to document e-gov use cases -- due 2009-01-06 -- OPEN
<trackbot> ACTION-174 -- Pratik Datta to update the transforms related to ISSUE-69 -- due 2009-01-21 -- OPEN
<trackbot> ACTION-177 -- Scott Cantor to document requirements for RetrievalMethod -- due 2009-01-22 -- OPEN
<fjh2> we may add new material to new schema, allowing retrieval method intact
<fjh2> adding ids to existing schema
<fjh2> for 2.0, need to add id attributes
<fjh2> action-177: this is for 2.0, resolved by adding id attributes where needed, updating schema
<trackbot> ACTION-177 Document requirements for RetrievalMethod notes added
<fjh2> action-177: closed
<trackbot> ACTION-177 Document requirements for RetrievalMethod notes added
<trackbot> If you meant to close ACTION-177, please use 'close ACTION-177'
<fjh2> action-177 closed
<trackbot> ACTION-177 Document requirements for RetrievalMethod closed
<fjh2> scott asks if we add to schema without changing namespace, how do we communicate changes related to schema
fhj2: if we pretend that we have wildcards and add new elements
scantor: can have unpredictable
... should be copy the namespace and add all the elements into the new schema
tlr: is URI manadatory in reference
smullan: it is optional, it can
be omitted once
... which means that it is implementation defined
<fjh2> scott notes issue that if we have new ds2:Reference for new transform then we cannot add with existing namespace because there is no exensibility point
smullan: every transform required a nodeset or an octetStream, that is why we can't use existing Reference
<fjh2> tlr asks if when there is no URI attribue then transform is new single transform case
<fjh2> we have a choice of new namespace for all, breaking backward compatibility, but also then fix schema issue
<fjh2> other choice is to keep current schema but then allow new Reference
scantor: we want to use RetrievalMethod
<klanz2> the old reference will stay in the old namespace?
<klanz2> +1 to tlr
scantor: huge downsiide of changing the namspapce of dsig:Signature - all dependant specs have to change
<fjh2> new child elements are possible in KeyInfo
tlr: RetrievalMethod is child of KeyInfo which allows extensibility
<tlr> proposal: define new children for KeyInfo
smullan: we can use the a hack - have zero byte octet stream or empty nodeset input to this special transform
<fjh2> decision for wg - new namespace for all of 2.0 or attempt to hack to keep old schema yet extend without extension points
scantor: saml schema can never change
fhj2: we were supposed to allow breaking changes
<klanz2> I'm not sure web service appliances care about uglyness ;-)
scantor: references have a type
... use type to indicate new processing architecture
<fjh2> i thought charter indicated 2.0 could have breaking changes and new namespace but agree that if we can achieve results without breaking existing uses that is a noble goal
<fjh2> the current question - how to add new simplified transform without breaking schema
<fjh2> scott has proposal to use type to indicate new transform and to handle input appropriately
tlr: type attribute has two URI values for it
<klanz2> what is the problem with a single custom binary to binary transform?
<smullan> <Reference Type="DSig2.0"><Transforms><Transform><SelectionTransform URI=""> ...
<fjh2> adding something assuming a wildcard that isn't there may produce indeterminate results
<fjh2> this is different than error that is anticipated, e.g. unknown transform
scantor: by adding a Reference2 element ,we get an unpredictable failure, but by adding a new transform we get a predicatable failure
<klanz2> that what currently goes on
<fjh2> so we say type Dig2 then input of binary error
<fjh2> have 3 types, octet stream, nodeset, the new thing
<fjh2> goal - modify processing model but not schema
<fjh2> goal - avoid implicit conversions
<fjh2> question - how do we learn whether there is a problem with using Type this way?
<scantor> there may be multiple ways to express the new processing model within Reference that we want
<klanz2> if a URI is dereferenced and XPointers are not used only complete subtrees will be dereferenced
<klanz2> entites external to the document are binary anyway ...
<klanz2> take the first node from the node-set and throw away the nodeset
<klanz2> pratik, you are hard to understand
<fjh2> pratik notes could not have to use Type by recognizing first transform if it is the new one, then process appropriately and disallow additional transforms
<klanz2> cannot follow, mumbling
<klanz2> scott, has good audio
<fjh2> scott has mic in front of him
<klanz2> +1 to scott
<klanz2> you do not have to make the expansion
<klanz2> URI="" it's on the current document
scantor: the spec for transforms
say that some transforms take nodeset and some take
... add a third type - transforms that take an URI
<klanz2> why can't the input be a CONSTRAINED Nodeset that SHOULD not be implemented as NodeSet
<fjh2> As described in The Reference Processing Model (section 22.214.171.124), some transforms take an XPath node-set as input, while others require an octet stream. If the actual input matches the input needs of the transform, then the transform operates on the unaltered input.
<fjh2> could add third input to this list, change rule for transformation of input
<fjh2> third being URI without dereferencing
<fjh2> and no implicit conversion
<klanz2> The enhancements would be clerly outlined inside a ds:Transform
<tlr> I want version numbers that converge to e/2
<klanz2> fully backward compatible, and forward compatible if the transform is plugged in
<tlr> or e/sqrt(2)?
<klanz2> the new transform can even be plugged into old dsig implementations if they define a node-set data to pratiks datamodel converison
<fjh2> do we need both 1.1 and 1.5
<klanz2> because you need to pulugin the transform
<klanz2> now we're talkin spec ...
<klanz2> out of a transform ...
<fjh2> what are we cutting out in 1.5
<klanz2> what about two conformance levels FULL and PERFORMANCEMODE
<fjh2> ack 2.0
<klanz2> the dependencies to SAML ...
<klanz2> etc ...
<fjh2> 2.0 may keep the existing schema, extend with new performance, but remove lots of stuff, need to clear
<fjh2> ACTION: fjh send email about roadmap [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-296 - Send email about roadmap [on Frederick Hirsch - due 2009-05-20].
<trackbot> ACTION-142 -- Brian LaMacchia to come up with identifiers and add to the algs doc for the new DSA algorithms -- due 2009-01-20 -- OPEN
<fjh2> need to address before 1.1 published?
<fjh2> stalled on FIPS-186-3 coming out... wait to last call
<trackbot> ACTION-215 -- Thomas Roessler to fix contributors' list -- due 2009-03-30 -- OPEN
<fjh2> before last call?
<trackbot> ACTION-217 -- Thomas Roessler to add boilerplate language about optional algorithms -- due 2009-03-18 -- OPEN
<trackbot> ACTION-257 -- Konrad Lanz to follow up and provide unified proposal for changes to support randomized hashing and signing -- due 2009-04-14 -- OPEN
<fjh2> we defer randomized hashing for 2.0
<fjh2> action-257: we defer randomized hashing for 2.0
<trackbot> ACTION-257 Follow up and provide unified proposal for changes to support randomized hashing and signing notes added
<klanz2> I keep pinging the person giving me info on whether Salt's can be reued in randomized hashing and RSA-PSS
<tlr> s/whether salts/whether/salts/
<tlr> konrad, I think that sharing of salts is (a) a bad idea, (b) not worth any effort
<tlr> I woulnd't bother with that
<klanz2> well entropy is expensive especially on small devices
<trackbot> ISSUE-83 -- Ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051? -- OPEN
<fjh2> issue-83: see RFC draft
<trackbot> ISSUE-83 Ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051? notes added
<fjh2> issue-83 closed
<trackbot> ISSUE-83 Ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051? closed
<klanz2> sharing of salts: to (a), I don't think they are problematic and should be much like http://en.wikipedia.org/wiki/Hash_tree
<fjh2> issue-87: suggestion is to not allow transforms for RetrievalMethods in 2.0 processing rules, even though we do not change schema
<trackbot> ISSUE-87 Determine approach to RetrievalMethod in 2.0 with regard to transforms, if any, or if revised transform approach notes added
<trackbot> ISSUE-92 -- Include the \"implicitCA\" option for ECKeyValueType and separate ECDomainParameterType type -- OPEN
<fjh2> remove note for 1.1 in 2 June
<trackbot> ISSUE-94 -- In the ECParameterType type definition, note that the <Order>element may also be a large number and hence the use of the\"integer\" type may again be problematic -- OPEN
<fjh2> issue-94 closed
<trackbot> ISSUE-94 In the ECParameterType type definition, note that the <Order>element may also be a large number and hence the use of the\"integer\" type may again be problematic closed
<fjh2> tlr notes may have similar issue in KeyInfo
<fjh2> defer for 2.0
<fjh2> X509Data cloning can solve serial number issue
<fjh2> says scott
<trackbot> ISSUE-100 -- Ripe URIs -- OPEN
<fjh2> issue-100: duplicate, dealing with RFC algorithm document
<trackbot> ISSUE-100 Ripe URIs notes added
<trackbot> ISSUE-104 -- Carry existing ds:References into new XMLDSIG 2.0 -- OPEN
<fjh2> best practices warn about extension
<klanz2> but I can plug in the new transform in the old ds:Reference ...
<fjh2> alternative is to remove stuff
<trackbot> ISSUE-105 -- HMAC output length is defined on bits base64 on octets -- OPEN
<fjh2> padding issue
<fjh2> pad with leading 0's to octet boundary
<tlr> ACTION: konrad to propose change to 1.1 to address issue-105 [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-297 - Propose change to 1.1 to address issue-105 [on Konrad Lanz - due 2009-05-20].
<fjh2> RESOLUTION: change 1.1 to address this issue
<fjh2> action klanz to propose change for HMAC output length to pad with leading 0s to octet boundary
<trackbot> Created ACTION-298 - Propose change for HMAC output length to pad with leading 0s to octet boundary [on Konrad Lanz - due 2009-05-20].
<trackbot> ISSUE-110 -- Need better definition for "visibly utilizes" in Exc-C14N -- OPEN
<trackbot> ISSUE-110 -- Need better definition for "visibly utilizes" in Exc-C14N -- OPEN
<fjh2> errata issue?
<tlr> ACTION: scantor to look at issue-110 and errata document for exc-c14n [recorded in http://www.w3.org/2009/05/13-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-299 - Look at issue-110 and errata document for exc-c14n [on Scott Cantor - due 2009-05-20].
<trackbot> ISSUE-111 -- Clarify role of document use case in renamed 2.0 versus 1.1 -- OPEN
<fjh2> issue-111: give name to 2.0 if needed
<trackbot> ISSUE-111 Clarify role of document use case in renamed 2.0 versus 1.1 notes added
<fjh2> issue-111 overlaps Reference processing discussion for 2.
<fjh2> issue-111 closed
<trackbot> ISSUE-111 Clarify role of document use case in renamed 2.0 versus 1.1 closed
<trackbot> ISSUE-116 -- C14N clarification and errata as noted by Konrad wrt ACTION-259 -- OPEN
<trackbot> ACTION-259 -- Konrad Lanz to propoal for the C14N spec change -- due 2009-04-14 -- CLOSED
<trackbot> ACTION-259 -- Konrad Lanz to propoal for the C14N spec change -- due 2009-04-14 -- CLOSED
<trackbot> ISSUE-117 -- Key Wrap -- OPEN
<fjh2> issue-117 closed
<trackbot> ISSUE-117 Key Wrap closed
<trackbot> ISSUE-123 -- How in 2.0 to disallow SHA-1 when algorithm URI currently defined -- OPEN
<tlr> lSSUE: Define padding for non-15 minute segments remaining in the end of meeting days (blocks 2.0)
<fjh2> issue-123: not removing URIs, changing processing rules
<trackbot> ISSUE-123 How in 2.0 to disallow SHA-1 when algorithm URI currently defined notes added
<tlr> RESOLUTION: meeting will be adjourned in 2 minutes
<fjh2> RESOLUTION: Thank you to Magnus and RSA for excellent hosting.