[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [dss]: A first quick Shot at section 4.4 and section 4.6.1
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>.
> >
> >
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]