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

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

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?

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.

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

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

> [...] 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>.
> 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.
>
> 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
> 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.

>
> 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.
> ""