RE: [dss] Re: <Result>/<ResultMinor> more values vs appropriate modelling [Action 05-11-28-04]

["Nick Pope" <pope@secstan.com>]

Konrad,

 

What are your thoughts on this?   I am still not sure whether generally there isn't a third state which is not sure - here is some information for you to make a judgement, although if you are happy with this.  Can we try and get a proposed set of changes ready for the next DSS?

 

Regards

 

Nick

-----Original Message-----
From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
Sent: 13 January 2006 17:56
To: Konrad Lanz
Cc: DSS TC List
Subject: [dss] Re: <Result>/<ResultMinor> more values vs appropriate modelling [Action 05-11-28-04]

Hi Konrad -

> Considering all values above, it has to be noted that the <ResultMinor>
> is not limited to core validity of XMLDsig signature verification even
> not if resultminor would only take the values starting with 1.2.

My current view on this (still) is that the DSS core validation processing should
reflect the XMLSIG Core Validation requirements and that the ResultMinor value
space should also reflect that.  In other words, that there should be two values
in the core related to signature validity:

1.2.1 urn:oasis:names:tc:dss:1.0:resultminor:valid
1.2.2 urn:oasis:names:tc:dss:1.0:resultminor:invalid

If a third one is required - one that draws the callers attention to the presence of
manifest validation results - I propose that its value also reflects valid core-validation
and additionally contains a hint that Manifest's were also validated. The caller can in
this case consult the VerifyManifestResults for details on what References (in the Manifest)
did and did not validate. Something like:

1.2.3 urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults

Personally, I don't think this third resultminor is necessarily required - if the caller specifies
<VerifyManifests> in the request he knows to look out for manifest verification results.

ProcessingDetails currently defines a Type attribute value:

urn:oasis:names:tc:dss:1.0:detail:Manifest

which according to the current text indicates "Whether the manifests in the XML signature verified correctly." It is probably of interest to provide {Valid,Invalid,Indeterminate}Detail at a per Reference basis so I propose modifying the text to: "Whether a manifest reference in the XML signature verified correctly."

I don't mind renaming ProcessingDetails to ValidationDetails but I think it should remain optional and that <ReturnProcessingDetails> in that case should stay and become <ReturnValidationDetails>.

Regards,
Tommy

On 12/9/05, Konrad Lanz <Konrad.Lanz@labs.cio.gv.at> wrote:

Dear Tommy and all,

The status quo (committee draft 3) concerning the <Result> element
returned in a <SignResponse> or <VerifyResponse> is as follows:

The <Result>/<ResultMajor> indicates whether processing was a success
(urn:oasis:names:tc:dss:1.0:resultmajor:Success) and the server was able
to return a response that either carries a signature in a <SignResponse>
or a statement about the validity of a signature (timestamp).
If processing was not successful the server responds with a
(urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError) if it could
determine that the processing error occurred due to a malformed request
or inconsistent data sent by the client otherwise a ResponderError
(urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError) is returned
assuming that the failure was caused by the server.

The <Result>/<ResultMinor> currently offers a set of values for 1.
successful processing and 2. erroneous processing. (I numbered them to
ease the discussion. Profile editors are welcome to contribute further
<ResultMinor> values as this will enable a broader view on the issue).
1. can be further divided in sign (1.1) and verify (1.2) specific
<ResultMinor> values however there are currently none for the sign
request. 1.2 can be divided in valid signature/timestamp (1.2.1)
responses, invalid signature/timestamp (1.2.2) responses and
indeterminable signature ( 1.2.3) responses.

1.2.1.1 urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures
1.2.1.2
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
1.2.1.3
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments
1.2.1.4
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocumentsReferenced

1.2.2.1
urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
1.2.2.2 urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
1.2.2.3 urn:oasis:names:tc:dss:1.0:resultminor:invalid:untrustedKey
1.2.2.4 urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
1.2.2.5 urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature

1.2.3
urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs

2.1 urn:oasis:names:tc:dss:1.0:resultminor:NotAuthorized
2.2 urn:oasis:names:tc:dss:1.0:resultminor:NotSupported
2.3 urn:oasis:names:tc:dss:1.0:resultminor:NotParseableXMLDocument
2.4 urn:oasis:names:tc:dss:1.0:resultminor:XMLDocumentNotValid
2.5 urn:oasis:names:tc:dss: 1.0:resultminor:XPathEvaluationError
2.6 urn:oasis:names:tc:dss:1.0:resultminor:MoreThanOneRefUriOmitted

1.2.3 The introduction of 1.2.3 became necessary as <ds:Manifest> (cf.
http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest
<http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest> and
http://www.w3.org/TR/xmldsig-core/#sec-Manifest) mandates that
applications may reserve reference validation decision logic to themselves.
In our case this means that only clients will be able to decide upon
validity themselves, based on the information given in
<VerifyManifestsResults>. Note that this is only relevant if the
optional input <VerifyManifests> was sent as and <ds:Manifest> are
treated as normal documents otherwise.

Considering all values above it has to be noted that the <ResultMinor>
is not limited to core validity of XMLDsig signature verification even
not if resultminor would only take the values starting with 1.2.

There is a need to discuss the relations between <ResultMinor>,
<ProcessingDetails> and <VerifyManifestsResults>.

My feeling is that a lot of things dealt with in <ResultMinor> should be
rather in <ProcessingDetails>. I also think that <ProcessingDetails>
should be rather called <ValidationDetails> as it seems that would
reflect what they really are. And <VerifyManifestResults> should be
merged into it.

So we could and should limit <ResultMinor> to

1.2.1 urn:oasis:names:tc:dss:1.0:resultminor:valid
1.2.2 urn:oasis:names:tc:dss:1.0:resultminor:invalid
1.2.3
urn:oasis:names:tc:dss: 1.0:resultminor:indetermined:checkOptionalOutputs

and leave values 2.1 - 2.6 as they are.

The only and probably more sensible alternative would be to abandon the
values starting with 1 and to limit <ResultMinor> to add more verbosity
to unsuccessful processing. On the other hand we should elaborate
<ValidationDetails> (<ProcessingDetails>) to a compulsory output element
for <VerifyRequst> and model the validation verbosity level inside
<ValidationDetails>.

To conclude, I think the introduction of more <ResultMinor> values will
cause that we leave the route of designing an xml protocol and we would
start to model structure inside URNs.

best regards
Konrad

This mail is related to Action [05-11-28-04]

P.S.: I think I mentioned previously already that 1.2.1.3
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments
should be abandoned because the client does not specify transforms on a
verify request and a server only performs the transforms inside
<ds:Reference>/<ds:Transforms>.