06:36:37 RRSAgent has joined #xmlsec 06:36:37 logging to http://www.w3.org/2008/10/21-xmlsec-irc 06:36:39 RRSAgent, make logs member 06:36:39 Zakim has joined #xmlsec 06:36:41 Zakim, this will be XMLSEC 06:36:41 ok, trackbot; I see T&S_XMLSEC()2:30AM scheduled to start 6 minutes ago 06:36:42 Meeting: XML Security Working Group Teleconference 06:36:42 Date: 21 October 2008 06:37:03 Chair: Frederick Hirsch 06:37:20 Regrets: John Wray, Juan Carlos Cruellas 06:37:43 pdatta has joined #xmlsec 06:37:55 Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0039.html 06:38:08 zakim, call executive_6 06:38:08 ok, fhirsch3; the call is being made 06:38:09 T&S_XMLSEC()2:30AM has now started 06:38:11 +Executive_6 06:38:11 csolc has joined #xmlsec 06:38:21 zakim, who is here? 06:38:21 On the phone I see Executive_6 06:38:23 On IRC I see csolc, pdatta, Zakim, RRSAgent, fhirsch3, klanz2, trackbot 06:38:31 pdatta has joined #xmlsec 06:38:44 brich has joined #xmlsec 06:39:25 ScribeNick: brich 06:44:24 pdatta has joined #xmlsec 06:45:09 +??P1 06:45:11 zakim, ? is klanz2 06:45:11 +klanz2; got it 06:50:00 youenn has joined #xmlsec 06:50:07 youenn has left #xmlsec 06:51:56 TOPIC: Agenda discussion 06:52:39 Possibly go through Pratik's proposal for XPath subsetting 06:53:36 bal has joined #xmlsec 06:55:16 Proposal was from Sept 1 06:56:43 http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html 06:57:16 exi - serialize documents or fragments, multiroot docs 07:01:08 pdatta has joined #xmlsec 07:03:53 q+ 07:08:07 Schema validation, namespace undeclaration, etc 07:09:18 rdmiller has joined #xmlsec 07:10:51 Also need to discuss c14n...whitespace handling, intermediate indention, b64-encoded certs, detection and removal of "insignificant information" 07:16:03 Might help to consolidate what we consider to be insignificant information, those things that applications should NOT depend on being retained 07:20:43 c14n being a terminal transform, rather than having to go back and forth between nodesets and octet streams, seems like a crucial simplification 07:22:23 konrad...is there a heuristic for determining qnames in context vs other uses? 07:23:12 can we ask users that what looks like a QName, but isn't one it will ahev to be escaped 07:23:26 s/ahev/have/ 07:24:10 q+ 07:30:59 tlr has joined #xmlsec 07:32:50 Discussion around c14n output being able to be used as a standard form to be passed around...eliminating this allows more things to be considered "insignificant information" and can be left out 07:33:13 What is the complement of the InfoSet, what can be thrown away ... 07:34:11 TOPIC: XProc and XML discussion with Norm Walsh 07:36:42 Subtopic: C14N requirements 07:37:48 What pieces are not to be considered significant, that applications cannot depend on being retained? 07:38:23 Norm...what's significant is what in its infoset 07:38:46 Norm...element content whitespace is insignificant 07:39:22 Norm...almost everything else is significant 07:40:24 Norm...schema does not really address this well, only in DTD 07:41:05 Norm...w/o schema or DTD, all whitespace should be assumed to be significant 07:41:08 q+ 07:42:40 rigo has joined #xmlsec 07:43:18 pdatta has joined #xmlsec 07:43:28 norm...cdata sections do not turn up in the infoset 07:44:01 fhirsch has joined #xmlsec 07:44:52 That is what I tired in Transformation Primitives 07:44:57 zakim, who is here? 07:44:57 On the phone I see Executive_6, klanz2 07:44:59 On IRC I see fhirsch, pdatta, rigo, tlr, rdmiller, bal, brich, csolc, Zakim, RRSAgent, klanz2, trackbot 07:45:29 q+ 07:49:07 we have more protection with digital signature than paper signature today, as we have content protection...seems like whitespace preservation is beyond what is required 07:49:36 q+ 07:50:22 q+ 07:50:29 ack klanz 07:51:01 konrad...if want whitespace preservation, could allow option 07:51:02 ack tlr 07:51:20 if we wish to simplify then we need to simplify 07:51:41 csolc...how does application know whether whitespace is significant, to be able to request it or not? 07:51:43 both tlr and csolc asked how does app know whether space is signficant to set option 07:52:20 prefer to avoid options and complexit 07:53:41 Norm has joined #xmlsec 07:53:58 http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html: 07:53:58 if one would apply those to the referenced document itself (by 07:53:58 actually changing it) then the processing of the transforms, despite 07:53:58 some serialization, could be omitted on verification as those transforms 07:53:58 are idempotent. 07:53:59 In case it fails, the transformations may be executed again assuming an 07:54:01 allowed change has happened. If it fails again it fails overall. 07:54:03 We should hence further revise the paradigm of not changing the 07:54:05 dereferenced/parsed document. 07:54:06 norm...

donot

07:54:20 q+ 07:54:36 Critically, in the original document, there's a newline between the two spans 07:55:04 q+ to ask about pipelines 07:55:18 frederick...need to drive to simplification 07:55:53 kyiu has joined #xmlsec 07:57:59 bal...whitespace insignificance is only possible via DTD, and that is legacy...no longer to be used 07:59:21 q+ 07:59:35 q- 08:00:06 ack fhirsch 08:00:18 ack klanz 08:01:19 bal..."sign what is seen" is at end of dsig doc, was not primary focus, should not overemphasize 08:02:11 But it should be chewed away befor the document is signed ,,, 08:02:21 s/befor/before/ 08:03:12 So there is obviously enough potential if Information in XML is secure .... 08:04:33 Subtopic: Pratik's presentation 08:04:47 s/potential/potential to discuss/ 08:05:01 http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html 08:07:36 @bal: Point 1) in Pratik's presentation is to some extend equivalent to sections 8.1.1 to 8.1.3 08:08:07 q+ 08:08:50 pdatta...Building dsig on XPath 1.0 data model leads to lots of work to deal with namespace inheritance when nodes are omitted 08:08:51 fhirsch3 has joined #xmlsec 08:10:02 norm...xpath2 may help, not required to support namespace nodes and a namespace axis 08:10:27 http://www.w3.org/TR/xpath20/: 08:10:27 In [XPath 1.0], the in-scope namespaces of an element node are represented by a collection of namespace nodes arranged on a namespace axis. In XPath Version 2.0, the namespace axis is deprecated and need not be supported by a host language. A host language that does not support the namespace axis need not represent namespace bindings in the form of nodes. 08:10:48 pdatta...subtrees most important to support, and perhaps included/excluded subtrees 08:11:40 pdatta...Enveloped signatures require the exclusion of the signature subtree itself 08:12:17 norm...will help find "Schema Key Constraints" 08:13:41 tlr...put this in "Proposed Breaking Changes" in requirements doc 08:14:20 pdatta...going to Streaming signatures... 08:15:44 norm...streaming XSLT...need email reminder 08:16:33 q+ 08:16:43 Summary: namespace prefix undeclarations will continue to haunt us forever. 08:16:52 ack klanz 08:17:17 norm...namespace prefix undeclaration is NOT in xml 1.0 but is in 1.1...this will NOT change 08:17:51 Konrad observes that the XPath 2.0 data model can't be serialized as XML 1.0. 08:18:36 tlr...would like to change gears...XSLT serialization...what is the domain? what nodesets does it operate on? 08:18:38 s/XPath 2.0/XPath 1.0/ 08:19:31 norm...will serialize any XDM subtree...doesn't throw anything away(?), may add things (indentation) 08:19:46 tlr...why not c14n? 08:19:57 norm...not on radar 08:21:44 xproc may use c14n as serialization for serialization method 08:22:15 norm...XProc pipeline would output nodeset...would not make sense to have c14n...as that would output octet stream 08:25:18 All this XML == XML' ? Is allover the place in XML and causes so many headaches ... http://www.w3.org/TR/xslt#strip 08:25:19 q+ 08:25:34 and many more places and so on ... 08:25:52 frederick...these two requirements are linked...looks like must do both 08:25:58 removing the requirement to allow transforms to move from octet stream to nodeset and back as well as enabling c14n only has pre-hash signing step could greatly improve performance, simplification 08:26:13 can not do both! 08:27:02 q+ 08:27:11 ack klanz 08:28:49 Konrad is unfortunately right about XSLT 08:28:51 http://www.w3.org/TR/xmldsig-core/#sec-XSLT 08:30:01 ISSUE: Revise XSLT transform; it's currently octet-stream to node-set. 08:30:02 Created ISSUE-67 - Revise XSLT transform; it's currently octet-stream to node-set. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/67/edit . 08:30:31 frederick...not arguing against "sign-what-you-see" but did we make this more complicated than what was needed? 08:31:07 bal...whole reason for xform chains was for document subsets 08:31:16 Document subsets is XPointer 08:31:55 q+ 08:32:06 frederick...do we really need the transform chain mechanism? 08:32:21 Imagine Database A and Database B .... 08:32:36 bal...do you need to have subselection of URI-addressable parts? 08:32:50 and you send a detached signature from A to B ... 08:33:32 and the transforms dereference data from those data bases and the signature shall verify without actually transferring the data# 08:34:08 so would could make this a NON use case 08:34:49 but currently these things are used ... 08:36:00 tlr...XSLT transform requirement will constrain us...unless dealt with somehow 08:37:06 Subtopic: XProc futures 08:37:30 norm...going to CR the end of this week 08:37:51 norm...may get uptake early next year 08:38:40 norm...if case that dsig is atomic operation with few options, could argue that is part of XProc 08:39:23 norm...seems more complicated, would be compound steps, more than can be added to XProc 08:40:23 q+ 08:40:38 rdmiller...some work has already gone into this dsig+Xproc step/steps, will share later 08:41:18 is an XProc chain delivering the same output if executed on different processers ... 08:41:52 I mean if you stuck it into a digest will it deliver the same digest 08:42:46 q+ 08:43:36 ack fhirsch 08:43:42 ack klanz 08:43:45 maybe that is an interesting idea and then all other specs would have to assure that their output is canonical to some extend .. 08:46:46 konrad...if security is of concern to authors of XML apps, should have canonical form 08:47:13 tlr...most specs tell how to parse, not how to serialize, canonicalize 08:48:57 Security is inconvenient and costly, but is necessary to assure long term survival of any technology ... 08:49:48 frederick...what is going on with encryption? 08:50:05 norm...deferred until later, just as signature 08:51:35 q+ 08:55:31 q- 08:55:44 amy has joined #xmlsec 08:55:58 frederick? 08:56:06 let's meet in the Webapps room 08:56:10 they have more room 09:01:45 ArtB has joined #xmlsec 09:02:03 amy has left #xmlsec 09:02:11 Frederick - Thomas says you folks should join us @ 11:00 in Isle A 09:02:12 OK? 09:02:35 Isle A is behind the registration desk on floor 0 09:02:45 Please ACK 09:05:27 -Executive_6 09:11:22 brich has joined #xmlsec 09:11:41 bal has joined #xmlsec 09:12:32 csolc has joined #xmlsec 09:12:44 zakim, call iles_a 09:12:44 ok, brich; the call is being made 09:12:46 -klanz2 09:12:46 +klanz2 09:12:46 +Iles_a 09:13:23 fhirsch3 has joined #xmlsec 09:13:49 zakim, who is here? 09:13:49 On the phone I see klanz2, Iles_a 09:13:50 On IRC I see fhirsch3, csolc, bal, brich, ArtB, kyiu, rdmiller, Zakim, RRSAgent, klanz2, trackbot 09:14:41 ScribeNick: brich 09:15:00 TOPIC: WebApps meeting 09:17:42 tlr has joined #xmlsec 09:18:36 http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0077.html 09:19:12 WebApps: SHA-256 issues? 09:20:06 bal: deprecate sha-1 for signing, continue verification, support SHA-256 09:22:43 WebApps: how to deal with knowing which alg to use? 09:23:16 WebApps: Signature alg? 09:26:00 see wam minutes here 09:27:05 bal: 1024 key length good for a year... 09:32:03 if cert is long lived for code signing, e.g 3 year verisign cert, could drive desire to use long lived signing key at 1024... 09:32:14 s/if/kelvin, if 09:33:49 wam minutes - http://www.w3.org/2008/10/21-wam-minutes.html 09:37:44 q+ 09:39:18 q- 09:40:59 bal...said XAdES would have helpful info, some might be picked up in Signature futures 09:41:17 he asked about timestamps and I pointed to xades 09:41:31 link to XAdES already in WAM channel 09:42:15 re timestamps also poit to best practices for ephemeral signatures and timestamps, i.e. the contributon from Hal about webservices and timestamps 09:44:52 We expect to do the algorithm changes, minor clean-ups, low-hanging simplifications in XML Signature 1.1. No change of namespace. No clear time plan quite yet. 09:59:33 tlr: identify spec in signature as signature property, so to identify profile 10:26:41 zakim, who is here? 10:26:41 On the phone I see klanz2, Iles_a 10:26:42 On IRC I see tlr, bal, brich, ArtB, Zakim, RRSAgent, klanz2, trackbot 10:27:21 fhirsch3 has joined #xmlsec 10:27:28 zakim, who is here? 10:27:28 On the phone I see klanz2, Iles_a 10:27:29 On IRC I see fhirsch3, tlr, bal, brich, ArtB, Zakim, RRSAgent, klanz2, trackbot 10:32:48 yes 10:33:05 I can howevr hardly hear anything 10:36:05 q+ 10:36:09 q- 10:37:41 do we have a requirement to clarify dereferencing from within a ZIP file, it seems ODF and Widgets need this? 10:38:22 -klanz2 10:38:23 -Iles_a 10:38:25 T&S_XMLSEC()2:30AM has ended 10:38:26 Attendees were Executive_6, klanz2, Iles_a 10:40:12 things that may play a role here are: http://tools.ietf.org/html/rfc3986#section-5.1.2 10:40:12 Java has soemthing in the format jar:!/[] 10:40:14 http://java.sun.com/j2se/1.5.0/docs/api/java/net/JarURLConnection.html 11:01:46 T&S_XMLSEC()2:30AM has now started 11:01:53 +Ed_Simon 11:24:14 -Ed_Simon 11:24:16 T&S_XMLSEC()2:30AM has ended 11:24:16 Attendees were Ed_Simon 11:24:33 T&S_XMLSEC()2:30AM has now started 11:24:40 +Ed_Simon 11:27:20 esimon2 has joined #xmlsec 11:27:55 Hi Konrad, where is everyone? 11:35:24 -Ed_Simon 11:35:26 T&S_XMLSEC()2:30AM has ended 11:35:26 Attendees were Ed_Simon 11:51:50 fhirsch3 has joined #xmlsec 11:52:13 pdatta has joined #xmlsec 11:52:21 zakim, call executive_6 11:52:21 ok, fhirsch3; the call is being made 11:52:22 T&S_XMLSEC()2:30AM has now started 11:52:23 +Executive_6 11:52:36 kyiu has joined #xmlsec 11:52:49 zakim, who is here? 11:52:49 On the phone I see Executive_6 11:52:51 On IRC I see kyiu, pdatta, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot 11:53:15 ScribeNick: kyiu 11:54:03 zakim, who is here? 11:54:03 On the phone I see Executive_6 11:54:04 On IRC I see kyiu, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot 11:54:05 zakim, who is here? 11:54:05 On the phone I see Executive_6 11:54:08 On IRC I see kyiu, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot 11:55:27 csolc has joined #xmlsec 11:55:46 pdatta has joined #xmlsec 11:56:54 TOPIC: NVDL Introduction 11:57:05 pdatta has joined #xmlsec 11:57:45 +??P4 11:57:47 -??P4 11:57:47 +??P4 11:57:51 pdatta has joined #xmlsec 11:57:56 zakim, ? is klanz2 11:57:56 +klanz2; got it 11:58:27 do we have a link to NVDL 12:01:01 bal has joined #xmlsec 12:01:08 RobMiller: how to move XML in an assured way - has paper that shows how to constrain schema 12:01:10 what slide are we on 12:01:35 I think 2 12:01:41 What is NVDL 12:02:48 NVDL=Namespaces-based Validation Dispatching Language 12:03:13 I know, but is that the heading of the slide you have been seeing 12:03:20 yes 12:06:02 zakim, who is there? 12:06:02 I don't understand your question, kyiu. 12:06:11 zakim, who is here? 12:06:11 On the phone I see Executive_6, klanz2 12:06:12 On IRC I see bal, pdatta, csolc, kyiu, esimon2, Zakim, RRSAgent, klanz2, trackbot 12:09:02 q+, what PSVI is added when multiple schmas is validated against? 12:09:52 fhirsch3: how do you identify a component? how do you express constraints? 12:10:45 ack klanz2 12:11:43 brich has joined #xmlsec 12:16:26 fhirsch3: can possibly put NVDL on our best practices list 12:21:55 q+ 12:22:38 ack klanz2 12:23:50 fhirsch3 has joined #xmlsec 12:24:24 Very Good Point 12:25:23 rob: NVDL can be used to mitigate many things on a schema validation level already 12:26:01 slides for NVDL http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.ppt 12:26:14 there is a potential to tackle certain things in our best practices using NVDL ... 12:26:58 NVDL pdf http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.pdf 12:30:20 e.g.: Limit http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#id114072 -> give an NVDL example of how to prevent this ... 12:30:24 TOPIC: Transform Requirements 12:30:25 q+ 12:30:43 ack klanz2 12:30:47 ack klanz 12:31:12 http://tools.ietf.org/html/rfc3986#section-5.1.2 12:31:34 TOPIC: WebApps followup 12:31:46 pwd 12:32:09 tlr has joined #xmlsec 12:32:36 s/5/konrad, 5 12:33:12 s/pwd// 12:34:45 klanz2: add test cases for zip based packaging formats? 12:35:53 tlr: xmldsig already allows relative paths in uris. not xmldsig's responsibility 12:35:57 group noted that other groups may have to test Reference uri retrieval, really out of scope for signature 12:36:41 TOPIC: Transform Requirements 12:36:42 rdmiller has joined #xmlsec 12:37:05 http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/att-0036/00-part 12:38:43 pdatta: very difficult to find out what is signed. Model is run transform, get digest 12:39:28 pdatta: seems verifying processor doesn't know what is going on. in practice, we restricts what transform sequences are allowed 12:39:41 pdatta: should step back and try to do things in a different way 12:40:13 pdatta: how to identify what is signed - not responsibility of a transformation 12:41:23 csolc: may want to canonicalize binary formats 12:41:56 separate what is signed, selection, and digesting/canonicalization 12:42:08 csolc: 2 steps: selection and canonicalization 12:43:31 pdatta: klanz2 brought up using xslt to remove whitespaces, but it should be done within canonicalization 12:44:17 kyiu has joined #xmlsec 12:44:52 q+ 12:47:26 klanz2: new use case for transforms: generate xhtml on the fly and signed 12:54:42 fhirsch3: seems like you can simplify signature greatly if data is first retrieved from database, run through xslt, then signed, instead of running the xslt as part of xmldsig 12:58:21 bal: you would have to generate a uri for the results from the database query 12:59:10 q+ 12:59:21 ack klanz 13:01:01 8.1 Transforms 13:01:01 A requirement of this specification is to permit signatures to "apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].) The Transforms mechanism meets this requirement by permitting one to sign data derived from processing the content of the identified resource. For instance, applications that wish to sign a form, but permit users to enter limited field data withou 13:01:01 t invalidating a previous signature on the form might use [XPath] to exclude those portions the user needs to change. Transforms may be arbitrarily specified and may include encoding transforms, canonicalization instructions or even XSLT transformations. Three cautions are raised with respect to this feature in the following sections. 13:01:03 Note, core validation behavior does not confirm that the signed data was obtained by applying each step of the indicated transforms. (Though it does check that the digest of the resulting content matches that specified in the signature.) For example, some applications may be satisfied with verifying an XML signature over a cached copy of already transformed data. Other applications might require 13:01:08 csolc: seems transforms for document manipulation should not be part of dsig 13:01:08 that content be freshly dereferenced and transformed. 13:01:22 *to sign data derived from processing the content of the identified resource* 13:03:17 bal: thinks we had requirement from we wanted to sign parts of a document. xpath was a means of selection, xslt is selecting and transforming 13:03:37 q+ 13:03:58 fhirsch3: what would we lose if we keep only selection, but not transform? 13:05:47 tlr: 2 possible assertions: if we take msg, apply transform, then you are assured the information is result. you don't get the assurance if you don't apply it. 13:07:01 fhirsch3: push back on putting all information about a workflow into xmldsig 13:08:00 q+ 13:09:22 q- 13:10:36 q+ 13:10:38 bal: looking back on v1 requirements, we may have just over defined transforms when reqs were mostly inclusions and exclusions 13:14:14 XPointer is still a WD ... 13:20:07 tlr was arguing to keep selection 13:21:48 q+ 13:21:50 (discussion of what auditors do when they audit) 13:22:32 where info is stored (inside or outside of the signature) should not affect the auditor 13:23:35 What about this: http://www.w3.org/TR/xmldsig-core/#sec-Base-64 13:23:54 That is a clear indication that what is to be secured is the derived and not the data as such 13:24:46 but the empty transform chain degenerates to the situation where there is identity between what is dereferenced data and digested data 13:24:52 + +1.781.993.aaaa 13:25:11 zakim, aaaa is hlockhart 13:25:11 +hlockhart; got it 13:25:53 fhirsch3: it may be difficult for an app to define a transform if the API doesn't support it or complex 13:26:50 similar thoughts could be applied if only transfrom primitives were used ... 13:27:41 fhirsch3: xproc is about defining processing chain and would like to see a simple processing step for signing 13:28:00 q+ 13:28:28 fhirsch3: trying to get things simpler, not sure if we can meet our security and perf objectives without simplification 13:29:01 bal: then you can make canonicalization the last transform before digest 13:29:21 q+ 13:29:33 ack klanz 13:30:33 +Ed_Simon 13:30:57 klanz2: doesn't think supporting transformation is contrary to our goals 13:31:59 fhirsch3: we don't eliminate the transform step, but questioning whether it belongs within xmldsig. 13:32:59 q+ 13:34:26 klanz2: removing transformation may not be supported by the community 13:35:24 fhirsch3: convinced that we should be on a path to do a version 1.1. Would be nice to get feedback beforing going to last call 13:35:56 fhirsch3: pretend we have a small part of 2.0 ready way ahead and ask for feedback 13:37:06 tlr: would be very valuable if we reach out to etsi, ietf and oasis. proposal would have to be public and not member only 13:37:28 tlr: brief design not may be the right way to get feedback 13:37:37 s/design not /design note/ 13:37:49 zakim, mute me 13:37:50 sorry, esimon2, I do not know which phone connection belongs to you 13:39:08 For 1.1 we could start with things like http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html Transfromation primitives ... 13:39:17 pdatta: could present in 2 ways: new syntax or retain old syntax but restrict 13:41:02 Some quickly drafted examples for such transformation primitives could be: 13:41:02 a) some sort of minimal canonicalization as defined in RFC 4051 [2] ... 13:41:02 b) normalization of namespace prefixes, ... 13:41:02 c) normalization of multiple successive whitespace characters ... 13:41:02 d)sorting of attributes ... 13:41:03 e) a non-XPath-Filter based version of the enveloped signature 13:41:05 transform ... 13:41:07 f) and the like .... 13:48:44 -klanz2 14:01:10 -Executive_6 14:01:55 zakim, call Executive_6 14:01:55 ok, csolc; the call is being made 14:01:56 +Executive_6 14:03:03 bal has joined #xmlsec 14:04:10