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

["Nick Pope" <pope@secstan.com>]

Minor suggestions on wording, otherwise OK


> -----Original Message-----
> From: Konrad Lanz [mailto:Konrad.Lanz@labs.cio.gv.at]
> Sent: 06 February 2006 12:49
> To: Stefan Drees
> Cc: Nick Pope; Tommy Lindberg; Konrad Lanz; DSS TC List
> Subject: Re: [dss]: A first quick Shot at section 4.4 and section 4.6.1
>
>
> 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:notAllDocum
> entsReferenced
> - 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.
I suggest " .... KeyInfoNotProvided - The required key information was not
supplied ....."

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

I am not quite clear what is mean by "exceptional state" can you give some
examples.

Or do you mean "......GeneralError - The processing of the request failed
due to some an error not covered by the existing error codes. Further
details should be given ...."

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

The spec should not be specific on how keys are obtained or held.  Suggest:
"....... KeyLookupFailed - Failed to locate the identified key (e.g. look up
failed in directory or not in local key file)."

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