Manifest validation results

[Tommy Lindberg <tommy.lindberg@gmail.com>]

[This is a dialog between Konrad and myself about Manifest validation results.]

Here's a coarse proposal for carrying manifest validation information back
to the client in support of <dss:VerifyManifests>.

To recap; Manifest validation is not part of XMLSIG core validation and
the affect a failed Manifest verification has, is determined at the
applications discretion.

In order to return the required ds:Manifest/ds:Reference validation results back to
the client, additional markup is required - this will be in the form of an optional output.
The validation result constitutes the actual outcome of the validation - valid or invalid - as
well as information regarding what ds:Reference it relates to.

ds:Reference's are carried in ds:Manifest's that are in turn carried in ds:Object's.
There can be more than one ds:Object in a single ds:Signature; there can also be more
than one ds:Manifest in a single ds:Object.

All of the three elements (ds:Object, ds:Manifest, ds:Refernce) do have ID attributes but
as they are optional, their presence cannot be relied upon and can consequently not
be used (as xs:string's or similar) as the means of identifying a ds:Reference in the
general case.

I initially considered an approach similar to the one taken by the dss:TransformedDocument
optional output which identifies references by means of their  position (using a zero based
integer) in the <ds:SignedInfo> -  it got messy halfway through when the number of "position"
attributes increased so I abandoned that for the time being.

Instead I am proposing the use of an XPath expression (WhichReference) to identify the Manifest
Reference for which the validation status is reported.  The status (Status) contains a URI
that indicates the validation outcome - valid or invalid.

dss:VerifyManifestResults would be an optional output.

A sketchy schema fragment follows:

<xs:element name="VerifyManifestResults" type="dss:VerifyManifestResultsType"/>
<xs:complexType name="VerifyManifestResultsType">
  <xs:sequence>
    <xs:element ref="dss:ManifestResult" maxOccurs="unbounded"/>  
  </xs:sequence>
</xs:complexType>

<xs:element name="ManifestResult">
  <xs:complexType>
    <xs:element name="ReferenceXpath" type="xs:string"/>
    <xs:element name="Status" type="xs:anyURI"/>
  </xs:complexType>
</xs:element>


Example instance fragment reporting the validation status for two references in the same Manifest
one of which is valid the other invalid.

<VerifyManifestResults>
  <ManifestResult>
    <ReferenceXpath>XPath identifying reference one</ReferenceXpath>
    <Status>urn:oasis:names:tc:dss:1.0:manifestresult:Valid</Status>
  </ManifestResult>
  <ManifestResult>
    <ReferenceXpath>XPath identifying reference two</ReferenceXpath>
    <Status>urn:oasis:names:tc:dss:1.0:manifestresult:Invalid</Status>
  </ManifestResult>
</VerifyManifestResults>

[Start of Konrad's comments]

If I understand you right you propose to verify manifesto's
(<ds:Manifest>) if they are referenced by a SignedInfo, but not their
references (<ds:Manifest>/<ds:Reference>)

. However if someone also
supplies the optional input <VerifyManifests> we do check them although
core validation for a <ds:SignedInfo> will succeed referencing a failed
manifest having a failed reference(<ds:Manifest>/<ds:Reference>) thus
producing an optional output indicating this.

It is in line with [XMLSig] however I think we need some further
discussion if we really should return an overall valid result in such a
case. To be able to leave the decision to the client I think we'd need a
new Resultcode that SHALL signal the Error.

I think we should also try to get it a little bit in sync with
<ProcessingDetails>/<InvalidDetail>, <ProcessingDetails>/<ValidDetail>.
I think that a Manifest verification should then imply the returning of
<ProcessingDetails> as well.

We should probably also rethink our ResultCodes on this occasion and I'd
suggest the following changes as a first solution:

urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocumentsReferenced
urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
urn:oasis:names:tc:dss:1.0:resultminor:invalid:untrustedKey
urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
urn:oasis:names:tc:dss: 1.0:resultminor:inappropriate:signature
and eventually
urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs

This is a little bit odd however and I think better modeling of
Resultminor in xml schema is necessary in a future release.

[End of Konrad's comments]

Regards
Tommy