AW: [dss-x] First set of comments on profile on comprehensive report for multisignature

["Huehnlein, Detlef" <Detlef.Huehnlein@secunet.com>]

Hallo Juan Carlos,

thank you very much for your comments. You will find some feedback /  
questions below. 

> 
> 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?

Yes, but it might be worthwhile to discuss this issue. 
The general motivation for this sentence was that
the information contained in 

•	<VerifyManifestResults> (see [DSSCore], § 4.5.1)
•	<ProcessingDetails> (see [DSSCore], § 4.5.5)
•	<SigningTimeInfo> (see [DSSCore], § 4.5.6)
•	<SignerIdentity> (see [DSSCore], § 4.5.7)

is also contained in the advanced verification report and
should not be doubled. Concerning the other elements

•	<DocumentWithSignature>, <UpdatedSignature> (see [DSSCore], § 4.5.8)
•	<TransformedDocument> (see [DSSCore], § 4.5.9)
•	<DocumentWithSignature>, <TimestampedSignature> (see [DSSCore], § 4.5.10)

we could discuss whether we should leave the sentence as it is
or whether we should provide a solution to handle those cases in the multi-signature-setting.
As it seems that the typical use cases, which would demand a solution for the
latter problem (updating a batch of signatures) are also related to long term
archiving issues, it might be interesting to discuss this new topic along with
the said problem.


> 
> 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)?.


Not to check the certificate path here would mean that the 
certificate of the signatory is - temporarily, just for the purpose of 
verifying the particulary signature - treated as it would be implicitely trusted and 
hence there are no further certificates in the path and there 
will be no status check necessary. This option would only
be used, if the validity of the certificate (path) is guaranteed 
by other means and performance is important.   

> 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?

Yes, careless use of this option could be dangerous. It would be 
useful, if the validity of the certificate (path) is guaranteed 
by other means and performance is important. 

Would you prefer to drop this option?  

> 
> 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?. 

Yes, this was the idea. If this option would be set, the client
could tell the server that it should realize the sloppy "policy" not to 
care about the cryptographic suitability of the applied algorithms 
at the given point in time, because it might not be clearly defined in 
a particular usage scenario what kind of algorithms are suitable (at a given time) 
and which ones are not. This might be the case if a client in one (legal) domain 
(e.g. country) asks a server in different domain to verify the signature. 

> 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…

A DSS server will in general not be able to decide, whether a given signature
is appropriate in a given (legal) application context. But the server
would be able to check, whether the algorithm of a given signature
is among a defined set of suitable algorithms (with respect to the policy of the DSS server, which
might be defined by local juristiction) at the relevant point in time
or whether the signature is produced with algorithms, which are not 
up to date anymore.   

> 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.

Would this imply that it will be entirely left to the policy of the
server, whether the suitability of the algorithms will be checked?
Is there any possibility for the client to see whether the server
checks whether the algorithms are up to date?

Did I understand your suggestion (in comment #10) right, that the option should be 
dropped, but the server may (or may not) included the result of the algorithm
check in the verification report?

> 
> 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.

Using this flag the client would only indicate that the 
server should include the current time at which the verification report 
is produced. Would you prefer to drop this option and
just always include the <dss:VerificationTimeInfo> in the report
(see Comment #6)?

> 
> 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.

OK.

> 
> 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?

OK. The intention here was to use the same structures as in the core. 
I'm not sure, whether I remember right, but wasn't the reference in the core to 
SAML v1.0 something which should be changed sooner or later anyways?
Does anybody remember the status and plans for this issue?

> 
> 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?

Yes, while it is no real contradiction (l. 139 states SHOULD NOT and l. 303 states MAY) 
I will reconsider this point, as soon as comment #1 is settled. 

> 
> 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.

Yes, this was the plan. 

> 
> - 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.

Wouldn't the <SignatureValue> be even sufficient to uniquely identify 
a specific signature (in any real world signature format)? In this case 
we probably should (only?) use this option as identifier. This would have 
the advantage that even a human user would be able to see what signature 
is referenced. The only problem would be that the size of the verification report would 
grow with the size of the <SignatureValue>-element. 
Or would you suggest to have a sequence of optional elements 
(incl. FieldName to support PDF-signatures) and the DSS server may choose 
whatever subset he thinks is appropriate? 

> 
> 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

OK. 

> 
> Comment#11:
> 
> Line 442 “which” => “whose”.

OK.

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

OK.

> 
> 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.
>

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

Thank you very much for your input. I'm looking forward to receiving 
more input on the rest of the document and the questions above such 
that I am able to could provide an update of the working draft. 

Best regards,
        Detlef  

> 
> 
> Regards
> 
> Juan Carlos.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php 
> 
>