Ross wrote:
ess-09.txt:
2.3, second paragraph: I'm unhappy with the two consecutive sentences which
say that if two verified signatures conflict, a signature must not be
generated, but a signature should be generated if any signature verifies (or
'validates') and another doesn't because you don't recognize the algorithm.
That's not what they say, I believe. They say if two *receiptRequest*
attributes in a SignedData conflict, don't send back a receipt. If you
can't validate a signature due to not knowing a particular algorithm, keep
going.
First, the paragraph (in ess-09):
Before processing a receiptRequest signedAttribute, the receiving agent
MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a receiptRequest
attribute that has not been verified. Because all receiptRequest
attributes in a SignedData object must be identical, the receiving
application fully processes (as described in the following paragraphs)
the first receiptRequest attribute that it encounters in a SignerInfo
that it verifies, and it then ensures that all other receiptRequest
attributes in signerInfos that it verifies are identical to the first
one encountered. If there are verified ReceiptRequest attributes which
conflict, then the processing software MUST NOT return any signed
receipt. A signed receipt SHOULD be returned if any signerInfo
containing a receiptRequest attribute can be validated, even if other
signerInfos containing the same receiptRequest attribute cannot be
validated because they are signed using an algorithm not supported by
the receiving agent.
First, I'd like to propose 'recipient' for the list of terms whose use
should be regulated:) The problem is that what the final sentence means,
is that a signed receipt should be returned if any receiptRequest
verifies, under the restriction of the preceding sentence. In other
words, the final sentence doesn't stand on its own. And it doesn't say
anything different than the second sentence of the paragraph, it just
gives a reason why not processing a receiptRequest may not be an
'"error" error'.
4.2.3.2: I'm not sure this flowchart-like process will work.
To shorten the path, what I mean by this is that the words in 4.2 say
that we determine the outer signed data by recursing through the nested
signatures until we find something we like, and that if we don't find
one, we treat the _original_ message as the outer signed data. This
isn't the sort of algorithm that I think can be represented in
flowcharts, without some sort of explicit variable storage, if you see
what I mean.
Andrew.