[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ProcessingOptions example and discussion
Ed, Now that you are on the DSS list can I kick off discussions on this example with two thoughts (I am working extra hard today :-) a) Do we envisage the DSS to define other complex operations such as verify and countersign, extend signature with validation data, archive time-stamp. Would these be defined in the core or as part of the profiles? If these are defined in profiles, how do we avoid similar operations being redefined. I particularly see there is significant overlap between compound operations for EPM and XAdES profiles. b) If we have compound operations that involved sign & verify. Which of the current request - response protocols does this come under? Or do we want a single message structure for all the different operations and use processing options to also control the basic operations? Nick PS. Ed, Can you confirm that you get a second copy of this message through the DSS list. > -----Original Message----- > From: Edward Shallow [mailto:ed.shallow@rogers.com] > Sent: 17 August 2003 23:18 > To: 'Trevor Perrin'; Cruellas@ac.upc.es; 'Nick Pope' > Cc: Gray Steve > Subject: ProcessingOptions example and discussion > > > Nick, Juan-Carlos, and Trevor, (... please post, tks) > > Based partly on Trevor's feedback on the timestamp types post, > 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> > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]