First set of comments on profile on comprehensive report for multisignature

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

Dear Detlef and all,

Below follow some comments on the profile for comprehensive signature 
verification report draft:

Comment#1:

Line 138: the way it reads seems that when one client requests advanced 
verification, the IndividualSignatureReport does not allow for 
<DocumentWIthSignature>, <TransformedDocument>, <UpdatedSignature>, etc. 
Is this reading right?

Comment#2:

Line 182 reads: “This option specifies, whether the certificate path 
should be checked or not”. I do not understand what “cert path check” 
means in this context. Does it mean to retrieve the cert path?, does it 
mean to check the status of certificates in the cert path (if so, please 
see my next comment)?.

Comment#3:

Line 185 reads: “This option specifies, whether the certificate status 
should be checked or not”. Then it says that if this option is set to 
false a warning should be returned. First I guess that not only the 
status of one certificate (singular) but the status of all the 
certificates in the certpath is required. In addition to that, If the 
status of the certificates in the cert path is not checked, in fact the 
verification of the signature is not performed (well, the cryptographic 
private key / public key yes, but the server can not say whether the 
signature is valid or not). Is not this dangerous?. Is the rationale for 
this that this protocol allows to request only the cryptographic check 
of a signature, and if so, are there relevant use cases for this?

Comment#4:

Line 197 reads: “This option specifies, whether the used 
algorithms….shoulc be checked for appropiateness with respect to the 
relevant point in time”. This means that if this option is set to false 
the server will not check whether the algorithms used are appropriate?. 
In addition to that, I would say that the appropiateness of algorithms 
are not only a matter of point in time, but of other factors that may be 
as relevant as this one: application, for instance…The core specifies 
that the servers operate under a certain set of rules/policies; 
signature policies also constraint the algorithms to be used, so I would 
suggest to delete this option.

Comment#5:

Line 226 <IncludeCurrentTime>. I do not understand the semantics of this 
element; we have an optional input in the core for requesting 
verification at a certain point of time (including the current time), 
and an optional input for requesting that the server returns information 
on the verification time. I would say that these two options should 
satisfy any requirements on imposing the verification time to the server 
and on reporting of such a verification time.

Comment#6:

Lines 270 to 276: <CurrentTime> and <VerificationTimeInfo>. Please use a 
reference to the <dss:VerificationTimeInfo> element defined in the core 
instead these two new elements: it actually contains both: the 
verification time (what the document calls <CurrentTime>, and 
information related to time-stamps, etc.). Use new elements would cause 
confusion and misunderstandings.

Comment#7:

Line 277: <VerifierIdentity>. I propose not to restrict this element to 
be a SAML name. Just on the fly I am able to think in a certificate 
identifier (the verifier actually may have a certificate, which contains 
identity information).: What about making a sequence of optional 
elements including the saml name, a certificate identifier and any other 
type of information?

Comment#8:

Line 303 – 304: here the text reads that <Details> may contain any other 
signature specific optional output defined in DSSCore. Is this not in 
contradiction with what it is written in line 139?

Comment#9:

Line 316 and following: definition of SignatureIdentifierType. Some 
comments here:

- DigestAlgValue: the text starting in line 329 says that the input may 
be the whole <ds:Signature> element. If this is what we want, then the 
element must be completed with an indication of the canonicalization 
algorithm used for passing from a node set to an octet stream.

- I also envisage other alternatives for identifying the signature: 
<SignatureValue> in XMLDSIG (or equivalent in CMS) complemented with the 
KeyInfo (or signing certificate in CMS) would also serve for identifying 
the signature the report is referring to. Please add this alternative.

Comment#10:

Line 410: As I said, I would suppress the <CheckAlgorithms> option, but 
this does not mean that this element may not appear in the output as a 
way of saying that the algorithms used are the suitable ones

Comment#11:

Line 442 “which” => “whose”.

Comment#12:

Line 468: is “TrustOrigin” the same as “TrustAnchor” and if so is not 
this one more widely used than the first one?

Comment#13:

Line 490: I guess that the minOccurs value should be “0”, as below in 
line 513 the text says that under certain circumstances, <ChainingOK> 
element should be omitted.

I am sorry, I have to leave now for a Master Thesis presentation…. More 
comments will come on the rest of the document.



Regards

Juan Carlos.