[The status of these issue will be addressed in tomorrow's author call.]
Objecttags in the digest. continue with excluding such that the signature passes for an object or an external resource. ACTION Solo: reflect in his edit.
KeyInfo] is presently heavily under specified. Add a comment that it requires significant additional work. ACTION Solo: will add ANSI reference if he can find it.
Signature Syntax & Processing draft questions:
Sentiment on call is AGAINST having a general
Value element but instead
DigestValue elements that (of course
for signature but also for digest) are not nested inside the SigntureXxx or DigestXxx
Mark agrees with David's present sort of syntax described above.
On parameters to functions, sentiment favored a
Parameter element with a
URI attribute, algorithm specific in most cases. On having an
Parameter, most felt that the encoding could be fixed for a
particular Algorithm and parameter type.
Norman, people should be able to define an encoding, but we shouldn't enforce it on people. (optionally optional) That is, while an encoding attribute can syntactically be present, only algorithms that need that flexibility would pay attention to it.
ACTION: Eastlake will represent the position on the list.
Eastlake: Remove the syntactical "null" but if it isn't present, then don't touch the bytes. Sentiment FOR dropping Null but want very clear language.
something needs to have content in it, then it must be an element. Also attributes get
white space normalized in certain circumstances. URI could always be placed as an
No disagreement with placing things which are always syntactically IDs, IDREFs, URIs, XLinks, or MIME types in attributes.
Need more thought on how to deal with something (data type) that might be a MIME type or URI. These are distinguishable (scan for / or :, if you get a / first it's a MIME time, a : first, it's a URI) and syntactically fine as attribute values but it is a bit messy.
Transformelement or multiple Generic/Canonicalize/XSLT/etc. elements?
advantage of different elements is that different attribute defaults could be specified
for them; however, people favored a single
Transform element, for simplicity
and uniformity, which has a
Type attribute to indicate what algorithm it is
and optionally additional parameters.
Reagle wants the ability for others to include externally qualified-name elements so that it will be extensible.
Eastlake: will put options on list to the degree that transforms are passed along.
Norman: (only person on con call supporting type data passed along the transformation chain, for flexibility for runtime determined types, generic type dependent algorithms.) Further support for that proposal will come from people on the list.
Eastlake: does anyone object to type/charset info as option attribute input to algorithm? This also allows use of generic type dependent algorithms but with static type input. (no objection)
Eastlake: This section needs substantial more work and some decisions. For instance, should we have information that identifies the recipient?
Since the entire element is optional, there was a question as to whether any particular
content could be mandatory. People leaned towards making support of an opaque key
identifier mandatory if
KeyInfo is implemented.
Making X.509 certificates or anything else requiring ASN.1 mandatory was reject but use of such certificates is so common that an optional standard interoperable syntax for including them needs to be specified.
Allowing recipient identification information not required for key agreement in
was rejected. If desired, it should be elsewhere, perhaps in some
however, since user specified
KeyInfo content elements will be permitted,
someone can do this if they really want.
Fox: will volunteer to write a paragraph on some of this.
WG: this is a tricky issue, we don't want to place key info and cert issues on the critical path.
Eastlake: we probably need to work on
KeyInfo for a while, talk about it,
and do what we can in the time given.
Don't really mean "Attribute"s in XML sense but signature properties like signing time or serial number of crypto hardware used. Must pick a different name like Properties...
WG continues to agree to place these things in the content of an
tag. Create an auxillary syntax part of the document where we can place these things.
Some objections to this term. "Technical non-repudiation" suggested to avoid possible confusion with legal, business, etc., uses of the term.
Boyer: Suggest "Author Authentication"
Not resolved but lead to a discussion of having definitions in Syntax document. Those on call favor definitions at the end, generally opposed to having them at the beginning, and perhaps neutral on having them in sequence when the word is first used.
ACTION: Reagle send Eastlake minutes. Eastlake will augment and send back out.
ACTION: Fox will send paragraph on
KeyInfo to Eastlake.
ACTION: Todd will send his rough definitions to the list.
ACTION: Authors will call each other at 11 tomorrow to generate a last minute draft.