Re: [dss] Comments on DSS XAdES profile

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

Nick,

Thanks for your comments.
See my reactions below.

Now, concerning to concrete profiles, as we discussed yesterday, 
there would initially be two concrete profiles: one for XAdES and the other
for TS 101733, unless somebody else could identify others.

Regards and thanks

Juan Carlos.

At 22:27 08/07/2004 +0100, Nick Pope wrote:
>Juan Carlos,
>
>I offer the following comments on the XAdES profile:
>
>1) Section 2 and elsewhere
>
>The full description "Predefined advanced electronic signature forms as
>defined in [XAdES] and [TS 101 733]" could be used in the first 2nd level
>bullet item below "sign request" and "verify request" in section 2 to make
>it clearer what "predefined" means.
>
OK

>2) 5.1.2.1 3rd Para
>
>I suggest after "Acceptable" add "predefined"

OK
>
>3) 5.1.4 UpdateSignature
>
>Where is this element defined?  Should this this be an optional input?
>
Yes. I initially designed as a new OptionalInput. Forgot to put it in the
suitable section.
Thanks.

>Is this something that should be in the Core?

Well, not initially.
>
>On the editorial issues
>
>1. OK as is - I think it is reasonable to always have the form of signature
>registered through an identifier
>
As we have commented sometimes, it may happen that for a specific form
there may
be different combinations of properties. If we stick with this way of
requesting forms, how
could we manage these different combinations?. Could we dictate rules like
the ones
expressed below?:

1. Assign an URI for the form (no matter what combination of properties).
If a server receives this
UIR, then it generates the combination specified in its policy or other
configuration settings.

2. Assign one URI for each combination. If a server receives one of them,
then, if it is able to do so,
it generates the corresponding combination of properties.



>2. OK as is - same reason as above
>

>3. OK if there is a mechanism for controlling this.  How can the requestor
>signal what is expected?  Should this be something that can be controlled /
>indicated through the signature "form".

I am not sure of making this issue something on which the client should
express any
request. I mean, the client wants a signature that also protects the
signature, and this is what
is returned, in one way or the other: In other occassions we have left
things decided by the policy
or the configuration of the server. Do you see any use case where the
client would require to be
able to express any preference for one of the two structures?

>
>4. Already accepted
>
>5. OK As in current spec
>
>6 OK as is
>
>7 I would expect that the <xades:signingTime> would generally be used as the
>validation time but the profile should also allow validation against other
>times even though this may be the exception.

If I understand you, you seem to say that this <xades:SigningTime> should
be used as the time
for the verification of the signature. I agree that the profile should also
allow validate it
in other times. And in fact there is an element in the core for doing that.

>
>8 See earlier comment

I am not sure what this item has to do with the issue of SigningTime. I am
speaking of requesting
to the server the addition of new validation data to the signature without
validating it.

>
>9. Possible could leave counter signatures until understand requirement

OK
>
>10. Already accepted
>
>11. OK as is
>
>Nick
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>