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

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

Tommy, Konrad,

 

Nearly there - Can we have a (hopefully) short Skype call sometime on Monday to resolve all the final details.

 

The MinorResult values now seem to be rather arbitrarily spead between 2.6 and 4.4.  I propose that they are all moved to 2.6 with a backward reference to the three valid signature codes in 4.4.

 

I can't see us being able to capture all the minor codes so I suggest that we make only the Major codes have to be from the Core / Profile (see below)

 

Nick

 

-----Original Message-----
From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
Sent: 02 February 2006 18:09
To: Konrad Lanz
Cc: dss@lists.oasis-open.org
Subject: Re: [dss]: A first quick Shot at section 4.4 and section 4.6.1

Thanks for the feedback Konrad.  My tagged comments are inline.

Regards,
Tommy

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  

I suggest that we allow other result minors to be defined to cover cases we have not thought about (see below).  So this should be:

 

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

 

I am not clear what is proposed either.  Do you mean "requestor error".  Rather than defining them now should we leave this open so that values of ResultMinor may be other than those defined in the Core or profiles (see above)

How about this?
""
The following <ResultMinor> values SHALL only be  

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: Shouldn't a (service) administrator get informed about exceptional conditions without requestor involvement?]  

 

This is an issue for the implementation of the system can be left open as it doesn't effect interopability. 

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

 

Again it may be useful for the client administrator but whether this is returned back to the user is an implementation question.  

 

> [...] Section 4.4 in its entirety.
> "" 

Assume valid:signature:onAllDocuments remains as is

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

 

Agreed. 

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

 

What about:

  valid:notAllDocumentsReferenced  - I suggest that this remains

  invalid:referencedDocumentNotPresent - this is not realy a requester error and should be added to this list

  invalid:indetermianteKey - I presume that this is replaced with the responder error list above and "invalid" removed

  invalid:untrustedKey - This should remain

  invalid:IncorrectSignature - Keep but reword as follows 

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. 

 

indetermined:checkOptionalOutput - I presume that this is removed.

 

 
> 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 

 

I presume you mean 4.6.1

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

I suggest re-worded: 

 if XMLDSig core validation succeeds
  

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

 

I disagree.  There should be no statement of what other return values may be indicated for the case of other than Valid Signature.  This will depend on the why it failed.  Should not add this.

 

 

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