Re: [dss-x] Re: [DSS-X] comments to profile on individual reportingmulti-signatureverification

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

Dear Huehnlein,

Thank you very much for your message and xsd file.

It is indeed very interesting the level of detail that you have 
incorporated there.

I insert feedback on your comments below intermixed.

Despite this feedback let me first of all to make a general comment on 
how I see the whole issue.

In my view we may proceed in two different ways, each one has its pros 
and cons, but I would say that we should discuss which one we will follow.

1. First approach. We define two profiles.

    a. The first one consists in having two complementary profiles. The 
first one would be a profile that provides the basic functionality I 
mentioned in the proposal that I submmitted, maybe with some changes in 
the structure and/or punctual additions of what you propose in your 
profile (the mechanism for identifying the signature, for instanc, 
although I think that this deservers more discussion). But the core idea 
is that this profile would actually define containers for including 
there individual reports on each signature that the server has found in 
the verification request, no matter what the signature type was, CMS, 
plain XMLDSIG, XAdES, CAdES...., and without going beyond in terms of 
details on what the server did for actually arriving to the conclusion 
that the signature was valid or invalid.

    b. The second profile would actually go beyond that point: it could 
also be a profile defining structures that allow to report complete 
details of each piece of cryptographic material that the server has 
checked during the verification of the signature itself. This profile 
would incorporate most of teh material that appera in the xsd file that 
you circulated.

Way a Pros:

1. Having these two profiles, the service providers could claim 
adherence to the first profile, ie, provide individual reports on each 
signature and yet not need to provide all the details envisaged in your 
xsd file. Those services, whose environments require the provision of 
such a level of detail would claim adherence to both profiles and 
implement both. In summary, we give more freedom to service providers. 
My understanding is that if within one profile some part of the 
structure is optional, yet the service must be aware of its potential 
existance...

2. This would allow, in addition, that the second profile could be 
incorporated within environments where servers do not want to provide 
individual reports on each signature, but still want to give details on 
the verification process of one signature.

3. In summary, this would isolate two different althoug related 
problems: the problem of having more than one signature and reporting at 
a general level on the verification of each one from the problem of what 
details on the verification process the server provides to the client.

4. The xsd file includes quite a lot of references to AdES elements. If 
we define the two profiles mentioned above, we would separate the 
capability of reporting summaries of verification of individual 
signatures from the fact that the signatures may or may not have these 
properties, ie, from the fact that the signatures are or not AdES 
signatures.

Way a Cons:

1. There would be two profiles that need a certain degree of 
co-ordination in their development so that they may fit together.


Way b Pros:

1. No need to coordinate construction of two profiles.

Way b Cons:

1. Servers aiming at giving a very basic level of information on the 
verification of several signatures (ie, basically saying "valid" or 
"invalid" and few information more") should actually implement the whole 
unique profile for claiming adherence to the profile.

2. Servers aiming at only reporting on one signature with high degree of 
details should also implement the capability for reporting on more than 
one signature, even if they do not intend to do that.


As I think that the requirement document(s) strongly depend on which way 
we follow, I would suggest then to think about these two alternatives 
and try to reach an agreement on one (or maybe another one) and then 
proceed forward with the requirement document(s).

What do you think?

Below my feedback intermixed....

Juan Carlos.

Huehnlein, Detlef escribió:
>  Such a comprehensive verification report is 
> (in some Europen countries) required to be generated and archived for 
> electronic invoices. 
>
>   
This is certainly interesting. Looking at your xsd file, I think that we 
would get interesting comments from ETSI ESI as there are issues 
strongly related with AdES signatures.
>> 1. A new optional input in the <dss:VerificationRequest> 
>> requesting that if hte server finds more than one signature, 
>> it reports verification individually for each one.
>>     
>
> This could even be a default behaviour. Within the VerificationReport-structure,
> there is a general part (related to the request) and multiple (0..*) specific
> parts (related to the signed objects). 
>
>   
Mmmm... you mean that just because in the OtherProfiles element you 
mention this profile the server must understand that it may return the 
individual reports? It could be an option but one of the things that in 
the past we tried to keep was the Request-Response pairs in the 
OptionalInputs - OptionalOutputs, ie, we treated that for each 
optionalOutput there would be a corrsponding OptionalInput....we may 
talk of that.

>
>> 3. For <dss:VerificationResult> global Major results should 
>> globaly indicate whether there has been or not success.
>>    In the latter case, the client must look at the individual reports.
>>     
>
> It would be possible to specify a kind of detail-level, such that
> the lowest level would provide the same information as the current 
> verification in DSS. However the highest detail-level will provide a comprehensive
> verification report, which contains all information, which is gathered
> during the verification process. While this - e.g. in case of an advanced 
> electronic signature - might become a fairly complex structure, such a report
> is required in some scenarios (e.g. eInvoicing). 
>
>   
So the differences between the different approaches is that in the first 
one the least detail level is in one profile and the highest detail 
level is given through the usage of the second profile, while in the 
second approach there is only one profile serving for both purposes, 
with the pros and cons for each one...
>> 4. For <dss:VerificationResult> global Minor results have 
>> also been re-adjusted
>>
>>     
> I don't think that we would need to change any Major or Minor results.
> The VerificationReport structure could just be handed back in OptionalOutputs.
>
>   
Well, currently the  xsd you circulated  the VerificationSummary reports 
for each element actually identifies the element as valid invalid or 
indeterminate. What I am suggesting is that in order to allow clients 
actually know whether one given signature is or not valid by adding an 
element with Major and Minor elements, so that the client soft does not 
need to go through all the SignedObjectVerificationResult elements to 
conclude if the signature is valid or not.



>>   5.1 Each one of these elements will report details on how 
>> verification of one
>>   signature has gone.
>>     
>
> If one aims at supporting advanced electronic signatures, which
> may contain time stamps, (attribute) certificates and related 
> revocation information (OCSP or CRL), it would be a natural extension 
> (with only modest changes) to allow the verification of these structures 
> as well.
>
>   
Agree, it would be a natural extension....the issue here is if this 
comes in the same document (profile) or in another one.
>>   5.2 This element will include result major and minor for 
>> each signature.
>>
>>   5.3 This element will contain mechanisms for identifying 
>> the signature verified
>>   (and this is something on what I would like to get more 
>> ideas....you will see that
>>    I propose something but I would say that there might be 
>> other ways to do that).
>>     
>
> This element will contain some Identifier for the signed object.
> In case of a signature, this might be something similar to the
> SignaturePtr-element. 
>
>   
We certainly may talk of this SignaturePtr... I am not sure that it is 
always enough to identify any signature in a VerificationRequest...I 
have to think more but I would initially say that this is certainly one 
way more for identifying signatures....
>>   5.4 This element may incorporate any optional output giving 
>> details on a verified signature
>>   that have been defined in the DSSCore
>>     
>
> Yes. It seems to me that covering (CMS or XML) advanced electronic signatures
> would imply that everything (maybe apart from PGP-signatures?) is 
> covered. 
>
>   
And this could be the point where the two profiles, in case we go for 
way a) could be linked.
>>   5.5 Should allow the inclusion of further details on the 
>> verification process.
>>     
>
> In fact it could make sense to define a kind of detail-level, such 
> that one is able to control how detailled the verification report will 
> be.
>
> Please let me know what you think about the draft of the attached
> VerificationReport-structure. 
>
> Best regards,
>    Detlef
>
> --
> Dipl. Inform. (FH)
> Dr. rer. nat. Detlef Hühnlein
> Partner
> secunet Security Networks AG
> Sudetenstraße 16
> 96247 Michelau
> Telefon +49 9571 896479
> Mobil   +49 171  9754980
> detlef.huehnlein@secunet.com
> www.secunet.com
>