OASIS Open Mailing List Archives  ·  All Lists  ·  dss-x  ·  2009-03

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]