See also: IRC log
Present
Cynthia_Martin, Frederick_Hirsch, Hal_Lockhart,
Brian_LaMachia, Kelvin_Yiu, Konrad_lanz, Thomas_Roessler, Pratik_Datta,
Chris_Solc, Gerald_Edgar, Sean_Mullan, Brad_Hill, Bruce_Rich
Regrets
Shivaram_Mysore, Thomas_Roessler, Ed_Simon
Chair
Frederick Hirsch
Scribe
Cynthia Martin, Cynthia
·
Topics
2.
Liaisons
5.
DSS security consideration changes
8.
Exclusive Canonicalization Errata
10.
Actions
11.
Issues
<trackbot> Date: 07 July
2009
/invite Zakim #xmlsec
<Cynthia> Meeting: XML
Security WG Teleconference
Date: 07 July 2009
<Cynthia> Chair:
Frederick Hirsch
<Cynthia> Scribe: Cynthia
Martin
<Cynthia> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0006.html
<Cynthia> ScribeNick:
Scribe
Administrivia
<fjh> http://www.w3.org/News/2009#item113
<fjh> Candidate
Recommendation of Widgets 1.0: Digital Signatures.
<Cynthia> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0006.html
Fredrick: Meeting next week, Brad will scribe next week
<fjh> TPAC registration
open
<fjh> Please register: http://www.w3.org/2002/09/wbs/35125/TPAC09/
<fjh> XML Security
Thursday and Friday 5-6 November as originally planned.
Liaisons
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0074.html
Fredrick: RNG Schema, we need to ID some people to review/help with work on the
Widgets 1.0 conformance testing- do we need to do this or only demonstrate
interoperability?
<fjh> Candidate
Recommendation of Widgets 1.0: Digital Signatures
<fjh> http://www.w3.org/News/2009#item113
Fredrick: Can we help them if they need it?
Announcements
<fjh> NIST
"Transitions" presentation
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0071.html
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/att-0015/23-xmlsec-minutes.html
RESOLUTION: 23 June 2009
minutes approved
Editorial Status
<fjh> ACTION-142?
<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 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/142
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0008.html
<fjh> noted not defining
224
Brian: One additional identifier, with explanatory text, optional to implement...
No key length for RSA or DSA in the identifiers
Fredrick: ID in the interoperability file name for testing instead
Thomas: Comment- Update to algorithm
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html
Brian: ... 3b) XML Signature 1.1, Section 6.3.1 to resolve ACTION-320, Brian
ACTION-320
<fjh> ACTION-320?
<trackbot> ACTION-320 -- Brian
LaMacchia to draft language for HMAC section, 6.3.1 -- due 2009-06-23 --
PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/320
<klanz> Is this a
constraint on verifiers as well?
<klanz> what is the
escalation?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0009.html
Konrad: Clarify the language on the constraints
<fjh> Brian: notes were
undefined in 1.1
<fjh> Brian: hence it
does not impact conformance
Brian: We didn't specify what conformance would be in that case (in 1.1)
Thomas: Is this a problem where the fix is worse than the problem?
<klanz> That was my
language: http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html
<klanz> In the spirit of
RFC2104 [HMAC]
<klanz> http://tools.ietf.org/html/rfc2104#section-5
:
<klanz> > Applications
<klanz> > of HMAC can
choose to truncate the output of HMAC by outputting the the
<klanz> > leftmost
bits of the HMAC computation for some parameter t (namely,
<klanz> > the computation
is carried in the normal way as defined in section 2
<klanz> > above but
the end result is truncated to t bits).
Brian: If you zero pad, is the padding at the beginning or the end?
<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html
Konrad: Deal with differentiation.
<klanz> <klanz>
Issue 105 and action 297 are actually now on Brian to follow up on http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html
Fredrick: Information not found in minutes, Brian did what WG wanted
<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/att-0015/23-xmlsec-minutes.html
Fredrick: May need to consolidate some of the actions
Konrad: Would have preferred that it be in increments of 8
Brian: Under the old specification, we did not have this defined
<fjh> Brian: notes
original spec was not interoperable because padding was not clearly defined
Brian: You cannot ignore a partial byte, need to verify the bits in the
truncation
Konrad: No strong opinion on this
Fredrick: Let's not spend additional time, send it on the list if it is important
... If there is serious objection, it must be on the list
ACTION-319?
<trackbot> ACTION-319 --
Kelvin Yiu to and Brian to update DH & ECDH sections to take advantage of
new KDF section -- due 2009-06-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/319
<fjh> action-319?
<trackbot> ACTION-319 --
Kelvin Yiu to and Brian to update DH & ECDH sections to take advantage of
new KDF section -- due 2009-06-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/319
Brian: Sent information on list, but it was later in the day
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0010.html
Brian: Refactor the section to handle KDF
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-DHKeyAgreementNewKDF
Brian: This is updated in revision 1.30: DH key agreement section now split into
new and legacy KDF sections.
... Absence or presence of KA-Nonce is the trigger between the two options.
... Require this for interoperability to support new and legacy KDF
Fredrick: Is there no way to do this without a nonce?
Brian: That is correct
... Should be looking at the XML Encryption Schema
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-KeyAgreement
Brian: The nonce and digest method were under the any
... You have to know the key agreement algorithm before you know anything else
... I had back conversations with Kelvin, came up with this to distinguish
between new and legacy
Fredrick: What about using an attribute?
Brian: No, we don't want to mess with the schema
<fjh> Scott: could use
two different algorithm URIs
Kelvin: If you define a new URI (DH with mode), it would benefit this
Fredrick: Rather to be more specific
<scantor> don't feel
strongly, but I think a second URI is slightly cleaner
Fredrick: If we create a new URI, we are splitting it and maintain the old one for
backward compatibility
Kelvin: Benefit of new URI, better for new applications
Brian: Could be restructured, the old ID must use the legacy KDF and the new
would not
... This would not be a huge change, it would be ok
Fredrick: We don't have to find the nonce
Brian: Would still have to support both (any)
... Happy to make that change, and define new KGF for that
<fjh> Continued
discussion to use new URI for new KDF dh so that not rely on presence of nonce
to determine approach
<fjh> benefit that old
implementation won't break on new form when nonce is not present, yet uri the
same
<fjh> I believe it’s
better to be explicit where we can
<Cynthia> ACTION:
Brian to update ACTION 319 for explicit URI [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action01]
<trackbot> Created
ACTION-326 - Update ACTION 319 for explicit URI [on Brian LaMacchia - due
2009-07-14].
ACTION-283?
<trackbot> ACTION-283 --
Thomas Roessler to update algorithm xref draft to note new status of sha-1 --
due 2009-05-19 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/283
<fjh> action-283?
<trackbot> ACTION-283 --
Thomas Roessler to update algorithm xref draft to note new status of sha-1 --
due 2009-05-19 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/283
<fjh> action-283 closed
<trackbot> ACTION-283
Update algorithm xref draft to note new status of sha-1 closed
<fjh> Notes on using
XMLSpec tool
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0013.html
<klanz> did you add it to
the members page?
<klanz> the xmlspec intro
DSS security consideration changes
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0005.html
Fredrick: Brian updated the DSS security warning, Cynthia sent out comments
<fjh> Add
"bits" in two places in "defined to be 1024, 2048 or 3072 and
<fjh> the corresponding
DSA q value is defined to be 160, 224/256 and 256
<fjh> respectively"
yielding "defined to be 1024, 2048 or 3072 bits, and the
<fjh> corresponding DSA q
value is defined to be 160, 224/256 and 256 bits
<fjh> respectively
<fjh> in 2nd paragraph
change "required" to "requires"
RESOLUTION: Accept changes
for Action 283
<Cynthia> ACTION:
Update Action 283 [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action02]
<trackbot> Sorry,
couldn't find user - Update
ACTION-325?
<trackbot> ACTION-325 -- Cynthia
Martin to propose changes to Signature references -- due 2009-06-30 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/325
Cynthia: Yes, I am still working on it, I hope it will be done today
<fjh> ACTION:
bal to update DSS security warning [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action03]
<trackbot> Created
ACTION-327 - Update DSS security warning [on Brian LaMacchia - due 2009-07-14].
ACTION-324?
<trackbot> ACTION-324 --
Cynthia Martin to review http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0044/xmlenc-ref.html
for normative and informative -- due 2009-06-30 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/324
<fjh> update references in
XML Encryption 1.1
Fredrick: Cynthia sent out comments to the list
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0044/xmlenc-ref.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0014.html
<fjh> move RIPEMD-160
reference to normative section , used in 5.8.5
<fjh> Move MIME reference
to normative section, used for MimeType value definitions
Fredrick: Accept this and put it in draft
Cynthia: Comments are mostly related to RFC and link changes, no problems
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0047.html
RESOLUTION:
Accept updates and recommended changes to XML Encryption 1.1
references
<fjh>
ACTION:
fjh to update xml signature references [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action04]
<trackbot> Created
ACTION-328 - Update xml signature references [on Frederick Hirsch - due
2009-07-14].
Fredrick: Would like to publish at next call
Cynthia: Will have it done this week
Review and update XML Signature and XML
Encryption explain documents
Fredrick: started to update the explanation documents, need to work
Cynthia: I can look at reviewing this and help you out
<fjh> ACTION:
fjh review and update explain documents for xml signature and encryption
[recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action05]
<trackbot> Created
ACTION-329 - Review and update explain documents for xml signature and
encryption [on Frederick Hirsch - due 2009-07-14].
Ready to publish 1.1?
<fjh> ACTION:
tlr to update algorithms doc per http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html
[recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action06]
<trackbot> Created
ACTION-330 - Update algorithms doc per http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html
[on Thomas Roessler - due 2009-07-14].
<klanz> Re ACTION-320: http://lists.w3.org/Archives/Member/member-xmlsec/2009Jul/0001.html
Updated since last published: XML Signature
1.1, XML Encryption 1.1,XML Security Algorithms Note, XML Security Generic
Hybrid Ciphers (FPWD), Best Practices, XML Signature Transform Simplification:
Requirements and Design
Fredrick: Where are we with the Security Generic Hybrid Ciphers (FPWD)
... Want to get this out of the way, finish it up
Brian: Put a second working draft out, should not be a final doc
Fredrick: This is dated, need to be clear on the public page
<fjh> http://www.w3.org/2008/xmlsec/Drafts/key-encapsulation/key-encapsulation.html
Fredrick: Need to look at roadmap to check publication dates
... Still open issues with this- may have to defer it and wait for comments
... agree to publish this next week, get it out for comments
Cynthia: Yes, sounds reasonable
C14 2.0 Draft
<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/Overview.html
Fredrick: Sent comments to the list
Pratik: Review of draft, Canonical XML Version 2.0 is a major rewrite of Canonical
XML Version 1.1 to address issues around performance, streaming, hardware
implementation, robustness, minimizing attack surface, determining what is
signed and more. It also folds the 2.0 version of Exclusive Canonicalization into
same document
<fjh> I had a few
questions and comments: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0011.html
Pratik: Discussion on section 1.4.1 Performance
... 1.4.1 Performance
<fjh> comment - might
want to mention qnames in context explicitly in requirements section
Pratik: Discussion on section 2.1 Data Model
<scantor> comment - I
would add Simplicity to the title of the bullet on Robustness
Pratik: Discussion on section 2.2 Parameters
... 2.2 Parameters: Instead of separate algorithms for each variant of
canonicalization, this specification goes with the approach of a single
algorithm, which does slightly different things depending on the parameters.
<fjh> pratik notes that
trimwhitespace could list nodes to trim, but now is simply true false
Pratik: Discussion on section 2.2 Parameters: prefixRewrite- how to assign values
to prefix
... 2.2 Parameters: expandEntities- globabally define entities
... 2.2 Parameters: next four parameters- how to deal with special attributes
<Zakim> Thomas, you
wanted to note that xml:id must not be inherited
Thomas: Emulate existing spec as a requirement
<klanz> how do you assure
subtree and list of exclusion elements and attributes ar so disjoint that there
aren't any reinclusions
Discussion on xml:id requirement- drop or not
to drop
<tlr> +1 to the meta
comment
Fredrick: prefer to drop it
Konrad: may not want to re-sign large data
Fredrick: don't want to have to re-calculate/re-sign
<fjh> proposal to drop
xmlIdAncestors parameter
<fjh> Scott notes
prefixRewrite could be dropped
<fjh> or asks why it was
needed
<fjh> Pratik notes
utility for java object conversions
Brian: Have to go through normalization of prefixes, not required
<fjh> Issue: is
normalization of prefixes a goal for 2.0 c14n
<trackbot> Created
ISSUE-136 - Is normalization of prefixes a goal for 2.0 c14n ; please complete
additional details at http://www.w3.org/2008/xmlsec/track/issues/136/edit
.
Brian: Robustness issues- simplicity/interoperability
Fredrick: Profile this down, is that correct?
Pratik: yes
<fjh> Scott proposes
simplification here
<fjh> +1 from tlr
Thomas: Worried if we have a large number of options/features, it may be a
headache later
<fjh> Scott also notes
more to test, try to reduce it all
Thomas: If we can ID parameters that are likely to be used in practice, make
choice on parameters
<fjh> +1 to
simplification
<fjh> klanz notes options
needed for implementations that want certain features
Fredrick: Go through all possibilities on list and try to get things simpler
<fjh> Pratik notes qnames
in content use case for full inclusive
Pratik: Full inclusive canonicalization, way of avoiding the problem, inclusive-
don't have to think about it
<Gerald-e> WS-i Basic
security profile specification uses "Exclusive C14N without comments for
canonicalization"
Fredrick: Go on now
<fjh> Scott notes
xsiTypeAware can be orthogonal to prefix rewriting
<fjh> Discussion on
section 2.3.5
Pratik: 2.3.5 Other ideas considered
... 2.3.5- Have another parameter listing other element / attribute names that
can have qnames, besides xsi:type. Or simply search all text content for qname.
... 2.3.5- Significant white space: Have a parameters listing elements in which
whitespace is significant. Instead of listing individual element names, and
entire target namespace URI can be specified, e.g. in many elements in xhtml
namespace whitespace is significant
<klanz> I say: .... is
say a prefix ?
Fredrick: Scanning for :
Pratik: This is difficult, may be prefix or data/text
<fjh> Hal notes could be
URI
Konrad: There is a paper regarding this issue, can be solved, but not easily
Cynthia: Can we get a link/reference to this paper?
Thomas: A major rework of XML is complex and would take a long time.
<klanz> http://www.w3.org/2001/tag/doc/qnameids
Pratik: Finished with parameters, make a list of supported parameters
<klanz> sure, but if one
does not complain there is never a change
<tlr> s/a long time/a
very, very, very long time/
Fredrick: Do we need backward compatability to v1.0? Is it acceptable to break this?
Brian: Goal is functional parity not backward compatability?
Fredrick: Will it be handled the same way- handle different cases differently
Pratik: Not difficult to support v1.0, may just ignore it (additional items)
... 2.3 Processing Model for DOM- string parser
<fjh> Pratik considering
adding section for streaming but do not have standard for streaming to base on
Pratik: Discussion on section 2.3 Processing Model- The basic canonicalization process
consist of traversing the tree and outputting octets for each node. The
algorithm here is presented in pseudo code using a recursive function to
traverse the tree.
<fjh> q_
<klanz> how do you assure
subtree and list of exclusion elements and attributes ar so disjoint that there
aren’t any reinclusions ?
Pratik: Go through the processing models at a high level
... Section 3.1, 3.2
... Section 2.3.3- Added information, DOM concept
... Section 2.3.3 Namespace context- Hash table
... 2.3.4 Output rules
Fredrick: 2 questions- streaming use case, difficult to add to document as there is
no standard to base it on
Pratik: Not sure how to put it in
Fredrick: Is this a problem or straightforward, it is an important use case
<klanz> what about
SAX/Stax events agnostic of push pull
Pratik: Not a problem
Fredrick: Original spec was written in a straightforward model (procedures), are
people ok with pseudo-code?
Scott: In favor of it but people will complain if it doesn't work
<scantor> that was
scantor, not Brian, sorry
Frederick: Need to be clear on behavior
Fredrick: Using the xpath model, makes it somewhat more confusing
Thomas: Worried that if we only have pseudo-code, mixing implementation behavior
with specification
Scott: Not against the idea, but may have issues, hard to find the text around
the pseudo-code
Pratik: Most of the code will have reference; the information will remain the same
Fredrick: When we have an example of an algorithm, you want wording (warning) to
show intent not exact implementation
... next step- signature example
Brian: Is this a standalone document? May be an issue
<klanz> If you read the
bottom of http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0041.html
you can see that declarative can be horrible as well
Konrad: In favor of pseudo-code approach, in the past there were few examples
there the text was contraticting itself
<fjh> i think pseudocode
can be very useful for being clear as long as not taken as implementation
<fjh> klanz +1 to
pseudocode
<fjh> klanz need to
decide what is normative
Cynthia: We need to add the warning text up front
<tlr> +1 to that
structuring
Fredrick: Get down what we want now, look at the choices, then determine what we
want
<fjh> let us take this
work forward with what we have, look at pieces, then review normative language
approach
Proposed New E07 for ISSUE110, "visibly
utilizes"
Fredrick: When can this be worked?
Pratik: Next week
<klanz> how do you assure
subtree and list of exclusion elements and attributes are so disjoint that
there aren't any reinclusions ?
Konrad: One comment on proposal, nodes of sub-trees, exclusion of attributes- sub-tree
handling
Pratik: Have a solution (2.3.3.)
<fjh> request to Pratik
to clarify constraints and behavior on inappropriate subtree inclusion
Exclusive Canonicalization Errata
<fjh> E02
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html
<fjh> E07
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0076.html
Scott: Someone needs to look at the language
<fjh> ACTION:
Konrad to review E07 and E02 for Exclusive C14n [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action07]
<trackbot> Created
ACTION-331 - Review E07 and E02 for Exclusive C14n [on Konrad Lanz - due
2009-07-14].
<scribe> ACTION:
Konrad review wording http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html
[recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action08]
<trackbot> Created
ACTION-332 - Review wording http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html
[on Konrad Lanz - due 2009-07-14].
<fjh> issue-7?
<trackbot> ISSUE-7 -- Can
exi be used by xmlsec wg as part of solution -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/7
Issue discussions
<fjh> issue-9?
<trackbot> ISSUE-9 --
Review WS-I BSP constraints on DSig -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/9
<fjh> issue-7 closed
<trackbot> ISSUE-7 Can
exi be used by xmlsec wg as part of solution closed
<fjh> addressed in C14n
2.0 draft parameter
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0002.html
<fjh> Scott notes work
around for backward compatibility by providing library to map old APIs to new
APIs
Actions
<fjh> http://www.w3.org/2008/xmlsec/track/actions/open
Fredrick: Thomas: XML Security library?... Believe we covered almost everything
Issues
<fjh> http://www.w3.org/2008/xmlsec/track/issues/open
Fredrick: Did we forget anything?
<fjh> issue-134?
<trackbot> ISSUE-134 --
Camellia algorithm for section of 5.2 Block Encryption Algorithm and 5.6
Symmetric Key Wrap -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/134
Cynthia: Correct, it should be closed
<fjh> issue-134 closed
<trackbot> ISSUE-134
Camellia algorithm for section of 5.2 Block Encryption Algorithm and 5.6
Symmetric Key Wrap closed
<fjh> added to algorithms
document
Fredrick: Time to stop call
[NEW] ACTION:
bal to update DSS security warning [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action03]
[NEW] ACTION: Brian to
update ACTION 319 for explicit URI [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action01]
[NEW] ACTION: fjh review and
update explain documents for xml signature and encryption [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action05]
[NEW] ACTION: fjh to update
xml signature references [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action04]
[NEW] ACTION: Konrad review
wording http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html
[recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action08]
[NEW] ACTION: konrad to
review E07 and E02 for Exclusive C14n [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action07]
[NEW] ACTION: tlr to update
algorithms doc per http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html
[recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action06]
[NEW] ACTION: Update Action
283 [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action02]
[End of minutes]