San Jose [1]XML Signature Notes [2]ascii]
[1] http://www.w3.org/Signature/
[2] http://www.w3.org/Signature/Minutes/SanJose/Overview.html,text
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
[3]Petteri Stenius: RPX Signature, Implementation of an XML
Signature component [Slides]
[3] http://www.w3.org/Signature/Minutes/SanJose/stenius.html
* 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!
[4]Ed Simon, XSLT and XMLDSIG engines.
[4] http://www.w3.org/Signature/Minutes/SanJose/simon/presentation.html
* 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:
1. Defer digest validation
2. 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 ..., ... 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:
1. 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.
2. 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 [5]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.
[5] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0050.html
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.