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

On 2/1/06, Konrad Lanz <Konrad.Lanz@labs.cio.gv.at> wrote:

Hi Tommy and all,

please find comments below.

regards
Konrad

Tommy Lindberg wrote:
> Section 2.6 starting at line 551.
>
> ""
> The <ResultMajor> and <ResultMinor> URIs MUST be values defined by
> this specification
> or by some profile of this specification. The <ResultMajor> values
> defined by this specification are:
>
> urn:oasis:names:tc:dss:1.0:resultmajor:Success
> The protocol executed successfully.
>
> urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
> The request could not be satisfied due to an error on the part of the
> requester.
>
> urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError
> The request could not be satisfied due to an error on the part of the
> responder.
What about the <ResultMinor> values if the <ResultMajor> code is
ResponderError?

[Tommy: Seems like a good idea but I am not sure about the actual values you propose - see below.]

How about this?
""
The following <ResultMinor> values SHALL only be
returned when the <ResultMajor> code is ResponderError.

urn:oasis:names:tc:dss:1.0:resultminor:ResponderException
The processing of your request caused an exceptional state. Further
Information should be given in the result message instructing the user
to provide information to the relevant administrator.

[Tommy: Shouldn't a (service) administrator get informed about exceptional conditions without requestor involvement?]

urn:oasis:names:tc:dss:1.0:resultminor:OutOfServiceHours
The the service is currently not operating.

urn:oasis:names:tc:dss:1.0:resultminor:Maintenance
The the service is currently under Maintenance.
""
etc..

[Tommy: Could we combine these two into urn:oasis:names:tc:dss:1.0:resultminor:ServiceUnavailable?]

We should also add the following <ResultMajor>
""
urn:oasis:names:tc:dss: 1.0:resultmajor:InsufficientInformation.
The request could not be satisfied due to insufficient information.
""
plus the following <ResultMinor> values.
""
The following <ResultMinor> values SHALL only be
returned when the <ResultMajor> code is InsufficientInformation.

urn:oasis:names:tc:dss:1.0:resultminor:CrlNotAvailiable
The relevant certificate revocation list was not available for checking.

urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable
The relevant revocation information was not available via the online
certificate status protocol.

urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete
The chain of trust could not be established binding the public key used
for validation to a trusted root certification authority via potential
intermediate certification authorities.
""
etc ...

[Tommy: I am wondering if the requestor can make much use of this information. Again, I am inclined to think that the service admin should be alterted about these events through a log or some such.]

> [...] Section 4.4 in its entirety.
> ""
> [...]
> urn:oasis:names:tc:dss: 1.0:resultminor:valid:signature:OnTransformedDocuments
> The signature or timestamp is valid. Furthermore, the signature or
> timestamp covers all of the
> input documents. However, some or all of the input documents have
> additional transforms applied
> to them that were not specified by the client.
My view is that
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnTransformedDocuments
should be removed, as the client does not specify transforms on a verify
request and a server only performs the transforms
inside<ds:Reference>/<ds:Transforms>.

[Tommy: Makes sense to me.]

> urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults
> The signature is valid with respect to XML Signature core validation.
> In addition, the message also
> contains VerifyManifestResults.
> [...]
> urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature
> 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.
> ""
This should be moved up to section 2.6 and associated with RequesterError.

[Tommy: OK. With the same name?]

>
> Section 4.6.2
>
> ""
> For example, if a client supplies the optional input
> <VerifyManifests>, then the returned
> <ResultMinor> is
> urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults
for positive XMLDSig core validation

[Tommy: I agree.]

> and the
> optional output <VerifyManifestResults> is returned indicating the
> status of the manifest reference
> verification.
> ""
In case of a negative XMLDSig core validation the relevant <ResultMinor>
urn:oasis:names:tc:dss:1.0:resultminor:invalid:* is to be returned.

[Tommy: I agree.]

>
> Section 4.6.4
>
> The granularity of the *Detail in <ProcessingDetails> should, in the
> case of a Manifest, be per
> Reference; to reflect this I suggest changing the text on lines 1703
> and 1704 from
>
> ""
> urn:oasis:names:tc:dss:1.0:detail:Manifest
> Whether the manifests in the XML signature verified correctly.
> ""
>
> to
>
> ""
> urn:oasis:names:tc:dss:1.0:detail:ManifestReference
> Whether a manifest reference in the XML signature verified correctly.
> ""

dss message