dss-x — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Comments to the individual report profile
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]