Comments to the individual report profile

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

Dear Detlef,

I appologize for not reacting  before, but these weeks have been quite 
busy for me....

I have eventually managed to go through the document... below follow 
some comments.

Below follow those ones that I would like to talk about at the next call:

1. More conformance levels given the huge amount of elements that would 
require compliance with the current advanced level.

2. Making CertificatePathValidity optional in a number of elements where 
this is mandatory, as we could be repeating information.

3. DetailType semantics redefinition. Changing the namespace for this 
new element?

4. Starting description of optional elements by "This element MAY 
[contain / indicate]..."

5. Comment on line 277.

Regards

Juan Carlos.

PD: Ezer, will try to go through the visible signature profile during 
this weekend....

---->
General comment: after re-reading the document and thinking about, I 
would say that the two conformance level are still not enough. I mean, 
that the amount of elements that an application conformant to the 
advanced level should be able to process is very big. I would suggest to 
think if it would be possible to have more granularity in the 
conformance levels. Something like this:

1.	Level 1: individual report for each signature. Only saying 
valid/invalid/incomplete. Only Optional outputs appearing the Core.
2.	Level 2: Level 1 plus references to the validation material managed 
for the verification (i.e.: identifiers of certificates, crls, ocsps, 
times-tamp tokens, etc).
3.	Level 3: Level 2 plus values of the validation material managed for 
the verification.
4.	Level 4: Level 3 plus the XML version of the different validation 
material managed for the verification (CRLContentType, OCSPContentType, 
CertificateContentType…)

I would say that if we do it, we may satisfy requirements of different 
implementers without forcing them to completely develop all the types 
when it might happen that they do not need them.

Another general comment,  could we talk of “ValidationData” instead of 
“SignedObject” when referring to data that have been used during the 
process of verification of the signature?

Specific comments:

Line 127-128: the writing does not actually say that the basic level 
does not require the incorporation of the <SignedObjectIdentifier> as 
specified in the profile. Suggest to explicitly mention it.

Line 168: I would say that the document re-defines the DetailType 
semantics.  In the core, the Type attribute is allocated for identifying 
what object is being reported. In this profile, it is used for reporting 
validity, invalidity or incompletness…should we consider to define a new 
type within a different namespace?

Line 204: <IncludeRevocationValues>. Is it not missing similar text to 
<IncludeCertificateValues> “signature (in binary form or as equivalent 
XML structure)”?

Line 208: Suggest to start: “If this element is set to true the server’s 
response MUST include…..”

Line 220: suggest substitute “For every signature, the certificate path 
and each individual certificate the details are reported” by “For every 
signature, the certificate path details and details on the validation of 
individual certificates in the path are requested”.

Line 220: Start with: “If the element <ReturnVerificationReport> is 
provided as optional input in the request, the server MUST include in 
the response the element <VerificationReport> optional output:”

Line 234: Answer to comment by Detlef: we decided to move the name to 
the last version of SAML. I am not sure we have implemented this yet. 
Should this need an editorial note? As for my comment, what about also 
allowing to identify the verifier by other means different to saml 
identifiers? Could it be possible to define a type with a choice on 
different already known ways? Not strong on this….we may go for CD and 
discuss internally….

Line 249. Suggest: “For each independent signed object (time stamp, 
certificate, CRL, OCSP-response, evidence record, the signature itself, 
etc.) that has been used in the signature(s) verification process there 
will be one …..”.

Line 277: SIgnedObjectIdentifierType. Which ones of its children are 
used when the object reported is a signature and which ones are used for 
reporting on other type of objects? Is there a rule? Should this not be 
mentioned? I think that most of them and the attributes are for when the 
reported object is actually a signature…but again, text should be added 
to make it clear what elements/attributes are used with what types of 
objects reported.

Line 331: There is no a  DetailedReportType defined. Substitute by 
DetailedSignatureReportType

Line 410: as comment for line 331.

Line 510: Suggest to use one of the RFC that specifies how to represent 
as String a Distinguished Name

Line 505: Suggest starting:” If present, this element indicates…:”

Line 509 and 512, 518: as above.

This is a general comment: there are a number of children optional 
elements, whose description starts:
“This element MAY contain…”. Actually it seems that is saying, it may 
contain this but also may contain other things….I would suggest to start 
their description with: “If present this element [contains / indicate ] ….”


Line 536: Why SignatureAlgorithm in CertificateContentType is of type 
dss:DetailType? Would not be an URI (or a String, as the algorithm for 
the certificate is given as an OID) more suitable ?

Line 538: Suggest change the <Validity> tag to <ValidityPeriod>….we are 
dealing with Validity elements that refer to the status of things, and 
this element is just for the period when the certificate may be used.

Line 558: see my former comment for line 510.

Line 540: <Extensions>. The document allows to include extensions but 
does not define any…which I think is OK given the fact that there are so 
many extensions…but then, we may end up with different ways of reporting 
on certificate extensions…. Is it really necessary to include such 
extensions to the report of the certificate?. Anyway, I think that text 
explaining that this element is for reporting on the extensions found, 
is missing.

Line 717: CertificatePathValidity for a CRL. First, some text should be 
added making it clear that the path is the path for the signing 
certificate of the CRL. Second, I think that this element brings 
recursivity….
Imagine that we have the following trust framework: RootCA -> LevelACA 
-> LevelB CA -> signer.
We have four certificates: RootCACert, LevelACACert and LevelBCACert.
We have three CRLs: RootCACRL, LevelACACRL and LevelBCACRL.

The LevelBCACRL has as certPath: LevelBCACert, LevelACACert, RootCACert. 
The <CertificatePathValidity> element would include details on these 
three certificates-

The LevelACACRL has as certPath: LevelACert, RootCACert, which are 
present in the former one. What is the point in repeating that this path 
is OK if this has been already said?

Line 747: <Signature>. If this element is for indicating the algorithm 
of the signature, I would propose to name it differently. This name 
seems a bit misleading….  In addition to that, would not a String be 
enough for an algorithm identifier (OID)?
Line 740: I have the same concerns with the CrlExtensions than with the 
certificate extensions.

Line 776: same comment as to line 717.

Line 815, 865: same concern for OCSP extensions than for CRL extensions 
and certificate extensions.

Line 861, 863: suggest referring to the OCSP RFC 2560 section 2.4 for 
specifying what comes there.

Line 923: Not sure of making distinctions between 
SignedSignatureProperties and SignedDataObjectProperties. This is a 
rather XAdES oriented classification of properties that CAdES does not 
have, for instance….

Line 951 and the following: would not it be better to just use ref 
mechanisms in this piece of XML schema: <element 
ref=”xades:SigningCertificate”> and so on, as it seems that this element 
will be filled with the corresponding properties of XAdES or attributes 
from CAdES?...and by the way, have we checked that the CAdES attributes 
map so immediately in XAdES properties?... I would say that 
transposition of most of them is not difficult, but maybe we should make 
a careful double check…

Line 1016, 1056: same as before.

Line 1314: same concerns for attr cert extensions as for other extensions.

Line 1225: See my comment on whether the <certificatePathValidity> has 
to be mandatory or not applied to other validation data objects.