RE: [dss] Comments on DSS XAdES profile

["Nick Pope" <pope@secstan.com>]

Juan Carlos,

See below (I have cut out all but discussion points):

> 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.
>
I agree


> >
> >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.
OK


> >
> >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.
>
I suppose that 1. is more flexible  as it allows implementors to use URI and
request additional as they feel appropriate.  So one further contimplation I
would go for this.

>
> >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?
>
Not at the moment.  So lets go with this.


> >
> >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.
>
Yes - If no other verification time is requested.


> >
> >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.
>
I think I was referring to the comment on UpdateSignature.


Nick