RE: Algorithm Specifiction/Parameters/Value

More opinions...

    A.  Don't care

    B.  There are actually more options that this.  Types can be specified
in a generic fashion (type=urn:dsig:Integer) or in an algorithm-specific
fashion (type=urn:ietf-org:hmac-outputlength).  I prefer algorithm-specific
types, because then the types get defined as they are required.  Using
generic types means that we have to define a set of generic types (more
work!) that may or may not be sufficient for new algorithms.

I prefer B.3 with algorithm-specific types.

    C.  Definitely C.0.  I feel quite strongly about this one.  In places
where we are precisely defining what goes into an element, such as the
SignatureValue and DigestValue fields, there is no reason not to fix the
encoding to, say, base64.  If we allow multiple encodings we increase the
interoperability challenge with no offsetting benefit whatsoever.  I have no
problem with fixing the encoding on an algorithm-specific basis, so that if
there is some much better encoding for some new algorithm, we just fix the
encoding for that algorithm to that other encoding.

    D.  I'm not sure what is intended here.  The signature algorithm is
placed within the SignedInfo, and the signature value is elsewhere.  I
oppose

  <SignedInfo>
    ...
    <Signature><Algorithm>...</Algorithm></Signature>
    ...
  </SignedInfo>
  <Signature><Value>...</Value></Signature>

since the first <Signature/> can only contain the algorithm and the second
<Signature/> can only contain the value (different semantics for the same
element name).  I prefer
    
  <SignedInfo>
    ...
    <SignatureAlgorithm>...</SignatureAlgorithm>
    ...
  </SignedInfo>
  <SignatureValue>...</SignatureValue>

and for symmetry, I think we should do the same thing with Digest (have two
different elements, DigestAlgorithm and DigestValue).

    E.  I would say E.0, with the same motivation as for C.0.

    F.  My choice for D makes this question only apply to transformations.
I would say that anything one might call a Value in a transformation could
(and should) equally well be called a parameter.

-Mark Bartel
JetForm

-----Original Message-----
From: dee3@us.ibm.com
To: w3c-ietf-xmldsig@w3.org
Sent: 10/14/99 9:32 PM
Subject: Algorithm Specifiction/Parameters/Value

ALGORITHM SPECIFICATION / PARAMETERS / VALUE

A. Algorithm Specification
1.   As attribute <Foo Algorithm="urn:...">...</Foo>
2.   As element <Foo><Algorithm>urn:...</Algorithm>...</Foo>
B. Algorithm Parameters (for Transforms & possibly others)
1.   Just use element content <Foo>...</Foo>
2.   Use typed elements <Foo><Integer>1</Integer></Foo>
3.   Use Parameter element with URI type attribute
        <Foo><Parameter type="urn:...">1</Parameter></Foo>
4.   Use Parameter element with Type & Value elements
        <Foo><Parameter><Type>urn:...</Type><Value>1</Value>
          </Parameter></Foo>
C. Algorithm Parameter Encodings
0.   Use a fixed encoding, works for any B
1.   Use an attribute, works for any B option, example
        <Foo><Parameter type="urn:..." encoding="urn:...">
        93kv0w=</Parameter></Foo>
2.   Use an element, works only for B.4
        <Foo><Parameter><Type>urn:...</Type>
        <Encoding>urn:...</Encoding><Value>93kv0w=</Value>
        </Parameter></Foo>
D. Algorithm Output Value (for Digest & Signature)
1.   Just use element content <Foo>...</Foo>
2.   Use Value element <Foo><Value>...</Value></Foo>
E. Algorithm Output Encodings
     0. Use a fixed encoding, works for any D option
1.   Use an attribute, works for any D option, for example
        <Foo><Value encoding="urn:...">...</Value></Foo>
2.   Use an element, works only for D.2
        <Foo><Encoding>urn:...</Encoding><Value>...</Value></Foo>
F. Parameters and Value
     If there are cases where an algorithm has both parameters
     and a value, which I think is reasonable, this argues
     against B.1 and D.1.

NOTE:  A simple decision that URI's appear at attributes would
tend to select A.1 and B.3 and eliminate C.2 and E.2.  Similarly
a decision that URI's appear as element content would tend to
select A.2 and B.4 and eliminate C.1 and E.1.



Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

Received on Friday, 15 October 1999 16:16:09 UTC