Re: [dss] ISSUE#4: SIGNATUREOPTIONS (SIGN REQUEST DISCUSSION)

[Trevor Perrin <trevp@trevp.net>]

At 11:33 AM 9/9/2003 +0200, Juan Carlos Cruellas wrote:





>ISSUE#3: SignatureOptions
>
>Short description: You define the SignatureOptions element as a root child
>element.
>And you have suppressed the canonicalizationMethod element that was present
>in my proposal.
>
>
>
>My comments:
>
>         1.I generaly prefer to stick to the initial design in the f2f 
> meeting, ie,
>         to have an Options root child element and then to include there
>         all the different types of options we may need. So I propose to
>         put this element as child of an Options root child element.
>
>         2. You propose to include within SignatureOptions the indication
>         of what properties (and optionally their values) the requester can
>         instruct the server to use. I have to think about. I guess that I
>         could live with that....
>
>         3. I propose to add again the CanonicalizationMethod  and 
> SignatureMethod
>(both
>         of them could be optional just for dealing with the
>         case of a profile already definining them). Justification: the 
> requester
>may be
>         interested by any reason to instruct the server which 
> canonicalization
>algorithm
>         it has to use and what signing algorithms to use...And in the 
> simplest
>case, they
>         will not appear...

These are both low-level details that weren't anticipated in the 
requirements doc, and which I don't see much use for.

CanonicalizationMethod is just for canonicalizing ds:SignedInfo.  Why would 
the client care how this is done?

As for SignatureMethod, wouldn't the server know on its own which 
SignatureMethod to use with different key types?  Why would the client want 
to control this?

Trevor