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