[1]IETF [2]W3C [3]XML Signature WG
[1] http://www.ietf.org/
[2] http://www.w3.org/
[3] https://www.w3.org/tmp/Overview.html
99-October-07
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [[4]text]
[4] http://www.w3.org/Signature/Minutes/991007-tele,text
Participants
* Donald Eastlake 3rd, IBM
* Joseph Reagle, W3C
* Mark Bartel, JetForm
* John Boyer, UWI
* David Solo, Citigroup
* Ed Simon , Entrust Technologies Inc.
* Todd Vincent, GSU
Minutes
Review of Outstanding Action Items
* [DEL: ACTION Bartel: send AlgID by Monday :DEL]
* [DEL: ACTION Eastlake: propose something on URI and MIME
types. WG: discuss. :DEL]
* [DEL: ACTION Reagle: finish edits to RD and send on its
way. :DEL]
* [DEL: ACTION Reagle: check [5]RFC2119 to see if it defines
mandatory, recommended, should. :DEL]
http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt
* [DEL: ACTION Reagle: reflect these minutes in document and
post by end of Friday. :DEL]
* ACTION Fox: do we need to add a nonce? Barb still has it on
her queue, experts are travelling.
* ACTION Brown: send requirements and syntax comments to
list. Sent requirement comments. Still needs to send syntax
comments.
* [DEL: ACTION Reagle: Check with everything capitalized,
bounce off Ralph. Evidently some scripting languages don't
like '_'. We should probably just keep what we have and
move on. :DEL]
Algorithms
* Mark has added text to sections 7, are people generally ok
with this? Yes.
* Should we stop saying non-repudiation? People seem
comfortable speaking of it.
* Remove MD5? Agreed. Also tweak references to AES.
Syntax (Jim Schaad and Barbara Fox)
1. All IETF drafts now require a patent statement a the top of
the draft. Such a statement should be added to the
document.
ACTION Reagle: Add link in W3C status to patent statements
now on Web site. We'll add the IETF disclosure to the IETF
version when generated.
2. Example in section 2.0 should be a DSS example as this is
the mandatory example. I assume that at some point this
will be come a verifiable example as well.
WG Agrees.. ACTION Solo: will change example, and we will
hopefully have a verifiable example at some point.
3. Section 3.0 -- In the ATTLIST SignatureValue is misspelled.
ACTION Reagle Fix.
4. Section 3.0 -- SignatureValue is no longer an empty-tag
element.
ACTION Reagle Fix.
5. Section 3.0 - Insert reference to Base64.
ACTION Reagle Fix.
6. Based on input from mailing list -- please change c14nAlg
as an element to fully spelled out.
ACTION Reagle: move from c14n to canonicalization. In the
XML canonicalization. Text we can keep for the time being.
Bartel would like Alg spelled out too. No agreement -- but
no opposition either really.
7. Section 4.3.1 - I know that we were one of the people who
wanted to make the location optional. What we had in mind
was the following statement: "If the location is omitted,
then the content being signed is the first Object in the
immediate surrounding Signature."
Solo's scenario is closer to what Don sent than the
Fox/Schaad. Clarify: if omitted assumed that the
application knows what to do.
8. Section 4.3.5 - This is no longer an empty-element tag.
ACTION Reagle: fix.
9. Section 5.0 -- there are two DTD definitions for Object
here.
ACTION Reagle: delete second one.
10. Section 6.0 -- The DTD appears incorrect. ANY can only
occur once and not with any of the current defined items.
Should ANY be inside of the *?
Agreed. Don says one can rewrite to do it right. ACTION
Reagle: fix it. Solo: This section is presently heavily
underspecified. Add a comment that it requires significant
additional work.
11. Section 7.1 -- Please remove all references to MD5. We
should not be pushing the older potentially bad hash
algorithms (after all MD2 is not here either). SHA1 will
cover our needs until the AES hash algorithm comes along
Agree: remove MD5.
Agree: remove AES from table, include sentence that we
expect additional digest algorithms can be used in the
future.
ACTION Reagle: Fix the table.
Eastlake: suggests changing ECDSA to optional.
David will add ANSI reference if he can find it.
12. Please remove references to AES algorithms. There will be a
block cipher finalist next year and there is no hash yet.
13. Section 8.1
- Step 2 - "Calculate the digest over the result of the
transformations."
- Step 3 - formatting on objectreference is incorrect.
- Step 4 - space between SignedInfo/Element
- Step 5 - references step d
- Step f) - should be moved to step 6.
14. Section 8.2
- Step 6 - references steps c and d.
- Remove last sentence of step 6 -- this would go to
description of canonicazation.
ACTION Solo: clarify section 8.
15. We assume that the editorial comments will be removed in
the process of creating an IETF I-D.
Action REAGLE: Move most comments to open issues section.
Solo: Transformation Section:
* Presently underspecified. Agreed Applied in the order in
which they appear. Can you have more than one of a
particular type (multiple encodings).
* Need to specify defaults: 4.1/4.3.3 alludes to defaults.
4.1 is probably minimal. For signed_info, let's require the
element, and people can specify whatever they want. minimal
as the default if not present. If the element is not
present, no transformation occurs.
* remove third bullet in 7.5.2 mark and ed will propose
alternative text.
* do we include or exclude the object in the signature.
continue with excluding such that the signature passes for
an object or an external resource. ACTION Solo: reflect in
his edit.
* Reagle: what requirements will we have for the
transformation:
* Ed says REQUIRED XSLT, perhaps recommended. Though can see
that it might be a lot for some applications.
* John says REQUIRED XPath, perhaps recommended + algorithm.
* Eastlake, says RECOMMENDED (XSLT | XPath)
* If XPath, we need to have an algorithm (then encode).
ACTION Boyer: will write up a proposal for 7.6 using
"Recommended" term.