RE: Re: FW: [dss]: A first quick Shot at section 4.4 and section 4.6.1

On 1/25/06, Nick Pope <pope@secstan.com> wrote:

Tommy,

I agree that the content of ResultMessage has to be free text and that all we can do is provide guidance.

I think that the use of a hierachy of values in the ResultMinor space is the way to go.

Where we differ is the need for "indetermined" as well as valid and invalid as the first level. Without this branch how would you indicate that the server does not have sufficient information to evaluate whether the signature is valid or not, for example:

a) The document in the signature references is not currently available? [that is in the core XML signature not in the manifest]

b) The does not have the necessary information (certificates, revocation status) to decide if the siging key is valid.

I recognise that for some signatures the server may always have the information necessary to decide valid / invalid, but this will not be true for all signature policies.

I cannot understand without the "indeterminate" ResultMinor value the server can signal this situation. Perhaps you can explain

Nick

-----Original Message-----
From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
Sent: 24 January 2006 23:30
To: Nick Pope
Cc: OASIS DSS TC
Subject: Re: FW: [dss]: A first quick Shot at section 4.4 and section 4.6.1

Nick, Konrad -

ResultMessage appears to be for free text that ends up in a log file or an error dialog and I don't
believe the spec should require specific text here. I propose the spec instead (strongly) encourages
a precise problem description or diagnostic.

As regards the <ResultMinor> value space; I still don't see the need for values starting with
urn:oasis:names:tc:dss:1.0:resultminor:indetermined.

In the case of XMLSIG, my view is that a DSS service should only make statements about XMLSIG
core validation. If Manifests were validated then this is indicated with
urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults.

>Another example is the absence of a referenced Document, in such a case
>the signature also isn't determinable. However in such a case even the
>core validity of the signature isn't determinable.

I suggest that this is an erronous condition that should be flagged differently
e.g. with a RequesterError.IncompleteRequest resultmajor/resultminor pair.

In the case that the signature validation key cannot be determined I propose that this too is
reported with a distinct resultmajor/resultminor value pair e.g.
{Requester,Responder}Error.NoValidationKey depending on whether or not the policy
expects/requires the validation key inband.

Regards,
Tommy

On 1/23/06, Nick Pope <pope@secstan.com> wrote:
All,

Forwarding proposal from Konrad on handling of result codes & manifest
validation base with response from myself, for discussion at today's DSS
call.

Nick

> --- snip ---
>
> 4.4 Result Codes
> Whether the signature succeeds or fails to verify, the server will
> return the Success <ResultMajor> code.
> The <ResultMinor> URI MUST be one of the following values, or some other
> value defined by some profile of this specification.
> The values listed below indicate whether the signature or timestamp is
> valid, invalid or indetermined.
>
> urn:oasis:names:tc:dss:1.0:resultminor:valid
> urn:oasis:names:tc:dss:1.0:resultminor:invalid
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined
>
> These Resultminor values can optionally be further qualified by the
> optional output <ProcessingDetails>(<ValidationDetails>), if and only if
> a client specified <ReturnProcessingDetails>(<ReturnValidationDetails>)
> in the <VerifyRequest>/<OptionalInputs>.
>
> The <ResultMinor> also MAY be further qualified by a <ResultMessage> and
> implementors are encouraged to do so.
>
> The following rules SHALL be followed to bind a certain scenario to a
> <ResultMinor> and a <ResultMessage> as follows, their numberings give a
> priority that shall be followed (1.1 = highest priority) to determine
> the <ResultMinor>. If more than one Rule matches the <ResultMessage>s
> SHALL be concatenated. This MAY be extended by optional inputs and
> profiles, but extensions SHALL not contradict these rules.
>

For all the rules given below the ResultMessage SHOULD contain the given
words or alternative words with the same meaning in the relevant language.

> * Rule 1.1: The signature or timestamp is valid. Furthermore, the
> signature or timestamp covers all of the input documents just as they
> were passed in by the client.
> <ResultMinor>: urn:oasis:names:tc:dss: 1.0:resultminor:valid
> <ResultMessage>: "Valid signature all Documents
> covered".
>
> * Rule 1.2: The signature or timestamp is valid. However, the signature
> or timestamp does not cover all of the input documents that were passed
> in by the client.
> <ResultMinor>: urn:oasis:names:tc:dss:1.0:resultminor:valid
> <ResultMessage>: "WARNING Valid signature, not
> all Documents covered (referenced)".

Suggest " .... not all documents reference in request are covered by
signature"

>
> * Rule 2.1: The signature fails to verify, indicating that the message
> was modified in transit, or that the signature was performed incorrectly.
> <ResultMinor>: urn:oasis:names:tc:dss:1.0:resultminor:invalid
> <ResultMessage>: "WARNING Invalid signature, at
> least one covered document was modified".

Suggested ".... at least one document covered by signature was modified."
>
> * Rule 2.2: The signature is performed by a key the server considers
> suspect. For example, the signing key may have been revoked, or it may
> be a different key from what the server is expecting the signer to use.
> <ResultMinor>: urn:oasis:names:tc:dss:1.0:resultminor:invalid
> <ResultMessage>: "WARNING Signature invalid, due
> to an untrusted Key".
>
> * Rule 3.1: A <ds:Reference> element is present in the <ds:Signature>
> containing a full URI, but the corresponding input document is not
> present in the request.
> <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:in
> determined
> <ResultMessage>: "WARNING Valid signature, but a
> required Documents is not available".
>

[Not convinced about need for ":xmldsigcore:indetermined", if we are to
extend the result code tree I would suggest that we have an explicit result
minor code.]

> * Rule 3.2:. The server could not determine whether the signing key is
> valid. For example, the server might not have been able to construct a
> certificate path to the signing key.
> <ResultMinor>: urn:oasis:names:tc:dss:1.0:resultminor:indetermined
> <ResultMessage>: "WARNING Signature validity
> indetermined, due to an indeterminate Key".

[Following on from above, what is the distinction about this not being
"xmldsigcore:indetermined"]
>
> --- snip ---
>
> The following scenario is probably better to be dealt with by issuing an
> unsuccessful <ResultMajor>, but this needs further consideration:
> * The signature or its contents are not appropriate in the current
> context. For example, the signature may be associated with a signature
> policy and semantics which the DSS server considers unsatisfactory.

[I would say that the signature is invalid if it does not meet the
requirements of the policy.  I am not sure I understand what "not
appropriate" or "unsatisfactory" means.]

* Rule 4.1:. The signature does not meet the requirements of the policy in
force for the signature being validated.
<ResultMinor>:
urn:oasis:names:tc:dss:1.0:resultminor:invalid:signaturepolicyerror
<ResultMessage>: "WARNING Signature invalid, failed to meet requirements of
signature policy"
Note: It is recommended that additional words are added providing more
details.

>
> --- snip ---
> 4.6.1 Optional Input <VerifyManifests> and Output <VerifyManifestResults>
> The presence of this element instructs the server to validate manifests
> in an XML signature.
> On encountering such a document in step 2 of basic processing, the
> server shall repeat step 2 for all the <ds:Reference> elements within
> the manifest. In accordance with [XMLSIG] section 5.1, DSS Manifest
> validation does not affect a signature's core validation. The results of
> verifying individual <ds:Reference>'s within a <ds:Manifest> are
> returned in the <dss:VerifyManifestResults> optional output. For
> example, a client supplies the optional input <VerifyManifests>, then
> the returned <ResultMinor> is
> urn:oasis:names:tc:dss: 1.0:resultminor:indetermined:xmldsigcore:(valid |
> invalid | indetermined) (according to the XMLDSig core validity and the
> rules above mutatis mutandis) and the optional output
> <VerifyManifestResults> is to be returned indicating the status of the
> manifest validation.
>
> 4.4.1 Result Codes for <VerifyManifest>
> In the case of <VerifyManifest> being sent the rules above are extended
> as follows:
>
> urn:oasis:names:tc:dss: 1.0:resultminor:indetermined:xmldsigcore:valid
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:invalid
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:in
> determined
>
> The following rule SHALL amend the rules in section 4.4.
>
> ... A <ds:Reference> element is present in a <ds:Manifest> containing a
> full URI, but the corresponding input document is not present in the
> request and <VerifyManifest> optional input was given.
> <ResultMinor>:
> urn:oasis:names:tc:dss:1.0:resultminor:indetermined:xmldsigcore:(valid |
> invalid | indetermined) (according to the XMLDSig core validity and the
> rules above mutatis mutandis)

[I would keep anything about <verifyManifest> in 4.6.1.  I don't follow the
reason for this text for 4.4.1.  A simple note regarding manifests would be
sufficient.]

Replace with:

Note: The result code for core validation is not affected by the results of
any manifest verification.  See 4.6.1 for optional input and output for
Verify Manifest.

> ...
> --- snip ---
> .... we need some more text here
>
> best regards
> Konrad
>
> Tommy Lindberg wrote:
> > 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
> > <mailto: 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 < http://1.2.1.1>
> >     urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures
> >     1.2.1.2 < http://1.2.1.2>
> >
> urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
> >     1.2.1.3 < http://1.2.1.3>
> >
> urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransform
> edDocuments
> >     1.2.1.4 < http://1.2.1.4 >
> >
> urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocum
> entsReferenced
> >
> >
> >     1.2.2.1 < http://1.2.2.1>
> >
> urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
> >     1.2.2.2 < http://1.2.2.2>
> >     urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
> >     1.2.2.3 < http://1.2.2.3>
> >     urn:oasis:names:tc:dss: 1.0:resultminor:invalid:untrustedKey
> >     1.2.2.4 < http://1.2.2.4>
> >     urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
> >     1.2.2.5 < http://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)
> >     < http://www.w3.org/TR/xmldsig-core/#sec-Manifest%29> 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
> >     <http://1.2.1.3>
> >
> urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransform
> edDocuments
> >
> >     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>.
> >
> >
>
>

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

dss message