Hi Nick and Tommy,
please see below
Konrad
Nick Pope wrote:
Nearly there - Can we have a (hopefully)
short Skype call sometime on Monday to resolve all the final details.
I'm available until 12:00 CET and the from 14:00 to the call.
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 agree.
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)
[...]
> 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.]
[...] Do you
mean "requestor error".
No, I was talking about the <ResultMajor> code
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError.
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)
Okay let's do it that way, however we then need to state that.
E.g.: Values for <ResultMinor> associated with
<ResultMajor> code
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError are left open to
the implementor.
"" 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: 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.
I agree with Nick, lets suggest the values I proposed using MAY so we
have some direction to more streamlined error reporting.
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?]
I don't have a strong opinion about whether there are one or two values
for this as these are examples, however I prefer two.
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 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.
""
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.
Nevertheless we need to make a clear statement. Like either a), b) or
c) ...
a) see above and introduce a third <ResultMajor> value
urn:oasis:names:tc:dss: 1.0:resultmajor:InsufficientInformation plus
suggested <ResultMinor> values.
Let's probably use the phrase (is suggest "MAY be")
here as well.
b) In case of doubt of who is responsible a
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError is assumed.
c) In case of doubt of who is responsible a
urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError is assumed.
d) ... proposals welcome ...
> [...] Section 4.4 in its entirety.
Assume valid:signature:onAllDocuments
remains as is
> [...] remove
urn:oasis:names:tc:dss:
1.0:resultminor:valid:signature:OnTransformedDocuments [...]
[Tommy: Makes sense to me.]
Agreed.
So, let us hereby propose to remove this for the telco.
>
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
Agreed.
invalid:referencedDocumentNotPresent -
this is not realy a requester error and should be added to this list
I would have thought so as it seems to me to be the clients
responsibility to provide all documents, isn't it ?
invalid:indetermianteKey - I presume that
this is replaced with the responder error list above and "invalid"
removed
invalid:untrustedKey - This should remain
I prefer to have invalid removed here too as I don't think a statement
about validity is
necessary in case of an untrusted key. Validation could even be omitted
completely. So how about associating this with a <ResultMajor>
RequestorError?
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.
Agreed.
indetermined:checkOptionalOutput
- I presume that this is removed.
Agreed.
>
urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature
[...] This should be moved up to section 2.6 and associated with
RequesterError.
[Tommy: OK. With the same name?]
So, let us hereby propose to move this for the telco.
>
> 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
Agreed.
>
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.
This is what I intended to say by
urn:oasis:names:tc:dss:1.0:resultminor:invalid:* .So lets put it this
way:
In case of a negative XMLDSig core validation the relevant
<ResultMinor> is to be returned indicating why it
failed.
>
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.
> ""
Agreed.