[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Re: [DSS-X] comments to profile on individual reportingmulti-signatureverification
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]