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

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

Dear Stefan, Nick, Tommy and all,
find the minutes and proposals of the telco "<ResultMajor>, 
<ResultMinor>  Values", below.
Stefan, could you please update the relevant section in the core 
document and rephrase the proposed changes where necessary to fit into 
the text.

Nick, Tommy and all, I hope haven't missed some <ResultMinor>, please check.

best regards
Konrad

------ Minutes 20060206 ------
Tommy Lindberg
Nick Pope
Konrad Lanz
------------------------------------------------------
1) ResultMinor are spread between 2.6 and 4.4.
> Nick proposed that they are all moved to 2.6 with a backward reference 
> to the three valid signature codes in 4.4.
> [Tommy, Konrad]: Agreed
------------------------------------------------------
2) The <ResultMajor> 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.
urn:oasis:names:tc:dss: 1.0:resultmajor:InsufficientInformation - The 
request could not be satisfied due to insufficient information.

In case of doubt of who is responsible a 
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError is assumed.
> Konrad: We introduced a fourth <ResultMajor> value 
> urn:oasis:names:tc:dss: 1.0:resultmajor:InsufficientInformation plus 
> associated <ResultMinor> values further down.
------------------------------------------------------
The one of the following <ResultMinor> values is MUST be returned when 
the <ResultMajor> code is Success.

urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments - 
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.
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocumentsReferenced 
- 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.
urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature :  The 
signature fails to verify, for example due to the signed document being 
modified or the incorrect key being used.
invalid:untrustedKey - [remains] 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.

invalid:indetermianteKey - [untrustedKey and InsufficientInformation 
cases cover this already hence this was split in two errors 
KeyNotProvided, KeyLookupFailed and moved]
indetermined:checkOptionalOutput - [removed]
urn:oasis:names:tc:dss: 
1.0:resultminor:valid:signature:OnTransformedDocuments - [removed]
> Konrad, Nick, Tommy: remove.
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. Note: In 
the case that the core signature validation failed no attempt is made to 
verify the manifest.
> Konrad, Nick, Tommy: agreed.
------------------------------------------------------
The following <ResultMinor> values is suggest MAY be returned when the 
<ResultMajor> code is RequesterError .

urn:oasis:names:tc:dss:1.0:resultminor:referencedDocumentNotPresent - 
[i.e. remove the word invalid] 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.
> Konrad: I would have thought so as it seems to me to be the clients 
> responsibility to provide all documents, isn't it ?
urn:oasis:names:tc:dss:1.0:resultminor:KeyNotProvided - The Key was not 
supplied by the client, but the server expected it to do so.
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.

Further values for <ResultMinor> associated with <ResultMajor> code 
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError are left open to 
the implementor to be implemented with in their namespaces.

------------------------------------------------------
The following <ResultMinor> values is suggest MAY 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: It should remains subject to discussion if and how 
> indeterminable failures on the server side shall be reported to the 
> client, as this causes a leakage of information about vulnerability.
> Konrad: Some sort of response will have to be given, and giving no 
> response is also a response.
urn:oasis:names:tc:dss:1.0:resultminor:invalid:KeyLookupFailed - 
Unsuccessful lookup for key in directory of a key server (for validate) 
or some crypto device for signature.

Further values for <ResultMinor> associated with <ResultMajor> code 
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError are left open to 
the implementor to be implemented with in their namespaces.

------------------------------------------------------

The following <ResultMinor> values is suggest MAY 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.

------------------------------------------------------

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 if 
XMLDSig core validation succeeds and the optional output 
<VerifyManifestResults> is returned indicating the status of the 
manifest reference verification.
> Nick: I presume you mean 4.6.1
> Tommy: In case of a negative XMLDSig core validation no attempt is 
> made to verify manifests. 
-------------------------------------------------------

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.