Re: [dss-x] My comments on 'Errata on Core'

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

Dear all,

Intermixed below my reactions to Andreas' remarks

Regards
Juan Carlos.
El 30/10/16 a las 22:12, Andreas Kuehne escribió:
> Hi all,
>
>
> here are my comments on the Errata document.
>
> The first two sections are agreed upon, I assume.
>
> Section 3.1.1:
>
> I'm not sure that I get the problem right. The @URIs of the
> ds:References correlate to the RefURI of the input documents. Multiple
> input documents result in a set of ds:References.
I remember that I also read this comment and from my point of view there 
is no problem. Andreas is right when it mentions the correlation between 
RefURI and the URI attributes.
> Section 4.1.1:
>
> A bit too tricky for the core I would guess. The request is plausible
> but I may introduce complexity I would like to be addressed in a
> specific profile, not in the core. Probably it wouldn't be sufficient to
> require one element to be present but a set of elements. Or an
> alternative set of elements ... and the generic 'MgmtData' will need
> special care to be taken! And we would need to define some type of error
> response. I would prefer to keep it off the core.
Fully agree with Andreas.

> Section 4.2.1:
>
> I don't want to import with this design flaw into the core! It's so PDF
> specific, keep it e.g. in the PAdES profile.
 It seems complicated to me to include this feature in a server.
> Section 4.3.1:
>
> Dtmo the selection of a key of set of keys should be defined by the
> usage context of the DSS endpoint. This may be done by the user but in a
> user friendly manner. The KeyInfo structure is not fit for this.
>
> A response set will become invalid in an undetermined period of time (
> e.g. by key expiry, key renewal). Introducing additional complexities on
> the user side.
>
> The enumeration of available keys is critical from the security point of
> view.
>
> Moreover the management of the available keys is the primary duty of a
> signing server. But this is already weakened by the KeySelector. What
> should be filled in here when we don't tell which keys are available? My
> proposal would be: drop both, this enumeration request and the KeySelector.
I would suggest to drop the suggestion but not the KeySelector....To my 
understanding this KeySelector could help the server to decide among 
different keys that could have been assigned to a certain user....isn't it?
> Section 5.1:
>
> Already fixed, I assume.
I think so
> Section 5.2:
>
> The Verification profile is already dealing with both versions of SAML.
> This could be applied to the core, too. ut my recommendation would be:
> Uswe SAML 2.0 only!
>
>
> Greetings,
>
>
> Andreas