[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [dss] RE: ProcessingOptions example and discussion
Forwarding in case message has not got through to the list. Nick -----Original Message----- From: Edward Shallow [mailto:ed.shallow@rogers.com] Sent: 03 September 2003 21:16 To: 'Trevor Perrin'; 'Tim Moses'; 'Nick Pope'; 'OASIS DSS TC' Subject: RE: [dss] RE: ProcessingOptions example and discussion On the subject of ProcessingOptions, the recent discussions seem to be narrowing (and complicating) the original envisioned scope of the ProcessingOptions construct. The 1st memo below, which provides more insight into its intended use, never made it to the list. It was sent to Trevor, Nick, and Juan-carlos on the 15th of August. Now that I have an account, I'm cc'ing the list for your review. The 2nd has been attached for convenience. The 1st memo started off with a series of scope questions which were felt to have a direct bearing on the scope of the "ProcessingOptions" and its evolution. Only Trevor has responded todate. I do not think we have consensus on the responses to these questions as yet. The memo then goes on to describe a concept and recommended starting point for the "ProcessingOptions" construct. I was tasked at the face-to-face with doing that. May I suggest that feedback and rebuttal use this tabled suggestion as a starting point. I contend that the user should not be concerned with whether an operation is compound or not, but rather simply "What do you want done ?" and secondly "What processing and output consequences result from that request ?". The "ProcessingOptions" construct plays a pivotal role in allowing the user to specify in a straightforward way "What they want done". I also agree with Trevor that this expression of desire should only be required if it is an exception or override to the default profile handling. I disagree that default profile handling eliminates the need for the request construct entirely, that is why we have minoccurs="0". In fact, as my suggested schema shows, the collection of "ProcessingOptions" goes a long way to actually expressing not only the default profile handling, but also the profile-specifc extended handling and represents a tangible manfestation of core and extended profile handling. See XML below. I disagree violently to the suggestion that we don't need a framework for "ProcessingOptions" handling. If a particular ProcessingOption entails the execution of more than one operation, so be it. If it acts solely as a directive to the server, so be it. It is still simply a "ProcessingOption", and we definitely need a framework for handling them. Awaiting feedback and responses on the "Scope Questions" and the "ProcessingOptions" schema below. Ed Here is the 1st memo ... ******************** Here is some input and a discussion framework on "ProcessingOptions" aka CompoundOperations (bad), aka StackedOperations (bad), aka ExtendedProcessing (O.K.) concept ... broken down by topic category. You can break this up and post the pieces individually if you prefer, in order to focus the feedback. One of the more important relationships that exist and influences the "ProcessingOptions" notion is the one which exists with TimeStamping. I will ask for clarification on a few scope issues before proceeding into the ProcessingOptions discussion. Scope Questions *************** 1) If one agrees that there could exist more than one type of a timestamp, which types of timestamps is DSS intending to support ? As a starting point, and in the absence of any suggested references todate, may I be so bold as to use the ETSI 101 903 definitions as a basis for the question ? Please refer to the ETSI document for detailed descriptions, sections included. a) AllDataObjectsTimeStamp - a "content" TimeStamp produced before signature creation over the sequence of all ds:References (this excludes the SignedProperties), it itself is an optional SignedPoperty (see 7.2.9, and another TimeStamp variation called IndividualDataObjectsTimeStamp covered in 7.2.10) b) SignatureTimeStamp - with this timestamp the input for the timestamp hash computation is the ds:SignatureValue XML element, produced after signature creation c) XAdES-T TimeStamp - timestamp computed over the entire XAdES (or DSS equivalent in our case) structure itself d) There are 2 alternate forms of XAdES-X which can be used and are as follows: d1)SigAndRefsTimeStamp - as per SigAndRefsTimeStamp element definition (see 7.5.1) d2) RefsOnlyTimeStamp - for this type, the hash sent to the TSA will be computed then over the concatenation of CompleteCertificateRefs and CompleteRevocationRefs elements (see 7.5.2). Offers easier manageability and performance e) Archive TimeStamp - timestamp computed over entire XAdES-X-L Discussion and Concept Recommendation ************************************* The "Update" and/or "Refresh" protocol discussions are clearly in the same domain as much of the above. In fact one of the main thrusts of 101-733/903 was to ensure the validity of signatures over long periods of time. Given that the "Update" operation is intended to re-produce this desired validity, it behooves us to take a closer look at the afore-mentioned standard. Now to bring the discussion back full circle to how all this relates to "ProcessingOptions", I contend it would be a mistake to have users specify what TimeStamp type they want in their requests as part of Signed/UnSigned Properties structure. Rationale being, they will invariably tend to get it wrong (i.e. ask for attributes of a certain type thinking that this will result in a timestamp of a certain type. This will just cause excessive server-side validation. The make-up of the QualifyingProperties element (i.e. Signed and UnSigned Properties) should be the "result" of DSS processing and not input to it. After all, these elements were loosely borrowed from the element make-up and layout of resultant signature standards which we are using within our "request" structure. A quick review of 101-733/903 shows the specific structure layouts and dependencies for each TimeStamp type. Their makeup is standardized and involves multiple output parts. Please refer to document. A better approach IMHO is to have the user specify what kind of a TimeStamp or Update they want as a simple boolen flag or directive in the ProcessingOptions enumeration. The DSS server would then simply honour the request responding with the "appropriate" return structure reflecting the specific nature of the TimeStamp requested and not what the user thinks the structure is. This might even do away with the need for a separate "Update" or "Refresh" operation. Some example sub-types of ProcessingOptions might run as follows: "IncludeContentTimeStamp" (a synonym of the ETSI's AllDataObjectsTimeStamp), or "ProduceValidationDataRefsTimeStamp". As a thought, we might simply decide to refer to/import the ETSI 101 903 namespace qualifier "htttp://uri.etsi.org/01903/v1.1.1#" for the above names and use ETSI's element names as is. Clearly we could look at the subset required by the European Directive to make our lives simpler. On another "ProcessingOptions" related subject, the EPM also uses "ProcessingOptions" for specifying what Info to Return. DSS already has this covered with "OutputOptionsType", that is fine. However, I see an overlap emerging between "ProcessingOptions" (more general) and "OutputOptions" (more specific). For example when a TimeStamp is returned as a separate artifact, which is the case for certain types, is the user not just simply requesting output ? Possibly. We saw this more clearly and succinctly expressed as firstly "What do you want done ?" and secondly "What output consequences result from this request ?". When you look at it this way, all directives to the DSS service to support the primitive verb go in "ProcessingOptions", and then the DSS Service will return appropriate and consistent output structures, a much simpler approach from the user's viewpoint. I am not suggesting doing away with "OutputOptionsType" altogether, but rather making sure that if optional output is a direct consequence of a supporting "ProcessingOption", then it should be requested via "ProcessingOptions". The same rationale applies to Signed and Unsigned Properties. That is, "Don't have users specify output structure" and "Don't have users specify what they want performed in too many different places". We have at least 3 separate places where users must specify "What they want done". At the risk of lecturing, I invite everyone to read up on ETSI 101 903 and its overall defintion of TimeStamp types and handling approach as well as its Signed and Unsigned Property structures. This 2nd memo followed shortly thereafter ... ***************************************** Based partly on Trevor's feedback to the above, as well as the need to start getting down to examples, here is a mock-up of how to take advantage of the ProcessingOptions request structure. I will follow this up (soon I hope) with some response structure samples that get impacted. Additonally I have shown how it might be extended for the EPM profile. Please treat as a sample for now, and not an official EPM profile submission. This approach allows for defaulting and easy profile extension. As stated in my previous post which discussed timestamp requesting, a clearer separation and prority is given to "What you want done ?" versus "What you want returned and where to put it". Requesting a timestamp belongs in the former. Deciding what it looks like and where it goes is the responsibility of the DSS implementation. This will avoid incorrect specification of timestamp details and simplifies the request structure. Other uses beyond compound operations are also shown below. This is consistent with the more general definition I have submitted. There is a loose categorization shown below which could be formalized into the schema if people prefer. However if it confuses rather than clarifies, then I see no need. Options could also be separated by primitive if desired (e.g. Sign options, Verify options, etc ...). Again, this is a subjective "clarity and succinctness" question. Cheers, Ed P.S. It was agreed that primitives outside the scope of DSS will never find there way into any DSS profile (e.g. Encrypt, Decrypt, StartLifecycle, etc ..). However, if an implementation wishes to extend an existing primitive (e.g. Sign, Verify), it is free to do so within the implementation-specifc profile extensions. This is evident in the examples below. <xs:element name="ProcessingOptions" type="ProcessingOptionsType" minOccurs="1"/> <!-- This is the base type upon which core is built --> <xs:complexType name="ProcessingOptionsType"> <xs:sequence> <xs:element name="UtilizeDefaults" type="xs:boolean" minOccurs="0"/> <!-- explicitly stated, mutually exclusive with all other options --> <xs:element name="IncludeContentTimeStamp" type="xs:boolean" minOccurs="0"/> <!-- PKCS7/CMS and XML --> <xs:element name="IncludeSignatureTimeStamp" type="xs:boolean" minOccurs="0"/> <!-- XML only, essentially an XAdES-T --> ... <!-- could be more, TBD --> <xs:sequence </xs:complexType> <!-- This is a draft sample of the EPM profile extension which inherits then extends the base --> <xs:complexType name="EPMProcessingOptionsType"> <xs:complexContent> <xs:extension base=ProcessingOptionsType> <xs:sequence> <xs:element name="UtilizeProfileDefaults" type="xs:boolean" minOccurs="0"/> <!-- TimeStamping Options --> <xs:element name="IncludeTimeStampXAdES-X" type="xs:boolean" minOccurs="0"/> <xs:element name="IncludeTimeStampXAdES-X-L" type="xs:boolean" minOccurs="0"/> <xs:element name="IncludeTimeStampXAdES-A" type="xs:boolean" minOccurs="0"/> <xs:element name="ReturnDetachedTimeStampToken" type="xs:boolean" minOccurs="0"/> <!-- Applies to PKCS7/CMS only, could also be in core --> ... <!-- Additional Crypto Operations Options --> <xs:element name="VerifyCertificate" type="xs:boolean" minOccurs="0"/> <!-- Normally True, but can be used to suppress CRL/OCSP check --> <xs:element name="EncryptThenSign" type="xs:boolean" minOccurs="0"/> <!-- For confidentiality, encrypt content to be signed --> <xs:element name="DecryptIncomingEnvelope" type="xs:boolean" minOccurs="0"/> <!-- Used on Verify only --> ... <!-- Receipting Options --> <xs:element name="IssueProofOfPossessionReceipt" type="xs:boolean" minOccurs="0"/> <xs:element name="IssueProofOfSubmissionReceipt" type="xs:boolean" minOccurs="0"/> <xs:element name="IssueProofOfDeliveryReceipt" type="xs:boolean" minOccurs="0"/> <xs:element name="IssueCertificateOfVerificationReceipt" type="xs:boolean" minOccurs="0"/> <xs:element name="IssueCombinedReceipt" type="xs:boolean" minOccurs="0"/> ... <!-- Lifecycle Control Options --> <xs:element name="StartLifecycle" type="xs:boolean" minOccurs="0"/> <xs:element name="EndLifecycle" type="xs:boolean" minOccurs="0"/> ... <!-- Return Additional Info Options --> <xs:element name="ReturnExtendedStatusInfo" type="xs:boolean" minOccurs="0"/> <!-- Returns extended status info and info from TSA, OCSP--> <xs:element name="ReturnValidationDataAsText" type="xs:boolean" minOccurs="0"/> <!-- Returns human readable OCSP response --> <xs:element name="ReturnSignatureInfo" type="xs:boolean" minOccurs="0"/> <!-- Returns selected signature attributes separately --> <xs:element name="ReturnCertificateInfo" type="xs:boolean" minOccurs="0"/> <!-- Returns selected cert attributes separately--> ... <xs:sequence> <xs:extension> <xs:complexContent> </xs:complexType> -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: September 3, 2003 11:16 AM To: Tim Moses; 'Nick Pope'; OASIS DSS TC Cc: Ed Shallow At 10:36 AM 9/3/2003 -0400, Tim Moses wrote: >Colleagues - OK. Let's get a list of compound operations before we >decide how to deal with them. If there are three primitives (V,S & T) >and if it is not valid to repeat an operation and if it makes no sense >to do V anywhere but as the first operation, then there are four >possible dual-operations and two possible triple-operations (see >below). I don't think it makes sense for us to say which of these are >invalid: someone may one day want to do any one of them. We should >simply provide the framework in which one could do any one of them. All the best. Tim. > >Here they are ... > >VS, VT, ST, TS, VST, VTS. I like this approach. I would contend that ST and TS are just instances of the Signing Protocol - they're producing a signature that contains some sort of TimeStamp. But the client may not need to explicitly request the signature, or he may request the signature just by passing an "ApplyTimeStamp" boolean. I would not call such a simple technique a "compound operation". I also contend that T should be a profile of the signing protocol, as I've argued before. So if we can use S* for (S, T, ST, or TS), then the only "compound operation" is VS* - first verify, then update/ refresh/ augment/ whatever the signature. So I'd argue we don't need a general framework for compound operations, we just need to support this *particular* compound operation. This simplifies the problem. Do people agree? Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]