Action point on PRocessingDetails and reports

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

Trevor,

This message deals with the action point on me for giving some inputs
on the processing details.

First of all I have to say that my view of this issue is to have elements
in the answer allowing the server to tell to the client:

"I have verified your signature and the verification has failed.
By the way, during the verification, the cryptographic verification 
of the signature was OK, the validation of your certificate was OK,
the validation of the certificate of your CA was OK, BUT the 
validation of the certificate of your CA's CA did not succeed because
it was revoked...."

What this means is that we would need a way of allowing pairs of
(object,status) that could be integrated in the response.

With the current structures in section 4.5.8 this is not possible.
If I have correctly understood they just allow to give high level details
but not associated with a specific token (ie, a certificate in the CertPath).
They do not allow either, for instance to report problems like "unable to 
contact a OCSP server", or "unable to retrieve the CRL that has to
be checked for validating this certificate in the certpath".

As I said, this is the kind of details that were in my mind when I raised the
issue. 

I would sugest then to sketch a solution that would satisfy this requirement.
Whether this must be part of the core or part of some profile is something
that we can leave fof after having agreed on the schema, and the group
give their opinions....

What I am about to put below is mostly based on the document I submitted
some time ago to the list: "Servei de Validacio de CATCert", that was produced
by the three persons that appear in the first page of the doucment.

I will just give some details below. If we agree that such information
can be useful, we should afterwards consider how the ProcessingDetails
should be modified to incorporate them or to allow their incorporation in 
a profile.

The <Reports> element would concentrate a sequence of individual reports
giving information on each token that the service will have verified or
validated.

<xs:element name="Reports" type="ReportsType"/>

<xs:complexType name="ReportsType">
	<xs:sequence>
		<xs:element name="Report" type="ReportType" maxOccurs="unbounded"/>
	</xs:sequence>
</xs:complexType>

<xs:element name="Report" type="ReportType"/>

<xs:complexType name="ReportType">
	<xs:sequence>
		<xs:element name="Status" type="StatusType"/>
		<xs:element name="AdditionalInfo" type="AnyType" minOccurs="0"/>
	</xs:sequence>
</xs:complexType>

The <Status> element would contain information on the token
verified/validated and its corresponding
status.
The <AdditionalInfo> element would allow for any server to include other
kind of information to the
report. For instance, the service that I have already mentioned envisages
to give a kind of trust level indication 
in the view of the tokens verified/validated...

The <Status> element has the attribute Value that can be Valid or Invalid
summarizing
the status of the specific token.
Its content gives the reason(s) why it is Valid or Invalid

<xs:element name="Status" type="StatusType"/>

<xs:complexType name="StatusType">
	<xs:sequence>
		<xs:element name="Reasons" type="StatusReasonListType"  minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="Value" type="StatusValueType"  use="required"/>
</xs:complexType>

<xs:simpleType name="StatusValueType">
	<xs:restriction base="xs:string">
		<xs:enumeration value="Valid"/>
		<xs:enumeration value="Invalid"/>
	</xs:restriction>
</xs:simpleType>

<xs:complexType name="StatusReasonListType">
	<xs:sequence>
		<xs:element name="Reason" type="StatusReasonType" maxOccurs="unbounded"/>
	</xs:sequence>
</xs:complexType>

There may be a great number of reasons that can invalidate some token.
Below follow the ones
that we were able to think of while producing such document....

<xs:complexType name="StatusReasonType">
	<xs:choice>
		<xs:element name="CertValidByCRL" type="ds:X509IssuerSerialType"/>
		<xs:element name="CertValidByOCSP">
			<xs:complexType>
				<xs:sequence>
					<xs:element name="CertId" type=ds:X509IssuerSerialType"/>
					<xs:element name="OCSPId" type="xs:string"/>
				</xs:sequence>
			</xs:complexType>
		</xs:element>
		<xs:element name=”CRLNotReached”  type="xs:string"/>
		<xs:element name=”OCSPNotReached” type="xs:string"/>
		<xs:element name="SignatureFailure"/>
		<xs:element name="CertSignatureFailure" type="ds:X509IssuerSerialType"/>
		<xs:element name="CertRevoked"  type="ds:X509IssuerSerialType"/>
		<xs:element name="CertExpired"   type="ds:X509IssuerSerialType"/>
		<xs:element name="SignatureAttrNotPresent"  type="PropertyIdentifieType"/>
		<xs:element name="SignatureAttrUnvalid"  type="PropertyIdentifieType"/>
		<xs:element name="CertExtensionNotPresent"
type="CertAndExtensionIdentifierType"/>
		<xs:element name="CertExtensionUnvalid"
type="CertAndExtensionIdentifierType"/>
		<xs:element name="Other" type="AnyType"/>
		<xs:element name="SignedObjectDigestFailure">
			<xs:complexType>
				<xs:attribute name="URI" type="xs:anyURI" use="optional"/>
			</xs:complexType>
		</xs:element>
	</xs:choice>
</xs:complexType>

The name tags are semantically selfcontained: the names indicate the
reasons. The contents of
the elements are supporting information: if one certificate is revoked,
then the content of the element
is the identifier of the certificate, and so on.... 

There are a couple of types more (those identifying some property in the
signature and those identifying
an extension within a certificate), but before including them I would like
to check whether you would consider
useful to have such a reporting mechanism as part of the core or one of the
profiles....

I am sure that there would be other ways of structuring this information
(for instance, it could be thougth in 
the other way around: the tag of the element indicating the token type and
to assign QNames to the reasons)
 but the question remains, would we
like to have in the DSS a detailed reporting mechanism allowing the server
to give such a detailed information
on each token it has dealt with? If the answer is yes, then we can start
discussion on the specific structures...
What appears above is just a proposal..

Regards

Juan Carlos.