San Jose XML Signature Notes [ascii]

Chairs: Donald Eastlake 3rd, Joseph Reagle Jr.
Author: Joseph Reagle Jr.

Attendees

Mark Bartel, JetForm
John Boyer, UWI
Donald Eastlake 3rd, Motorola
Barbara Fox, Microsoft
Peter Lipp, IAIK TU Graz
Brian LaMacchia, Microsoft
Joseph Reagle, W3C
Jim Schaad, Microsoft
Ed Simon, Entrust
Raghavan (Rags ) Srinivas, Sun
Petteri Stenius, Remtec
Greg Whitehead, Signio
Eric Rescorla, RTFM
Kyle Austin, Digitrust
Satyajit Nath, Valicert
Mack Hicks, Bank of America
William White, Baltimore
Kevin Kingdon , RSA Security
Maryann Hondo, IBM
(regrets) David Smiley, Sagasoftware
(regrets) David Solo,Citigroup

9:00 AM Status, Changes to Agenda, etc.

Requirements document has been approved by the IESG except that it needs an Author's Address section and a one sentence Security Considerations section added.

There were no agenda changes.

9:10 AM W3C XML Canonicalization document

ACTION: Simon and Schaad to prepare a draft Signature WG report on Canonical XML by end of first week of February.

9:40 AM XML DSIG Implementation Experience & examples

Petteri Stenius: RPX Signature, Implementation of an XML Signature component [Slides]

His canonicalization algorithm (C14N) strips whitespace and removes Signature elemenets. For instance, his c14n as applied to Target="" automatically removes any element of the Signature namespace. (Presently, spec says use an XPath transform.)
Stenius: Specification seems very complex. Three types of signatures, many scenarios. The spec could just give the syntax of a signature without References, how you relate a detached signature to the data signed could be another specification.
Verifying is most difficult:
- So many items to calculate the digest of, if one is wrong, the whole thing m ight be wrong.
How does an application go to look at specifications or semantic definitions so it knows what to do? For instance, how do you do time stamps?
(Rescorla: there are about 8 ways to do it, the trick is that the time-stamping authority need not see that data itself.)
How to have multiple signatures. (Co-signing (parallel), counter-signing, and ti me stamping). PKCS-7 is split. How the data is processed is very simple, the other document is the other things. Fox: presently, not in scope of WG. Eastlake: correct, though more specific semantic labeling could be a future activity.
Canonical XML isn't intended to work over a fragment, it only produces well formed XML documents. However, a serialized XPath result may very well not be a well-formed document!

Ed Simon, XSLT and XMLDSIG engines.

See slides and source.

10:40 AM Break

11:00 AM Initial discussion of main points of contention

Manifest Syntax: Why are the Objects and References specified as they are? Do you always nee d a Ref? Can you just have two Objects? Is order important?

Eastlake: the purpose of the Manifest was to:

Defer digest validation
Syntactical abbreviation for lots of signatures.

WG agrees: Move to (Ref*). (There is no need to include Objects within a Manifest w here they could just be directly referenced from SignedInfo.)

Introducing Signature Semantics:

Introduce semantics via an Object or SignatureProperty. SignatureProperty is not the only place where you might place an assertions stating "I intend this signatu re as an {assertion, vouch, check}". Could be in a database, a separate RDF assertion, or somewhere else!
Reagle: why Manifest and SignatureProperty XML element-types and namespaces? It is very redundant and confusing.

Types

Eastlake Proposal: The type in a ref defines the referent. The type of an object defines the content of the object.
Reagle Tentative Proposal: Remove Manifest and SignatureProperty XML element typ es, just use an Object with a particular type.
ACTION Reagle: solicit proposals with a series of structured questions and ask D avid to be specific. Does the Reference have a type? Does the Reference identify an Object or the specific element-type within the Object? What does the Object type refer to?
Proposal: Object has a MimeType; References have Types.
What does null canonicalization mean? People that use null might have their own byte (big/little endian) orders. Null implies no guarantee of interoperability, but eve ryone agrees that is the risk in using it. However, why have a specific namespace for it ? ACTION Editors: remove null namespace and make the meaning of the CanonicalizationMethod not being present in SignedInfo mean that nothing happens. (Move text of 5.5.1 to 3.3. 1).

KeyInfo

Further specification? If we give a lot more detail it could end up being the la rgest part of the spec, participants agree that it has pretty much the right balance now though we could perhaps give a few more simple examples.
Review of the key structures:
- Result: Fold KeyName and SubjectName into (just KeyName).
- Result: X509Name should be disambiguated into X509SubjectName and X509Issuer Name as appropriate.
- Result: Change RetrievalMethod schema type to URI.

Explicit algorithm parameters

Confirmed: We have removed the element type Parameter. They are in 000114 because of an editorial error.
Do we permit ANY, MIXED, or elementOnly within Transform? Result: should be elementOnly.
Review of parameter sections:
Results: 5.1 (first paragraph): "the parameter element types can be defined by an external namespace, or the ones within the Core spec."
Rescorla: Please give the length of the fields. Result: include lengths.
Result: remove section 5.4.3 ECDSA
Result: move to <xpath>...</xpath>, <xslt>...</xslt> Tra nsform syntax.
Strike: 5.6.4 Xpointer

NOON Lunch

1:00 PM Further discussions on Sections 2, 3, 4, and 5

IDREF

Reagle: there are a number of proposals and arguments to remove IDREF, and just go with a URI that permits fragment identifiers. So we have two options:

Stop using IDREFs and permit people to put arbitrary expressions (e.g., "#expression") in their URI, but note that if they want to do it wel l, they should do it in a transform.
Keep with what we have.

Schaad: Having IDREF allows us to following nodes within the document without having to use XPath. If IDREF is removed, then we will have to use XPath (as part of the URI or as a transform) to do envoloped/enveloping signatures.
Boyer: Thinks it is just as trivial to write a small profile of XPath to do the same job. (Disagreement)
Reagle: An argument in favor of abandoning our currect design is that the XML uri data type permits fragment identifiers, we've defined something that doesn't permit a fragment and this is awkward.
With XPath we know we have to do c14n before (and maybe after) the XPath transform if we want selectors of attributes to work consistently. Boyer raised the issue on the list of shouldn't we do the same thing for IDREF? Answer: Some XPath expressions might depending on ordering, so prior c14n will be important! However, IDREF has no expression that is dependent on attribute ordering, so doesn't need to c14n first.
Schaad: let's stay with what we have until we hear a compelling argument that we understand and agree with before we move away from what we have.
Reagle: what about the "clean-URI" type, no such thing. Result: Define our own 'clean-URI' XML datatype.

Transforms

Should we define a minimal transformation -- that removes the SignatureValue. No . The result is that if people want to do enveloped signatures, you are going to have to use an XPath filter (Rescorla: meaning that we might not have that many enveloped signatures, which isn't a bad thing probably.)
Do the signed Transforms mean "this is what I did to yield the target content that was digested" or "receiving applications MUST do this ordered set of transforms (and only this set) in order to create the target content that is digested and checked."

WG very uncomfortable with the latter as it places sender specified behaviors upon the receiver that might be ignored regardless. (Similar to problems related to "criticality" in other security applications. Hallam-Baker: jokes that this would permit people to replicate "criticality fields" by specifying transforms via some URI that the receiver might not understand, and consequently can't process the signature.)

Boyer wants to define a set of documents that when combined with a set of transforms yields the same target content (TC).

X --T1--> TC
X'--T1--> TC

but not where some other document the originator never intended, when combined with some other transform yield the same target content.

Y--T2-->TC

For example,
A, B, C --(Select second)-->B
C,A,B,Y--(Select third)-->B

(In particular, Boyer wants to ensure that the permitted/signed transforms can be exclusive, removing content from an existing document instead of adding to it.)

Straw poll: how many people want the signature to be valid even if the target content that is digested was not produced as exactly specified by the transforms -- but the end result and digest are obviously the same? Or to restate the question: how many people want this to be a statement of "this is what I did" instead of "this is what you must do."

Most want the semantic to be "this is what I did" and do not favor sender based requirements. Boyer want this to be a specification of what receiving applications MUST do. Reagle: option to write minority opinion as we move forward.

How do we achieve the closure feature with the present design?
- An attribute/bit to say you must follow transforms is not well liked.
- LaMacchia: create a different sort of Manifest that has this sort of applica tion behavior associated with it that is not part of the core standard.
- Reagle: I suspect even the present design will do what Boyer wants as no man in the middle can make an attack, and no third party will be fooled that when present ed with Y and T2 that the signer meant those. Yes, a receiver could fool himself that Y and T2 is good enough, but that's his business.
- Result: discuss more on list, but present design stays the same (though text should be cleaned up.) Those opposed can make a minority report as we move forward to la st call.

3:20 PM FAQ/Scenarios

Eastlake: FAQ/Scenarios document will be an important WG product, would be good if it could come out at the same time as the Syntax and Processing document. Begins walking the WG through Scenarios/FAQ.
Beginning of discussion, but people don't have a lot to say yet, prefer to read more and discuss on list.
Reagle: Please send comments by beginning of February and then we will begin populating it with actual instance examples.

4:30 PM Upcoming conference calls and meetings

Eastlake: Next meeting at IETF meeting in Australia, many WG members will not be able to make it. Result: only schedule one slot instead of two as we have in the past. .
Reagle: but it may be a good outreach/comment opportunity to that part of the world. We will probably need another FTF to deal with Last Call comments that is closer. Will organize that FTF once we go to Last Call.
Eastlake: Move teleconferences to 1pm on Thursdays. Plan on having the first on the 3rd of February. Schedule for two months until the IETF meeting, then decide if/when subsequent calls will occur.