This is work in progress. It has only been looked at by Sam, Paul, PLH, and Robin. This document has no official status and was simply produced in response to a request from the AB. Some elements of this plan have been rejected previously and could undergo substantial changes before coming into effect.
Between the enactment of “Plan 2014” and the release of HTML 5.0 as a Recommendation, the HTML WG was for the most part fully dedicated to shipping, knowingly accepting the cost of such a strongly directed effort. Shipping HTML 5.0 was considered to be enough of an overwhelming objective that the group’s operation over that period can be considered mutatis mutandis as a wartime economy in which a singleminded objective primes over flourishing and innovation.
With this drive gone, the time has come to reorganise the HTML WG’s operation in the manner most conducive to improving the Web. The core ideas behind this reorganisation were published in the “After5” plan, much of which has already been deployed.
Resources available for the production of standards are scarce. Able editors with time to dedicate to new work are few and far apart, quality reviewers only have so much bandwidth, and test developers are always ridiculously hard to find. In order for us to contribute to the furthering of the Web, it therefore behooves us:
- To encourage greater participation — at the very least by not deterring it — and to ease the way for new participants to become contributors at all levels. Successful open projects have in common a relatively smooth path from minor fixes to expert contributions; something at which the Web standards community has been particularly inept.
- To deploy our limited resources in the most productive manner.
It should be noted that the ruthless efficiency applied to a single-minded time-driven release schedule entails an organisation of labour very different from the ruthless efficiency seeking the blossoming of innovation. The change is from a regimen of decrees and officialdom to one of experimentation and reciprocal obligations.
It is this philosophy and these constraints which together helm the whole of this plan. In fact, in more ways than one this is a plan against planification. It is grounded in the belief that the primary and perhaps sole function of “leadership” in the HTML project is to trust in the community’s intelligence and competence by providing support, infrastructure, and assistance for its work. Such a community can only be directed, planned, or scheduled with circumspection and Montesquieu’s trembling hand.
Before diving into further details, it should be noted that such an approach has direct implications that are worth highlighting.
Perhaps most notably, considering that duplication of work is a net loss to progressing the Web as are manual integration costs (e.g. from cherry-picking individual changes), this plan explicitly makes the WHATWG bugzilla instance at W3C the first location at which to report bugs about the HTML specification. While this may strike some as a radical change it is in truth nothing but the ratification of an existing reality. The primary benefit over denialism on this topic is the freeing of resources that it enables. The ability to escalate issues to the HTML WG is however provided for.
It must be noted however that this acquiescence to reality comes not without its pitfalls. Several attempts at finding a modus vivendi with the WHATWG have run aground on issues of IPR and escalation of decisions.
IPR problems are well-known and apply across the board to the documents produced by the WHATWG. There is little that can be done but keep the door open for a potential future agreement on IPR-friendly stable snapshots.
The question of escalation is more subtle. While the overwhelming majority of bugs processed in the development of the WHATWG HTML Living Standard are resolved in ways that meet the W3C definition of consensus, WHATWG HTML does however suffer from “too big to fail” externalities that decrease the editor’s responsibility for his actions and thereby negatively affect the specification’s evolution.
These issues must be accounted for in our plan. We must operate such that these additional desirable properties are externally bolted onto the WHATWG where needed, while keeping the cost of this forcible integration low and leaving the door open to future friendlier cooperation.
Some may be tempted to castigate this approach as “pro-WHATWG” (whatever that means) or that it carries an existential threat to W3C. Neither of these straw-people strikes us as carrying value. To the first one we shall simply point out that there are no sides but the Web. To the second we can only note that if the W3C’s advantage sits solely in its IPR and consensus policies but the WHATWG is superior in all other important aspects then the only existential threat to W3C would be W3C itself. It is the W3C’s sole responsibility to excel at standardisation, independently from what other organisations do.
To excel is not out of reach, or perhaps even so far as it may sometimes appear. Altogether too often W3C working groups have constrained their thinking about how to operate to a set of behaviours perceived to represent the requirements placed upon them by the W3C Process. Much of the time, these constraints are imaginary. While there is no denying that the production of royalty-free technology and a strong preference for broad consensus do place some demands on a group’s operation, there are many ways in which a group can carry out its day-to-day work without such requirements getting in the way.
Note that while this document specifically targets the HTML WG, it can also read as a broad set of suggestions for reform in the manner in which groups in general operate, most specifically large groups with broad remits.
Organisation & Work Mode
Over the past two years, the core HTML WG has been productive almost exclusively at shipping HTML5. The parts of the group that have produced novel, useful extension specifications are some of its task forces such as for example the Media TF or the Editing TF.
Certainly the adamantine focus on shipping that dominated the core group is part of this, but not alone. There are several issues with working as part of a broad group:
- Would-be participants report it as daunting;
- The platform is broad while interests are often more specific;
- It encourages drive-by comments;
- It discourages participation from those who do not wish to handle a fire-hose;
- What dysfunctional behaviour may exist in the group tends to be suffered by all while the parts that operate well mostly benefit (directly) those who care about them;
- Coupled with a large document that carries a deep gravitational well it discourages contributions.
A single group is not without its advantages (notably built-in coordination) but in practice they are outweighed by the downsides. It is notable that groups that operate as one large entity have resorted to filtering mechanisms, and in effect many participants are known to tune out the parts they do not directly care about.
As a result, we recommend the following organisation for the group: focused topic areas, some of which are currently handled as separate Task Forces, are to be handled in their own Community Groups (replacing the existing Task Forces). The list of CGs need not be fixed, on the contrary it is expected to evolve over time. Examples of possible CGs are given below.
Naturally, this does not instate a mandate to produce any kind of work. Participation commitments in W3C working groups are made under the agreement that the group’s intellectual property scope be sufficiently clearly bounded. One does not simply add a deliverable to a working group if it is not in scope. We can however expect the upcoming HTML WG’s charter to define its IP boundaries in a manner similar to the current one. While not open-ended, these boundaries are broad enough to accommodate new work that cannot necessarily be fully predicted two years in advance. This flexibility is to our advantage since it affords us the ability to reach intelligent judgement calls through concrete discussions (on public-html-admin) as to whether a proposed new work item fits within the established boundaries rather than constraining us to operate within the limitation of prescriptive foresight that, with two years to look ahead to, none of us has.
CGs can organise as they wish to subject to the W3C Community Group process. They can involve broad participation. Their process can be radically lightweight, while still operating within the boundaries of the W3C Community Group IPR policy.
CGs can notably publish forkable specifications (see notes below on licensing) so as to encourage participation by avoiding contribution-hostile constraints [NOTE: the ability for CGs to use such licenses needs to be validated by W3C legal]. They need not rely on communication methods that are often disliked by today’s Web developers and can easily make use of more modern alternatives (more on this in the tooling section).
Under this regime the core HTML WG would have as one of its functions to serve as a coordination forum between CGs, helping to sort out problems that may need cooperation amongst them or with the core HTML specification (publication details for which are outlined below). It can also serve as a catch-all group for work that does not yet have a home of its own. At heart, this coordination is meant to enable the involvement of a broader community when it is needed. This may happen when a CG does not feel comfortable that it has the necessary knowledge or context to make progress on a topic, or when dissent amongst groups or inside of one would be helped by a discussion of the whole village. To extend the metaphor, it should be noted that if one is to call upon a gathering of the whole village for every minor issue and squabble, the villagers might not consider one favourably for long.
Such coordination is meant to be called upon solely as needed, and not enforced through a constant flow of artificial and seldom read activity reports as has been the case in the past in what used to be known as “Coordination Groups”.
Technical disputes are encouraged to be addressed through forking and merging (since CGs can avail themselves of forkable licenses), the goal being for dissent to operate on camera-ready documents. Only once a pull request has been thoroughly discussed with still no resolution in sight should a broader assembly be convened. Once it has, the usual machinery of group decisions apply. Disputes that are not grounded in a concrete proposal, implemented through a pull request or similar mechanism, expose themselves to summary dismissal. Perhaps counterintuitively given the naming, the primary goal of a forkable license is a merging process.
Over the past two years, the HTML WG has worked in tandem with CGs, notably the Responsive Images Community Group. One of the primary complaints has been the overhead imposed on such groups to report on their status and produce heartbeats. To address that, CGs that produce Final Specifications can bring them to the HTML WG as a way to get them to Recommendation relatively efficiently, provided they have undergone credible levels of review, notably horizontal review (I18N, A11Y, etc.) which naturally includes a reasonable amount of testing. As experience is gathered with this division of labour, the HTML WG could set up procedures allowing for the automatic publication of CG Final Specifications as Candidate Recommendations (which can be a First Public Working Draft at the same time).
When a Final Specification is accepted for publication by the HTML WG, if its content is intended to replace a given part of the HTML specification, the part in question is then removed.
Community Groups have a broad mandate to organise themselves in whatever creative manner they see fit, provided that:
- They document where one can follow and participate the work;
- They, in practice, adhere to a form of consensus decision-making. Note that this can vary very much from one instantiation to another.
- They keep as good a paper trail as possible of contributions from participants. A good example of such a paper trail would be commit logs or pull-requests.
Spreading the work in several locations does have the downside that it can make finding the proper place in which to participate harder. This will be addressed by making the HTML WG’s home page essentially be a participation map, very clear and above the fold, that points to every group with details about the topics covered there.
Additionally, in order to facilitate the work of people who wish to provide feedback, each group will document how it prefers to receive feedback and what its high-level policies (e.g. commit-then-review or the reverse). The goal here is notably to simplify the lives of horizontal groups that have to deal with many different organisations that can be hard to guess.
CGs will naturally require some guidance in order to produce good specifications. With this in mind it would be helpful to produce a resource pointing to the various existing (but scattered or unfinished) resources about writing good specifications, and to point out specific details about what make good extension specifications.
The expectation is that the HTML WG would operate under the 2014 Process (without which the useful mouthful that is the “First Public Working Draft Candidate Recommendation” is not possible).
The current (more recent) work mode of the HTML group is derived from that of the WebApps WG. Usage of regular telcons should be revisited by the group, while of course ad hoc ones can be scheduled (and CGs are allowed to make use of them is they so desire). If expressly requested by direct stakeholders, a coordination call between CGs may be held, for instance on a monthly basis. Occasional face to face meetings are to be expected, but may not involve the entire group.
Note: in the past some provisions of the Invited Expert agreement have forced individuals to choose between participating in a given W3C activity and a similar activity elsewhere, to the detriment of participation. By the time the charter for this new group is approved, the 2015/01 version of the Invited Expert and Collaborator Agreement is expected to be in effect, which will address this problem.
It is also worth noting that while CGs have been chosen as an organisational vehicle here in order to benefit from their flexibility notably with respect to the licensing and invited expert issues, it could be preferable to solve those issues at the WG level. Should that happen, using TFs instead of CGs should work just as well. Ideally, participants should be shielded from such discussions and from the operational differences they imply.
Open Tooling
Both the HTML WG and its related CGs can make use of whatever tools they see fit for a given specification, but we call out a number of options here as they are expected to take up a central place in these operations.
For drafts under the control of the HTML WG (since this is not an option we can offer CGs
yet) the new “Echidna” automated publishing
system that is to be deployed on labs.w3.org
in early February 2015 is
strongly encouraged. This tool essentially allows a group to use http://w3.org/TR/ for its Editor’s Drafts. Editors can set
their draft up such that any commit triggers a new publication there. This is designed to
avoid specifications in TR space from going stale. As many Working Drafts as are needed
can be published, every day.
Groups that so desire are encouraged to make use of GitHub, not just for repositories but
also for discussion if that is their preference. A tool that makes it possible to backup
not just the git
part but also the issues, comments, etc. is expected to be
made available. This should address concerns over migration should the need arise.
Discourse is already available for broad discussions with the community. Groups are encouraged to request new categories that match their needs better than those already in existence (as was done by the asm.js folks). The current administrators are happy to mint moderators and support the mode of operation required by groups wishing to work there.
Finally, the WebSpecs project is open to every project that wishes to use it as a publishing platform at which to maintain its documents. The project is specifically designed to publish from GitHub repositories with very minimal overhead (once you have a specification ready, integrating the project is pretty much one pull request away) while avoiding the scattered nature and complexity of dozens of GitHub repositories that can be hard to find. It also operates on the core assumption that multiple forked version of the same specification can be maintained at the same time in order to facilitate discussion (and, eventually, merges).
Core HTML Draft Publication
While the CGs may publish as they please, the HTML WG at present retains the responsibility of publishing the HTML specification itself. The publication is expected to operate under the following requirements:
- Be frequent;
- Minimise additive differences with the WHATWG version (but have extensive leeway to subset it);
- Aspire to be as close to reality, as supported by testing, as possible;
- Avoid the overhead of errata as much as possible, ideally completely;
- Be automated in every manner possible.
Note that “additive” describes features defined as part of the HTML WG or one of its related Community Groups. New features defined in the WHATWG, if acceptable and deemed to match reality, will simply be included.
Frequent publication is expected to be achieved through two-fold automation. First, the
draft is maintained as a set of transformations to the WHATWG’s version using a tool
called “Spork”. These transformations are
specified, as code, by the editors in charge of the HTML draft at W3C (the list of whom
still needs to be established). This avoids synchronisation issues that have made work
slow and painful in the past and serves to maintain the Landscape Document as direct documentation of
Spork’s operations. The ideal goal is to reach a point at which the W3C HTML specification
is just a subset of WHATWG HTML with two types of excisions: parts that do not match
reality, and parts that are being developed in separate documents. Second, the output from
these transformations is to be fed into the new Echidna automated publishing system and
published under /TR/html
.
It should be noted that while a strict subset is the desirable option, there are cases in which it is not entirely possible. To take an example from HTML 5.0, while in an ideal situation the ruby section of the HTML 5.0 specification could have been dropped and replaced with a separate extension specification, the interactions of that feature with the HTML parsing algorithm did not make that a viable option. Keeping such cases to a minimum is, however, an express goal. When needed, they are to be handled in the manner described in the paragraph on technical disputes.
The astute reader may note at this point that this organisation takes steps towards establishing the WHATWG as one CG (which it already is) that publishes through its coordination with the HTML WG, with modifications made to account for the atypical nature of the document. There are several ways in which such a setup would be desirable, and the organisation is deliberate. However it should be noted that it is not at this point a political reality, that making it so would require a number of issues between the two groups to be addressed, and that no claim is made here about endorsement from the WHATWG for this plan.
During the drive to get HTML 5.0 to Recommendation, the process employed was one of manual cherry-picking of individual WHATWG changes. Editors would both apply their own changes and integrate upstream changes from WHATWG HTML. One purported benefit of this approach was that HTML WG members were given explicit batch notifications of changes and had the opportunity to disagree with the acceptance or rejection of upstream changes. In practice, this opportunity was seldom used and the cherry-picking process was essentially a very costly way of accepting WHATWG changes. This proposal removes the cost while still making it possible for participants to maintain the ability to review accepted or rejected changes simply by tracking the commit logs from the upstream WHATWG HTML and Spork repositories. We would be willing to entertain discussions of alternatives, but only if such proposals include details describing how the both financial and technical aspects will be addressed.
The DOM specification is expected to follow a similar treatment, modulo the fact that strict subsetting (corresponding exclusively to test-failing) is far more likely. Having said that, some interoperability issues with the DOM that cannot be subsetted away are currently pending implementer input, and without such input the specification may, according to the principles expressed herein, find itself on indefinite hold.
The expectation is that the HTML specification will go to Recommendation every year, based on the features it contains that have tests and pass them sufficiently well. Rules concerning which tests ought to pass or not tend to have nasty side-effects (e.g. removing tests to ensure that the document passes and other such weaselling). Instead, the recommended practice is to make use of judgement calls when assessing interoperability, the key components of which being rough usability by developers and improvements compared to the previous year’s situation.
Even with the improvements to the errata process that the AB is considering which includes a number of simplifications, one has to question whether it is useful to maintain errata against HTML. Errata are valuable in the case in which no new features are being added to a specification, and patent commitments that were made for an existing Recommendation may no longer be made for the revised one.
HTML is not in such a situation. HTML is seeing new features, and we are not seeing major shifts in participation that impact patent commitments. The expectation is that publishing a Recommendation every year is sufficient to obviate the need for errata on previous Recommendations. Where required, these could be exposed as a diff of the documents as is likely to become possible with Process 2015 should the AB enact its modifications to the handling of errata (note however that such a diff would likely be large and hard to review).
Bug Handling
Over the past few years HTML-related bugs have been filed in both the WHATWG and the HTML WG. This duplication is at best a waste of effort and at worst induces confusion on its own.
In the future, when finding a bug in the core HTML specification, reviewers are expected to file it first against the HTML component of the WHATWG product in W3C’s Bugzilla. This proposal may not be consensual, but experience with handling the duplication has proven unpleasant (and wasteful). Alternatives suggestions are welcome; but the goal is just to be simple and efficient since there’s enough work for everyone and then some.
If the resolution of a given bug is not satisfactory (either to the reporting individual or to a third-party), it should be duplicated to the W3C Bugzilla HTML product for further discussion in the HTML WG, or to the corresponding CG bug tracker if applicable. Specific groups or individuals who have had clearly unpleasant interactions with the WHATWG in the past and feel it would be demoralising or demotivating to interact directly with the WHATWG to report HTML bugs can, after discussing the issue with the chairs of the HTML WG, skip straight to reporting bugs to the HTML WG. But in no case should bugs be reported twice as a first step.
For new features, the default mode of operation is for them to be defined in a separate document. They should therefore be directed to a CG if one exists that matches in scope, or failing that to Discourse where the community can help orient the proposal to its proper home, setting it up if needed.
A large bug backlog has accumulated while the HTML WG focused on shipping HTML 5.0. These bugs need to be ventilated and triaged amongst those that have been overtaken by events, those that have been fixed, those that aren’t relevant to the HTML 5.0 or HTML 5.1 document and those that, shockingly enough, need to be fixed.
Triaging the latter will require knowing where they need to be sent. This depends largely on the setup described herein coming into effect. It should be noted that some CGs may prefer bug tracking systems other than Bugzilla. In such cases the bugs will be moved there and the original tracker appraised accordingly.
Licensing
It is the de facto expectation of would-be contributors today that a project calling itself “open”, be it source, science, data, or standards, would operate under a contributor-friendly license in which rights granted for usage and modification are reciprocal. When developers learn that the W3C does not publish under such an agreement, they are baffled and at a loss for words. It simply does not fit into the W3C’s image as a place defending openness, and it certainly deprives the W3C’s standards from being considered open, let alone for W3C to take a credible open stand for anything.
In view of our goals for increased participation, and considering that all standards should be open, this plan’s recommendation is for the production of all CGs related to the HTML WG to be licensed under the W3C Software License. This license not only can be applied to specifications, but it also affords the guarantees desired from CC-BY while remaining GPL-compatible. It is also the default copyright license in the W3C Member Agreement (last 2 sentences of 7b) which states that “copyrightable materials (…) will be made available to the general public pursuant to the then-current W3C Software Notice and License.”
Adopting the W3C Software License for the HTML specification itself is also highly desirable, but would require the agreement of the AC. CGs however can freely adopt the license they desire and we suggest that they should use the W3C Software License unless overwhelming reasons not to are put forth.
Note: using a license explicitly labelled as being for “Software” might strike some — notably lawyers — as strange, and justifiably so. PSIG is currently discussing an update that would change the license’s title and replace “software” with “work” to clarify this point. This approach is in line with the general thinking of the open licenses community on this topic.
Example CGs
The set of CGs related to the HTML WG is meant to be dynamic and evolve over time in a flexible manner, the sole constraint being the chartered boundaries of the HTML WG. The following are however a few examples that could provide a good starting point based on existing experience.
- Editing
- The existing joint HTML-WebApps TF is already well under way but it is hitting up a few Invited Expert issues and could live with being a CG rather than the always clunky joint Task Force.
- Media APIs
- New Media APIs are needed, and some coherence could usefully be brought amongst all the people extending HTMLMediaElement. Some recent ideas about media controls could also fit here. Note that there is an existing HTML WG Media TF. Whether it should be extended to include new deliverables or whether two groups with different media aspects ought to be considered is left as a decision of the interested parties.
- Accessibility
- Much useful work is still needed in order for the Web platform to be accessible. While accessibility-review of other groups’ work is best conducted directly in those groups, this CG should define the technologies that are directly accessibility-centric. There has been some degree of dissent concerning some of the outputs from this task force; it is currently working on defining its upcoming work items.
- Canvas
- The 2DContext is an area of continued interest and given its specific, focused work could constitute a useful CG on its own.
- Markup for Application UIs
- There may be a set of elements that could usefully be added to HTML for (semantic) application components. Some work has already kicked off (in a deliberately discreet corner) about this and there is interest from some browser vendors. Also: form controls are still a problem.
Schedule
While the new group is meant to be flexible and oriented towards action — and therefore less amenable to centralised planning — the following schedule is expected to be applied:
- Discussion of this plan with the WG
- ASAP.
- Date of republication of HTML 5.1 as an Editors’ Draft
- In February. The new Echidna system is expected to support the publication. The goal is for a Recommendation by year end 2015.
- The mode of operation outlined in this document
- Assuming the HTML WG can agree to it, it is expected to be deployed during the coming HTML WG face to face meeting in April 2015.
- Rechartering of the group
- Much of the HTML WG rechartering depends on agreement about this plan. Assuming the April milestone is hit for that, a new charter can be proposed to the W3C Membership shortly thereafter.
- New CR for the DOM
- As explained above, our requirements to focus on interoperability are blocking the DOM specification’s progression along Recommendation-track until at least bug 22960 and bug 19431 are addressed through implementer decisions. Given the current lack of interoperability any alternative blesses an option with insufficient real-world support.


Raj Kumar Maurya
Gurgaon, Haryana
9818515510
<EMAIL_ADDRESS>Working as a Full Stack Developer at Accenture Solutions Pvt Ltd having {{completedate}} of IT experience
Working as a Full Stack Developer at Spade Infotech Pvt. Ltd having 1 year 8 Month of IT experience
Working as a Full Stack Developer at Pythhos Technology Pvt. Ltd having 9 month of IT experience
Working as a Full Stack Developer at Picsaxis Technologies Pvt. Ltd having 3 year 2 month of IT experience
I do hereby declare that the particulars of information and facts stated herein above are true, correct and complete to the best of my knowledge and belief.


@import conf.Config @(config: Config, menu: Menu)(hookForm: Form[controllers.HookForm], prismLookup: resources.PrismLookup)(implicit request: Security.AuthenticatedRequest[AnyContent, com.gu.googleauth.UserIdentity], messages: Messages) @import helper.CSRF @main("Create Post Deploy Hook", request) {
If the following tokens appear in the target URL or POST body, they will be replaced with details of the deploy that triggered the hook:
%deploy.@param%
%deploy.tag.tagName%
where tagName is any tag applied to the build


| DOSE: |
100 mg |
insufflated |
AMT |
One night I was with a group of friends and they had some AMT the kind that smells like mothballs, I insisted that one friend front me 2 capsules which had 50mg each in them. He did so I opened them up and emptied them out onto the table, everyone in the room told me donít snort that much because I will not like it. I said donít worry about it I have tripped my brains out before, this was the second time I took AMT. The first time I didnít have any visuals just the feeling like I was on MDMA, (the reason it didnít hit me was because of the cross tolerance the night before I took 1 roll) so I figured 100mg wouldnít do much more than the 50mg I took the first time.
 I said I am fine, finally after about 30min I decided to go home it didnít kick in yet, so I took my friend home and while I was driving home the AMT hit me, the visuals started. I was so lucky to have made it home that night. As soon as I came home I went downstairs and just was like oh man. The visions I saw were like nothing I had experienced before it was stronger than taking 13hits of acid seriously. I just sat there and my body was in euphoria and I closed my eyes and could swim with the dolphins in the ocean. It was that great.
Then the jaw clenching and the shivering started so I went and got some water and kept drinking water the rest of the time I was tripping. I just stayed in my basement the whole time because I couldnít let my mom see me like this so after the whole night of tripping my face off I went upstairs when the visuals were gone but the rolling feeling was still there. I went to my mom and told her what I did and she wasnít mad because of the fact it is legal.
I talked to her for about an hour and told her how I felt and all she sat there and talked to me about life and everything. I wouldnít recommend anyone taking 100mg their first time. It's very intense VERY INTENSE. Also make sure you drink plenty of water, as your body will appreciate that. I didnít throw up nor have any diarrhea as some people reported.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines interoperability test cases for Canonical XML 1.1 [XML-C14N1.1] and XML Signature Syntax and Processing, Second Edition [XMLDSIG2]. The changes tested include C14N11 handling of attributes in the XML namespace, including xml:id and xml:base, appropriate C14N11 nodeset to octet stream transform processing, modifications to RFC 3986 dot segment processing for C14N11, and RFC 4514 string encoding of Distinguished Names. The tests include standalone C14N11 tests as well as tests integrated with XML signature generation and validation. This document also includes earlier test cases used in XML Signature [XMLDSIG] for regression testing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The set of test cases documented in this report was used to provide evidence for implementation support for the Canonical XML 1.1 and XML Signature Proposed (Edited) Recommendations. While the Working Group might publish revised versions of this document to include mild improvements of the test documentation, there is no expectation that the core material in this document will change. It should be noted that no material in this document is normative; in particular, passing the tests documented in this document is neither necessary, nor sufficient for a conformance claim against either Canonical XML 1.1 or XML Signature 2nd Edition.
This document was developed by the XML Security Specifications Maintenance Working Group.
Please send comments about this document to<EMAIL_ADDRESS>(with public archive).
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Test Case Notation
1.2 Codes for Recommendation
References (Rec, SubRec)
1.3 Codes for Issues (SpecificIssue)
and Sub-Issues (SpecificSubIssue)
2 Acknowledgements
3 Test Cases specification
3.1 Legacy
XMLDSig Working Group Test Cases
3.2 Test
Cases for Canonicalization 1.1
3.2.1 Test Cases for xml:lang attribute
3.2.2 Test Cases for xml:space attribute
3.2.3 Test Cases for xml:id attribute
3.2.4 Test Cases for xml:base attribute
<IP_ADDRESS>
Test Cases for checking xml:base
attribute propagation
<IP_ADDRESS>.1
Test case
c14n11/xmlbase-prop-1
<IP_ADDRESS>.2
Test case
c14n11/xmlbase-prop-2
<IP_ADDRESS>.3
Test case
c14n11/xmlbase-prop-3
<IP_ADDRESS>.4
Test case
c14n11/xmlbase-prop-4
<IP_ADDRESS>.5
Test case
c14n11/xmlbase-prop-5
<IP_ADDRESS>.6
Test case
c14n11/xmlbase-prop-6
<IP_ADDRESS>.7
Test case
c14n11/xmlbase-prop-7
<IP_ADDRESS>
Test Cases for checking
XML-C14N1.1 specification tests
<IP_ADDRESS>.1
Test case
c14n11/xmlbase-c14n11spec-102
<IP_ADDRESS>.2
Test case
c14n11/xmlbase-c14n11spec2-102
<IP_ADDRESS>.3
Test case
c14n11/xmlbase-c14n11spec3-103
3.2.5 Test Cases for checking examples in the
XML-C14N1.1 Appendix
3.3 Test
Cases for XMLDSig
3.3.1 Test Cases for C14N 1.1 in
XMLDSig
3.3.2 Test Cases on nodeset to octet-stream
conversion by C14n 1.1 explicitly reflected in the chain of
transforms
3.3.3 Test Cases on schema based
XPointers and canonicalization
3.3.4 Test Cases on String encoding of
Distinguished Names
<IP_ADDRESS>
Test
Cases on differences identified in RFC 2253 and RFC
4514
<IP_ADDRESS>.1
Test case
xmldsig/dname/diffRFCs-1
<IP_ADDRESS>.2
Test case
xmldsig/dname/diffRFCs-2
<IP_ADDRESS>.3
Test case
xmldsig/dname/diffRFCs-3
<IP_ADDRESS>.4
Test case
xmldsig/dname/diffRFCs-4
<IP_ADDRESS>.5
Test case
xmldsig/dname/diffRFCs-5
<IP_ADDRESS>
Test Cases for
RFC 4514
<IP_ADDRESS>.1
Test case
xmldsig/dname/dnString-4
<IP_ADDRESS>.2
Test case
xmldsig/dname/dnString-6
<IP_ADDRESS>.3
Test case
xmldsig/dname/dnString-8
4 References
The test cases include standalone C14N 1.1 tests and test cases involving XML signature generation and validation. XML signatures are generated according to the details specified in this document.
All the test cases are positive (signatures that are valid).
Applications should validate these signatures and check that they are valid.
This section summarizes the notation used for identification of test cases.
A test case identifier matches the following pattern, and the syntax for describing the pattern is borrowed from section 2.0 of [XMLDSIG] (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences) and "|" denotes a choice.
Rec/(SubRec/)?(SpecificIssue-(SpecificSubIssue-)?)+TestNumber
The Rec
part identifies the source
recommendation for the test case.
The SubRec
part identifies a recommendation
that is tested in the context of Rec
.
The SpecificIssue
part identifies the issue
to be tested by the test case. The optional
SpecificSubIssue
part further refines the
issue to be tested.
The TestNumber
part numbers the test case.
It must be an integer number or an integer number followed
by a lowercase letter.
The next section identifies codes used throughout this document.
Rec
,
SubRec
)The following codes are used for identifying the source recommendations for the test cases:
c14n11
identifies the standalone
Canonical XML 1.1 [XML-C14N1.1] test cases.
xmldsig
identifies the XML Signature
Second Edition [XMLDSIG2] test
cases.
c14n11
identifies the test cases
that test c14n11
with
xmldsig
.
dname
identifies the test cases
that test [RFC 4514] versus
[RFC 2253] with
xmldsig
.
xpointer
identifies the test cases
that test [XPointer-Framework],
[XPointer-Element]
and [XPointer-xpointer] with
xmldsig
.
This structure is reflected in the directories c14n11/, xmldsig/, xmldsig/c14n11/, xmldsig/dname/ and xmldsig/xpointer/.
SpecificIssue
) and Sub-Issues
(SpecificSubIssue
)The following codes are used for identifying the issues and sub-issues for the test cases:
defCan
identifies the test cases that
test the [XMLDSIG2] implicit
and explicit rules managing the final canonicalization
that precedes the digest computation..
xmllang
identifies the test cases that
test the C14N11 handling of the xml:lang
attribute.
xmlspace
identifies the test cases that
test the C14N11 handling of the xml:space
attribute.
xmlid
identifies the test cases that
test the C14N11 handling of the xml:id
attribute.
xmlbase
identifies the test cases that
test the C14N11 handling of the xml:base
attribute.
The following sub-issues are associated with this issue:
prop
identifies the test cases that
test the C14N11 propagation of the
xml:base
attribute through the node
tree.
annexA
identifies the test cases
that test the C14N11 Remove Dot Segments examples
listed in Appendix A of [XML-C14N1.1].
c14n11spec
identifies the test
cases that test the examples in the [XML-C14N1.1] specification.
dnString
identifies the test cases that
test the string encoding of Distinguished Names.
diffRFCs
identifies the test cases that
test the differences between [RFC
2253] and [RFC 4514].
xpointer
identifies the test cases that
test the handling of XPointer Reference URIs as
specified in [XMLDSIG2]
Major contributions to this document were received from Juan Carlos Cruellas, UPC; Konrad Lanz, A-SIT; Sean Mullan, Sun Microsystems; Pratik Datta, Oracle; Frederick Hirsch, Nokia; Bruce Rich, IBM; Thomas Roessler, W3C. The test cases in this document were reviewed by the members of the W3C XML Security Specifications Maintenance Working Group.
The following sub-sections describe each of the test cases and are grouped by Recommendation and Issue.
The IETF/W3C XML-DSig Working Group produced an interoperability test matrix that can be found at [XMLDSIG-interop].
The set of test cases in this section are designed to test the C14N11 handling of attributes in the xml namespace. The input for each of these test cases is an XML document and an XPath document subset expression. Two different sets of tests are included based on the test cases in this section.
Standalone tests: no XML signature generation or validation is required. The XPath document subset expression is applied to the input document. These tests are used to check that the implementation for [XML-C14N1.1] behaves correctly.
Integrated tests with XML signatures: In these set of tests, an XML signature is generated based on the input document and a corresponding XPath Filtering Transform as indicated in the tables. For these set of tests, the following rules apply:
The XML Signature is generated using the
HMAC-SHA1 SignatureMethod algorithm and a secret
key with the value:
"secret".getBytes("ASCII")
.
The Transforms
element contains a
sequence of two transforms:
An XPath Filtering Transform that contains an XPath expression that depends on the test case.
A Canonical XML 1.1 Transform.
xml:lang
attributeThe set of test cases in this section test the C14N11
handling of xml:lang
attributes.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11Xmllang xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:lang="EN"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11Xmllang>
Note:
Document subset expressions for document subsets computation are defined as in [XML-C14N1.1].
| Input details | To-Be-Signed (TBS henceforth) data object
with ONLY a xml:lang attribute in a
certain element e whose content
includes other elements. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element e . |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Input details | TBS data object with ONLY a
xml:lang attribute in a certain
element e whose content includes
other elements. The ds:Transform
contains a XPath expression whose result is a
node set that DOES NOT include neither element
e nor any of its children
elements. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e2] |
| Output |
<ietf:e2 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e21></ietf:e21> </ietf:e2> |
| Input details | TBS with ONLY a xml:lang
attribute in a certain element e
whose content includes a sequence of one element.
The ds:Transform contains a XPath
expression whose result is a node set that DOES
NOT include element e but includes
one child element. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e111></ietf:e111> </ietf:e11> |
| Input details | TBS with ONLY a xml:lang
attribute in a certain element e
whose content includes a sequence of more than
one element (these children may in turn contain
children elements). The ds:Transform
contains a XPath expression whose result is a
node set that DOES NOT include element
e but includes more than one of its
children elements. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:lang attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*)[ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:lang="EN"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2" xml:lang="EN"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:space
attributeThe set of test cases in this section test the C14N11
handling of xml:space
attributes.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlSpaceDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:space="true"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11XmlSpaceDoc1>
| Input details | TBS data object with ONLY a
xml:space attribute in a certain
element e whose content includes
other elements. The ds:Transform
contains a XPath expression whose result is a
node set that includes element
e . |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Input details | TBS data object with ONLY a
xml:space attribute in a certain
element e whose content includes
other elements. The ds:Transform
contains a XPath expression whose result is a
node set that DOES NOT include neither element
e nor any of its children
elements. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e2] |
| Output |
<ietf:e2 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e21></ietf:e21> </ietf:e2> |
| Input details | TBS with ONLY a xml:space
attribute in a certain element e
whose content includes a sequence of one element.
The ds:Transform contains a XPath
expression whose result is a node set that DOES
NOT include element e but includes
its child element. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e111></ietf:e111> </ietf:e11> |
| Input details | TBS with ONLY a xml:space
attribute in a certain element e
whose content includes a sequence of more than
one element (these children may in turn contain
children elements). The ds:Transform
contains a XPath expression whose result is a
node set that DOES NOT include element
e but includes more than one of its
children elements. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:space attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:space="true"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2" xml:space="true"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:id
attributeThe set of test cases in this section test the C14N11
handling of xml:id
attributes.
Below is the input document for all the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlIdDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:id="IdInterop"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:c14n11XmlIdDoc1>
| Input details | TBS with ONLY a xml:id attribute
in a certain element e whose content
includes other elements. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element e . |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:id attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" xml:id="IdInterop"> <ietf:e11> <ietf:e111></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121></ietf:e121> </ietf:e12> </ietf:e1> |
| Input details | TBS with ONLY a xml:id attribute
in a certain element e whose content
includes other elements. The
ds:Transform contains a XPath
expression whose result is a node set that DOES
NOT include the element e but some
of the children of the element
e . |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] handle xml:id attributes as defined in [XML-C14N1.1] |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> <ietf:e111></ietf:e111> </ietf:e11>\ + <ietf:e12 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" at="2"> <ietf:e121></ietf:e121> </ietf:e12> |
xml:base
attributeThe set of test cases in this section test the C14N11
handling of xml:base
attributes.
Three sets of test cases have been defined:
Tests that check if the implementation correctly
propagates the xml:base
attributes
through the node tree.
Tests that check if the implementation correctly processes the examples involving xml:base propagation in the [XML-C14N1.1] specification.
Tests that check if the implementation correctly processes the examples in the Appendix of [XML-C14N1.1]
xml:base
attribute
propagationThis section defines test cases that test how
implementations propagate xml:base
attributes through the tree when the result of the
filtering is a document subset.
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e1 xml:base="/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"/> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"/> </ietf:e12> </ietf:e1> <ietf:e2> <ietf:e21 xml:base="/xmlbase21/"/> </ietf:e2> <ietf:e3> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlBaseDoc1>
The document's root element
ietf:c14n11XmlBaseDoc1
defines an
xml:base
attribute. This element contains
three children elements.
The first element ietf:e1
has another
xml:base
attribute. All the
ietf:e1
's descendant elements have a
xml:base
attribute. Transforms that select
subsets of ietf:e1
's descendants will test
how each level in the tree of elements incorporates its
corresponding part to the value of the final
xml:base
.
The second element ietf:e2
does not
have a xml:base
attribute, but its child
element, ietf:e21
has a
xml:base
attribute. Transforms that select
ietf:e21
will test how it takes the value
of xml:base
from an ancestor different
than its parent.
As for the third element, neither it nor any of its
descendants have a xml:base
attribute.
Transforms that select ietf:e3
or any of
its descendants will test how they inherit the
xml:base
attribute from the root element
without any further processing.
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element
ietf:c14n11XmlBaseDoc1 and the
child ietf:e1 and its
descendant. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] work properly
when the xml:base origin appears
in the output document subset and also children
with xml:base , which do not
require further processing, are also
present. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e2)] |
| Output |
<ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e1 xml:base="/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"></ietf:e121> </ietf:e12> </ietf:e1> <ietf:e3> <ietf:e31 at="3"></ietf:e31> </ietf:e3> </ietf:c14n11XmlBaseDoc1> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element ietf:e1 and its
descendant but not
ietf:c14n11XmlBaseDoc1 . |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] properly build
the xml:base at the first level
(ietf:e1 ). |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1] |
| Output |
<ietf:e1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase1/"> <ietf:e11 xml:base="/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 xml:base="/xmlbase121/"></ietf:e121> </ietf:e12> </ietf:e1> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element ietf:e11 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 and
ietf:e1 do not appear. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] properly build
the xml:base if one of
intermediate the levels (ietf:e1 )
are absent from the document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11] |
| Output |
<ietf:e11 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase11/"> <ietf:e111 xml:base="/xmlbase111/"></ietf:e111> </ietf:e11> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element ietf:e111 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e11 and ietf:e1
do not appear. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] properly build
the xml:base if several
intermediate levels (ietf:e1 and
ietf:e11 ) are absent from the
document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e111] |
| Output |
<ietf:e111 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase111/"></ietf:e111> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element ietf:e2 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e1 and its descendant, and
ietf:e3 and its descendant do not
appear. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] properly build
the xml:base if one intermediate
level (ietf:e2 ) without any
xml:base attribute is absent from
the document subset. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e21] |
| Output |
<ietf:e21 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase21/"></ietf:e21> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes element ietf:e3 and its
descendant. Elements
ietf:c14n11XmlBaseDoc1 ,
ietf:e1 and its descendant, and
ietf:e2 and its descendant do not
appear. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] properly build
the xml:base in one element that
originally had no xml:base
attribute. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e3] |
| Output |
<ietf:e3 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e31 at="3"></ietf:e31> </ietf:e3> |
| Input details | The document shown above. The
ds:Transform contains a XPath
expression whose result is a node set that
includes elements
ietf:c14n11XmlBaseDoc1 and
ietf:e3 and its descendant.
Elements ietf:e1 and its
descendant, and ietf:e2 and its
descendant do not appear. |
|---|---|
| Rationale | Check that implementations of [XML-C14N1.1] do not pass
the xml:base to another element
when it is not necessary. |
| Document subset expression | (//. | //@* | //namespace::*) [ancestor-or-self::ietf:c14n11XmlBaseDoc1 and not(ancestor-or-self::ietf:e1 or ancestor-or-self::ietf:e2)] |
| Output |
<ietf:c14n11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"\ + xml:base="http://xmlbase.example.org/xmlbase0/"> <ietf:e3> <ietf:e31 at="3"></ietf:e31> </ietf:e3> </ietf:c14n11XmlBaseDoc1> |
This section defines test cases that are based on
the examples in the C14N11 specification that propagate
xml:base
attributes through the tree when
the result of the filtering is a document subset.
Below is the input document from section 3.8 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-102 below:
<!DOCTYPE doc [ <!ATTLIST e2 xml:space (default|preserve) 'preserve'> <!ATTLIST e3 id ID #IMPLIED> ]> <doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="http://www.example.com/something/else"> <e1> <e2 xmlns="" xml:id="abc" xml:base="../bar/"> <e3 id="E3" xml:base="foo"/> </e2> </e1> </doc>
| Input details | The input document shown above. |
|---|---|
| Rationale | Check that correct xml:base fixup is performed. |
| Document subset expression | (//. | //@* | //namespace::*)[self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) or count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())] |
| Output |
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="http://www.example.com/something/else">\ + <e3 xmlns="" id="E3" xml:base="../bar/foo" xml:space="preserve">\ + </e3></e1> |
Below is the input document similar to the example from section 3.8 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-102 below. The main difference is that the value of the xml:base attribute of the e2 element is "bar/" instead of "../bar".
<!DOCTYPE doc [ <!ATTLIST e2 xml:space (default|preserve) 'preserve'> <!ATTLIST e3 id ID #IMPLIED> ]> <doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="something/else"> <e1> <e2 xmlns="" xml:id="abc" xml:base="bar/"> <e3 id="E3" xml:base="foo"/> </e2> </e1> </doc>
| Input details | The input document shown above. |
|---|---|
| Rationale | Check that correct xml:base fixup is performed. |
| Document subset expression | (//. | //@* | //namespace::*)[self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) or count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())] |
| Output |
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"\ + xml:base="something/else">\ + <e3 xmlns="" id="E3" xml:base="bar/foo" xml:space="preserve">\ + </e3></e1> |
Below is the input document from section 2.4 of [XML-C14N1.1] for the test case c14n11/xmlbase-c14n11spec-103 below.
<?xml version="1.0" encoding="UTF-8"?> <a xml:base="foo/bar"> <b xml:base=".."> <c xml:base=".."> <d xml:base="x"> </d> </c> </b> </a>
| Input details | The input document shown above. |
|---|---|
| Rationale | Check that correct xml:base fixup is performed. This test illustrates the modification of the "Remove Dot Segments" algorithm. |
| Document subset expression | (//. | //@* | //namespace::*) [self::a or ancestor-or-self::d] |
| Output |
<a xml:base="foo/bar"><d xml:base="../../x"> </d></a> |
This section defines test cases for checking if implementations are compliant with [XML-C14N1.1], specifically the normative rules in the Document Subsets section. Informative examples are given in the Appendix of C14N11.
Each test case in this section specifies an input string, representing a URI that must be processed according to the modified Remove Dot Segments algorithm described in Section 2.4 (Document Subsets) of [XML-C14N1.1].
Each test case appears in a row of the table shown below. The first column identifies the input URI that has to be processed. The second column shows the corresponding output.
| inputs.txt | outputs.txt |
|---|---|
no/.././/pseudo-netpath/seg/file.ext no/..//.///pseudo-netpath/seg/file.ext yes/no//..//.///pseudo-netpath/seg/file.ext no/../yes no/../yes/ no/../yes/no/.. ../../no/../.. no/../.. no/.. no/../ /a/b/c/./../../g mid/content=5/../6 ../../.. no/../../ ..yes/..no/..no/..no/../../../..yes ..yes/..no/..no/..no/../../../..yes/ ../.. ../../../ . ./ ./. //no/.. ../../no/.. ../../no/../ yes/no/../ yes/no/no/../.. yes/no/no/no/../../.. yes/no/../yes/no/no/../.. yes/no/no/no/../../../yes yes/no/no/no/../../../yes/ /no/../ /yes/no/../ /yes/no/no/../.. /yes/no/no/no/../../.. ../../..no/.. ../../..no/../ ..yes/..no/../ ..yes/..no/..no/../.. ..yes/...no/..no/..no/../../.. ..yes/..no/../..yes/..no/..no/../.. /..no/../ /..yes/..no/../ /..yes/..no/..no/../.. /..yes/..no/..no/..no/../../.. / /. /./ /./. /././ /.. /../.. /../../.. /../../.. //.. //..//.. //..//..//.. /./.. /./.././.. /./.././.././.. . ./ ./. .. ../ |
pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext yes/pseudo-netpath/seg/file.ext yes yes/ yes/ ../../../ ../ /a/g mid/6 ../../../ ../ ..yes/..yes ..yes/..yes/ ../../ ../../../ / ../../ ../../ yes/ yes/ yes/ yes/yes/ yes/yes yes/yes/ / /yes/ /yes/ /yes/ ../../ ../../ ..yes/ ..yes/ ..yes/ ..yes/..yes/ / /..yes/ /..yes/ /..yes/ / / / / / / / / / / / / / / / ../ ../ |
The test cases in section [TestCases-C14n11] are performed
in the context of XMLDSig as well. Here it should be
noted that this is performed in a different location
(i.e. xmldsig/c14n11/)
and the XPath-Filter expression in the
ds:Transform/ds:XPath
should be equal to the
filter step of the XPath expressions in section [TestCases-C14n11] (cf.
explanation). The test cases are specified by an
"unsigned" ds:Signature
(without
ds:DigestValue
and
ds:SignatureValue
) in files in xmldsig/c14n11/ having the
postfix ...-template.xml
.
The set of test cases in this section test the
Reference Generation steps of [XMLDSIG2] and its rules that manage the
contents of the Transforms
element when
nodeset to octet-stream conversions are to be performed
by canonicalization.
General rules for these test cases:
Test cases contain a ds:Transforms
element with one child, containing a XPath filter
that depends on the test case.
| Input details | The same input document as in section [XMLBASE]. |
|---|---|
| Rationale | Check that implementations and APIs of
[XMLDSIG2] honor the
recommendation to use [XML-C14N1.1] in section 3.1.1
"Reference Generation" of [XMLDSIG2] and make its use
explicit as a ds:Transform . |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. It is expected that c14n11 is inserted at the relevant places. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:c14n11XmlBaseDoc1 and\ + not(ancestor-or-self::ietf:e2)</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>t7d2cL8Ink8A5i3cS9/bu9MBBU8=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>LR4s+Nxoq3VZO1NiCLoiovfCpK4=</SignatureValue>\ + </Signature> |
| Input details | The same input document as in section [XMLBASE]. |
|---|---|
| Rationale | Check that implementations and APIs of
[XMLDSIG2] honor the
recommendation to use [XML-C14N1.1] in section 3.1.1
"Reference Generation" of [XMLDSIG2] and make it's use
explicit as a ds:Transform . It is
expected that c14n11 is inserted at the relevant
places. |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. The focus in this test case is to assure that c14n11 is inserted before transforms requiring an octet stream as input and also at the end of the chain of transforms if necessary because the last transform resulted in a node set. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:e21</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">1</XPath>\ + </Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>fL7Igzs0LL7lKHJzAJIKYCphYBo=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>bKQLywY51VZwjutUX/CUMsVs6RE=</SignatureValue>\ + </Signature> |
| Input details | The same input document as in section [XMLBASE]. |
|---|---|
| Rationale | Check that implementations and APIs of
[XMLDSIG2] honor the
recommendation to use [XML-C14N1.1] in section 3.1.1
"Reference Generation" of [XMLDSIG2] and make it's use
explicit as a ds:Transform . It is
expected that c14n11 is inserted at the relevant
places. The focus in this test case is to assure
that c14n11 is inserted before transforms
requiring an octet stream as input but not
inserted at the end of the chain of transforms,
which is not necessary because the last transform
resulted in an octet stream. |
| Template | This template can be used to instruct some API to create a signature with a chain of transforms that would require implicit transformations from a node set to an octet stream. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="c14n11/xml-base-input.xml"><Transforms>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">\ + ancestor-or-self::ietf:e21</XPath></Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">\ + <XPath xmlns:ietf="http://www.ietf.org">1</XPath>\ + </Transform>\ + <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">\ + <xsl:stylesheet version="1.0"\ + xmlns="http://www.w3.org/1999/XSL/Transform"\ + xmlns:xsl="http://www.w3.org/1999/XSL/Transform">\ + <xsl:template match="@*|node()"><xsl:copy>\ + <xsl:apply-templates select="@*|node()"/></xsl:copy>\ + </xsl:template></xsl:stylesheet></Transform>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>hqabUu4fEZp7GK5JRyFC26W5JBk=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>9+wp0W9xwL5X3kSttxABZ7p/kU0=</SignatureValue>\ + </Signature> |
This section defines test cases that test if implementations behave correctly when processing both schema-based xpointers and short-name xpointers with regards to comments present in the to be signed xml data object.
The following rules apply to the test cases in this section:
As the model processing is defined in [XMLDSIG2], the test cases are based
on XML signatures. For each test case, an XML
signature will be generated and validated. The
signatures will be enveloped signatures when the
URI
attribute is referencing the root
element and enveloping when the URI
attribute is referencing an element using its Id
attribute.
The input for the test cases is the to be signed
xml data object shown below and the
ds:Reference
's URI
attribute value (a schema-based xpointer or a
short-name pointer).
The ds:Reference
for enveloped
signatures will eventually contain two
Transform
elements, namely; the
enveloped signature transform and the conversion from
node set data to octet stream (canonical XML
1.1).
Below is the input document for the test cases in this section:
<?xml version="1.0" encoding="UTF-8"?> <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org" > \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11 > <!-- This is a comment for ietf:e11 element --> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21 /> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1>
| Input details | The signature is an enveloped signature. It
appears as the last child of the root element.
The document enveloping the signature is the one
shown at the beginning of this section. The value
of the URI attribute is
"#xpointer(/)" (find it here). |
|---|---|
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting the root element and its descendant, and that comments are preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(/)"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>/IZyGLL72rXhisXRkB617TxJrL8=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>E4gxKwllVjvvlUQFe9p/ssO7Yxw=</SignatureValue>\ + </Signature></ietf:c14n11XmlPointerDoc1> |
| Input details | The signature is an enveloping signature. The
enveloped document is the one shown at the
beginning of this section. The value of the
URI attribute is
"#xpointer(id('e1ID'))" (find it here). |
|---|---|
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting an element identified by its id attribute as well as its descendant, and that comments are preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(id('e1ID'))"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>XhSsDpWTt+ti0kcU9XYpleRDHfQ=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>brEpICVA4lg7eQwz7i/rlBmYXiU=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Input details | The signature is an enveloped signature. It
appears as the last child of the root element.
The document enveloping the signature is the one
shown at the beginning of this section. The value
of the URI attribute is "". |
|---|---|
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting the root element and its descendant, and that comments are not preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI=""><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>gaV5r7qC3Ve/t641+d3ykN8JFSc=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>gS1QKSwAH/6eE3OFi/L9O0oKKig=</SignatureValue>\ + </Signature></ietf:c14n11XmlPointerDoc1> |
| Input details | The signature is an enveloping signature. The
enveloped document is the one shown at the
beginning of this section. The value of the
URI attribute is "#e1ID" (find it
here). |
|---|---|
| Rationale | Check that implementations, following the rules stated in the [XMLDSIG2] model, dereference the URI getting an element identified by its id attribute as well as its descendant, and that comments are not preserved before proceeding with the computation of digest. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#e1ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>3K+K4MbR2EW7l/ry59XockKqt4g=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>dgyjONUs9rBjW7PH25seGqcMNZY=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Input details | The signature is an enveloping signature and
signs three elements from the document. The
enveloped document is the one shown at the
beginning of this section. There are three
ds:Reference elements. For the first
one the value of the URI attribute
is "#xpointer(id('e1ID'))" (find it
here). For the second, it is
"#xpointer(id('e2ID'))" (find it
here). For the third one, it is
"#xpointer(id('e3ID'))" (find it
here). |
|---|---|
| Rationale | Check implementation's behaviour when processing several elements (with and without comments) referenced by its Id attribute using a schema-based xpointer. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#xpointer(id('e1ID'))"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>XhSsDpWTt+ti0kcU9XYpleRDHfQ=</DigestValue>\ + </Reference><Reference URI="#xpointer(id('e2ID'))">\ + <Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>abyA1j4yzf1IgQLWwDwKuU9l8Ik=</DigestValue>\ + </Reference><Reference URI="#xpointer(id('e3ID'))">\ + <Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>RUUBiUeFf8uRqTlpCyutkXDqnJ4=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>sG+0pHk9TB6v7jES9RZUIVKMFos=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
| Input details | The signature is an enveloping signature and
signs two elements from the document. The
enveloped document is the one shown at the
beginning of this section. There are three
ds:Reference elements. For the first
one the value of the URI attribute
is "#e1ID" (find it
here). For the second, it is "#e2ID" (find it
here). For the third one, it is "#e3ID" (find
it
here). |
|---|---|
| Rationale | Check implementation's behaviour when processing several elements (with and without comments) referenced by its Id attribute using a short-name xpointer. |
| Signature |
<?xml version="1.0" encoding="UTF-8"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>\ + <Reference URI="#e1ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>3K+K4MbR2EW7l/ry59XockKqt4g=</DigestValue>\ + </Reference><Reference URI="#e2ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>hnKFjGFr/jwLCCTckZpaclOwe28=</DigestValue>\ + </Reference><Reference URI="#e3ID"><Transforms>\ + <Transform\ + Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>\ + </Transforms>\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>RUUBiUeFf8uRqTlpCyutkXDqnJ4=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>XzEJQ+whhHUYlqiCEt8XFxC8wpk=</SignatureValue>\ + <Object>\ + <ietf:c14n11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org"\ + xmlns:w3c="http://www.w3.org"> \ + <!-- This is a xml document for checking behaviour of tools with\ + regards to comments when using scheme-based xpointers in the\ + ds:Reference's URI attribute --> <ietf:e1 xml:id="e1ID"> <!-- This is a comment for ietf:e1 element --> <ietf:e11> <!-- This is a comment for ietf:e11 element --> <ietf:e111/> </ietf:e11> <ietf:e12 at="2"> <!-- This is a comment for ietf:e12 element --> <ietf:e121/> </ietf:e12> </ietf:e1> <ietf:e2 xml:id="e2ID"> <!-- This is a comment for ietf:e2 element --> <ietf:e21/> </ietf:e2> <ietf:e3 xml:id="e3ID"> <ietf:e31 at="3"/> </ietf:e3> </ietf:c14n11XmlPointerDoc1></Object></Signature> |
This Working group has identified a number of differences between [RFC 4514] and [RFC 2253]. They are described in this e-mail within the XML Security Specifications Maintenance Working Group e-mail list archive. This section contains test cases designed for checking that applications can parse and generate RFC 4514 Distinguished Names with these differences.
The following rules apply for the test cases defined in this section:
The input to each test case is an XML Signature. Each signature contains an X509SubjectName or X509IssuerSerial element with an RFC 4514 Distinguished Name.
To resolve the key, the application must find a certificate containing a matching issuer/serial or subject DN from the certificates that are contained in the "certs" directory. This verifies that the implementation can parse the RFC 4514 DN and find a matching certificate with an equivalent subject or issuer DN.
Signature generation is also required. A PKCS#12 KeyStore containing the private keys used to generate the signatures is in the file "certs/keystore.p12". The keystore password is "secret". The key entry name is the same as the corresponding certificate file name (without the ".crt" part).
The generated signature should contain an X509SubjectName or X509IssuerSerial element with an RFC 4514 distinguished name as specified in the "[RFC-4514] DN" row of each of the tables in this section. However, if an implementation does not support an optional encoding as specified by RFC 4514, it is acceptable to generate a DN that is not strictly equivalent to those in the table but that is still RFC 4514 compliant.
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains one Relative Distinguished Name whose attribute type keyword is encoded with one alphabetic character, and another Relative Distinguished Name whose attribute type keyword is encoded with two characters. RFC 4514 allows attribute type keywords to be of length 1, whereas RFC 2253 (erroneously) requires them to be at least length 2. |
|---|---|
| Rationale | Check processing of attribute type keywords by tools implementing [RFC 4514]. |
| [RFC 4514] DN | CN=John,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + DOz4KhJHOvhzPiKjxl0WVsrXPuZ9XQtdDvKN0KuLQGIzXkljfkFEQA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=John,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing space characters. [RFC 2253] (erroneously) does not allow escaping, whereas [RFC 4514] allows space characters to be escaped. |
|---|---|
| Rationale | Check escaping of space characters by tools implementing [RFC 4514]. |
| [RFC 4514] DN | CN=\ Spacey\ ,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + V18nxls1pqn4IyA/GNosGfqLHEE6INnyuV9TmHlYt/sYsaagHCH9Xw==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=\ Spacey\ ,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing a null character. [RFC 2253] does not require null characters to be escaped, whereas [RFC 4514] requires null characters to be hex escaped. |
|---|---|
| Rationale | Check escaping of null characters by tools implementing [RFC 4514]. |
| [RFC 4514] DN | CN=\00,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + N6jHpYnYpggrfADJkvZfggCaUq9dzU9M3EQ+27wA8f92nWwmrlyUQQ==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=\00,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing a non-leading number sign character that is not escaped. [RFC 2253] requires escaping of non-leading number sign characters, whereas [RFC 4514] does not. |
|---|---|
| Rationale | Check processing of non-leading number sign characters that are not escaped by tools implementing [RFC 4514]. |
| [RFC 4514] DN | CN=Num#ber,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + QN8dVUz4674CG7tnHJ+VSDFKbttZ3Ywa5rizoYS2EGUD8/33RFlZJA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Num#ber,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing an equals sign character that is not escaped. [RFC 2253] requires escaping of equals sign characters, whereas [RFC 4514] does not. |
|---|---|
| Rationale | Check processing of equals sign characters that are not escaped by tools implementing [RFC 4514]. |
| [RFC 4514] DN | CN=Eq=uals,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + TEFSu5hmr8r5JU78U9MgS0mdZIZOXUjORTRzDFaBWh9DhFjPjxxW4w==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Eq=uals,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
The set of test cases in this section are designed to test the representation of Distinguished Names as Strings as specified by [RFC 4514] and augmented by the optional encoding rules of section <IP_ADDRESS> of [XMLDSIG2].
The same rules defined in section <IP_ADDRESS> apply to the test cases in this section.
Also, with respect to signature generation, if an implementation does not support an optional encoding as specified by RFC 4514 or XMLDSIG2, it is acceptable to generate a DN that is not strictly equivalent to those in the table but that is still RFC 4514 compliant.
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing trailing space characters that have been escaped as "\20" instead of "\ ", as specified by the optional encoding rules of [XMLDSIG2]. |
|---|---|
| Rationale | Check that implementations correctly manage escaping of trailing space characters. |
| [RFC 4514] DN | CN=Trailing\20\20,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + ONd8OoOnv9OThyiTPkneEcsdgVt65w6AgUAxidekHeKmjyQxnYEdWA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Trailing\20\20,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing an ASCII control character that has been escaped as "\09" (instead of not escaping it), as specified by the optional encoding rules of [XMLDSIG2]. |
|---|---|
| Rationale | Check that implementations correctly handle escaping of an ASCII control character. |
| [RFC 4514] DN | CN=Con\09trol,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + V34pKGIfKacwJtTEShfSXx4M2dhSOTqZVCIL6nO66lm+JTQ//wCKaA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=Con\09trol,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |
| Input details | The input is an XML Signature containing an X509SubjectName in RFC 4514 format. The DN contains a Relative Distinguished Name containing several characters that must be escaped, as specified by [RFC 4514]. |
|---|---|
| Rationale | Check that implementations correctly manage escaping of the special characters (except '"', 'lt;' and '>'). |
| [RFC 4514] DN | CN=E\+s\,c\;aped,C=US |
| Signature |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>\ + <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\ + <SignedInfo>\ + <CanonicalizationMethod\ + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\ + <SignatureMethod\ + Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>\ + <Reference URI="#object">\ + <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>\ + <DigestValue>nxGVxTzX3uQVeaZ7vtWMLc+V6CE=</DigestValue>\ + </Reference></SignedInfo>\ + <SignatureValue>\ + L2r+QCiO0qOPgDYybThQEbP7A8Iq8AomDGBXgQqe4mkuLMnroTxnGA==</SignatureValue>\ + <KeyInfo><X509Data>\ + <X509SubjectName>CN=E\+s\,c\;aped,C=US</X509SubjectName>\ + </X509Data></KeyInfo>\ + <Object Id="object">Approved</Object></Signature> |