OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: My comments on 'Errata on Core'


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.

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.

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.

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.

Section 5.1:

Already fixed, I assume.

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


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]