[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [dss-x] Some issues with the current standards
Hallo Juan Carlos, > I appologize for not reacting before to your email... no problem. > > 1. Return of at most one SignatureObject in SignResponse (core, > > section 3.2) > > > This definition (without maxOccurs="unbounded") would preclude the > > simplest (and hence a widely used) bulk signature use case in which > > somebody wants to generate some sort of enveloping signature for a > > large number of (small) documents, which are all provided > in a single SignRequest. > > > > Why is the current restriction necessary? Would it be > possible to add > > the maxOccurs="unbounded" during the maintainence process? > > My recollection of this was that it was actually discussed > whether the protocol would allow the generation of one or > more than one signature and it was decided to restrict the > protocol to generate only one signature. In addition to that > I would say that there are no means in the protocol for > indicating what documents should be signed by one signature > or the other, so if I have correctly understood you the issue > would go farther than only include a maxOccurs="unbounded" attribute. In my point of view we may distinguish the following cases for the SignResponse: 1. Only allow only one SignatureObject This is how it is currently specified in the core. 2. Allow multiple SignatureObjects of one specific signature-type This is could be reached by inserting the maxOccurs="unbounded" attribute and moving the related restrictions (e.g. "The <SignRequest> MUST contain either a single <Document> ..." on line 935) to profiles (if necessary, or remove them at all). 3. Allow multiple SignatureObjects of multiple signature-types This would certainly go further than just inserting the maxOccurs-Attribute. - Option #1 corresponds to the current state of the core specification, but it precludes the support of important use cases with DSS at all (e.g. batch signature, long term archiving processes which produce n evidence records (cf. RFC4998) for n (hash values of) documents etc.). - Option #2 would allow to support those use cases and only requires moderate changes to the core specification. - Option #3 would be nice, but would require major changes to the core specification. Considering the three cases it seems to me that the "cost/benefit ratio" tends to be optimal in option #2 and hence we should think about whether we should introduce these changes during the maintainance process. > > > > > 2. Possible conflict between AdES- and Timestamping-Profile? > > ------------------------------------------------------------ > > In section 3.3.2.1 and 3.4.1.2 of > > > http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0- > > os.pdf it is stated that the <SignatureObject>-element "SHALL NOT > > contain a dss:TimeStamp-element as a child". > > > > This stipulation implies that it is impossible that there > is a profile > > or an implementation, which satisfies the AdES _and_ the > > Timestamping-Profile > http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-timesta mping-spec-v1.0-os.pdf . > > > > Why is the current restriction necessary? Would it be possible to > > change the "SHALL NOT" during the maintainence process? > > Maybe there is a certain use case where the adherence to both > profiles is required, but in my mind, they are quite disjoint > profiles: one serves for generating and/or verifying AdES > signatures (that may include timestamps, that is for sure) > and from this I conclude that the relevant objects are > signatures, and the time-stamping profile is for requesting > and / or verifying time-stamps,.... am I missing some > specific use cases where this adherence to both profiles is a > requirement? From an abstract point of view (advanced electronic) signatures and time stamps are similar - both produce a signed object - and hence there may be implementations, which allow to request signatures or time stamps just by specifying the appropriate SignatureType, which defines the format of the signed object. In general we should try to keep the interference of the various profiles to a minimum such that one is able to support different profiles in some implementation (or a comprehensive profile). With the eCard-API-Framework, which is currently specified on behalf of the German government for example we aim at providing a comprehensive framework, which allows to produce or request and verify signatures or time stamps. For this purpose it would be good if we could refer to the different existing profiles and "just combine them" in a comprehensive profile / implementation. However this is not possible with the current AdES-profile, as it precludes that an implementation, which supports this profile may as well be used to produce / request time stamps. Are there any further implications, if we would change the "SHALL NOT" to a more open stipulation, which would allow an implementation to support both profiles? > > > > 3. The <IncludeEContent> element (cf. core, section 3.5.7) does not > > seem to be defined in the schema. Hence we should probably add > > <xs:element name="IncludeEContent"/> during the > maintainance process. > > > I think that you are right. Stefan, I am not sure who was in > charge of dealing with the list of issues for maintenance of > the core.... do you remember this? OK. > > > 4. The UseVerificationTime-element is currently defined in > the schema > > as <xs:element name="UseVerificationTime"/>, but it should > most likely > > be defined as <xs:element name="UseVerificationTime" > > type="dss:UseVerificationTimeType" />. > > I would also say that you are right....as above Stefan.... OK. There is yet another issue in the core, which seems to provide a restriction, which might not be absolutely necessary: The Result-element is defined in Section 2.6 of the core and it may contain (up to (!) one) element ResultMinor: <xs:element name="ResultMinor" type="xs:anyURI" minOccurs="0"/> If the ResultMajor would indicate a warning, which indicates that the general result is ok, but there are (possible multiple) issues which should be considered further, it would be nice if it would be possible to allow multiple ResultMinor-elements, which correspond to individual warning codes. When verifying a signature for example there may be multiple reasons, which produce an individual warning (e.g. that some checks were not performed) and it would be good, if these warnings could be communicated in multiple ResultMinor-URIs. Do you think that it would be possible to allow multiple ResultMinor-URIs? ... at least in some profile? Best regards, Detlef
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]