[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Time-stamping issue closed?
Ed, Thank you very much for your email. The systematic approach that you did is great and I think that is extremelly helpful. You will find my comments intermixed but before some general statements. First of all, I agree with you Ed in the way you propose to split coverage between core and time-stamp (hencforth TST) profile. In the end, the core deals with generation and verification of signatures. The fact that at the same time that we request a signature we may request a timestamp on the signature itself or on the data to be signed is a plus on the protocol: in the end everything will be part of the signature returned. In the verification is similar: if the signature contains a timestamp on itself or on the signed data objects, the server must also verify the timestamps and report... But if I want to merelly get a time-stamp on a piece of data (be this data a signature or a document) for archive or manage such a time-stamp as a separated piece of information, then I should use the time-stamp profile. I do not know if we explicitely arrived to this point, and if not, I think that this deserves some discussion and be recorded in some minutes. Could anybody confirm if this split was explicitely mentioned and agreed?. This makes that I agree with most of the changes you suggest with some remarks that you will find intermixed. Now, you will find some remarks intermixed. Edward Shallow escribió: > General > ******* > > Here is the exhaustive list of permutations and combinations of PROTOCOL > (Sign or Verify), timestamp signature TYPE (CMS or PKCS7), timestamp > signature SCOPE (content timestamp or signature timestamp), and finally > timestamp LOCATION (embedded or standalone). I have traced them back into > the document and illustrated which sections address them or where they are > not addressed. Thanks a lot Ed by this exhaustive list. I think that it clearly depicts the whole issue and serves for assessing the coverage in the core and the profile. > > Here you go: > > PROTOCOL/TYPE/SCOPE/LOCATION Combinations > ***************************************** > > Combination 1 - Sign/CMS/Content/Standalone > > --> covered by the Timestamp Profile but inadequately/poorly explained. The > basic requirement to simply create a standalone timestamp (as covered by the > Timestamp profile) should be referenced in the core. I would this reference > to section 3.4. For example: Users wishing to create a signature whose > SignatureType is a timestamp SignatureType as per section 7.1, should refer > to the Timestamp Profile of this spectification. > > As I said before I agree with Ed's view and in consequence I agree with your proposal of referring readers to the profile. > Combination 2 - Sign/CMS/Content/Embedded > > --> MISSING FROM THE CORE. Should be added to section 3.5.2.1. This has been > done. See below. This option represents a timestamp as an AUTHENTICATED > attribute created BEFORE the act of signing. In essence it is a > SignedProperty of the resultant signature being created as part of this > SignRequest. We could force the user to treat this case by using > <SignedProperties>, but this would be inconsistent treatment given support > for AddTimestamp, would force 2 calls, and would be orthogonal. > I agree in using AddTimeStamp. Just to mention: XAdES profile in fact has a specific request for this type of signature with time-stamp, that allows even, when you want to sign multiple objects with an XML signature, select on which ones you want to get a time-stamp before signing, but this is another story. Briefly speaking, XAdES profiles explicitly deals with the inclusion of time-stamp on both signed data objects and signatures within the signature itself. Mentioning just to remark that time-stamp issues are also covered in XAdES profile. And as I said, I agree with you in the contents of this section. > > Combination 3 - Sign/CMS/Signature/Standalone > > --> covered by the Timestamp Profile but inadequately/poorly explained. If > the user is passing in a DocumentHash whose content was derived from the > signature value of some signature, then they would essentially be creating a > Combination 3. Again this is not adequately explained in the Timestamp > Profile. > > > Combination 4 - Sign/CMS/Signature/Embedded --> covered in section 3.5.2.1 > entitled <AddTimestamp>. Small textual errors require fixing. See below. > Yes... you will see my remarks below. > > Combination 5 - Verify/CMS/Content/Standalone > > --> should be covered by the Timestamp Profile but it is inadequately/poorly > explained. Section 4.1.3 of the Timestamp Profile states that only > DocumentHash should be sent in on a Verify timestamp request. This is > inconsistent and different than what is advocated for timestamp verification > as explained in Section 4.3.2.1 See Lines 1440-1441 where it is advocated > that the orginal data that was timestamped be passed in NOT just the hash. > This is a question of integrity and what the practice of timestamp > verification should or should not entail. I believe what is stated in > Section 4.3.2 is closer to industry expectations. > I think that I also pointed out some time ago the inconsistency you mention. We certainly should modify the profile accordingly, and I also think that passing the input documents for time-stamp verification would be better. > > Combination 6 - Verify/CMS/Content/Embedded --> partially covered in > Section 4.3.2.1 By definition this timestamp is an authenticated attribute > and some integrity would be achieved by simply verifying the enclosing > signature. However the need for the MessageImprint in the timestamp to be > cryptographically bound to the signature hash value should be better > explained in this section. (see my Suggestion in Point 6 and 7 below). > > > Combination 7 - Verify/CMS/Signature/Standalone --> should be covered by > the Timestamp Profile but it is inadequately/poorly explained. > > > Combination 8 - Verify/CMS/Signature/Embedded --> covered in section > 4.3.2.1 > > (Note: There is an equivalent 8 Combinations for XML. I'll send the feedback > separately but the feedback is similar.) > > In general all CMS standalone timestamps (as reflected above) are/must be > addressed by the Timestamp Profile. All CMS embedded timestamps must be > addressed by the core due their close tie with the enclosing signature. > > > Specific > ******** > > Point 1) Add level 4 Headings (e.g. 4.3.2.1) to the Table of Contents. It > presently only shows Headings down to 3 levels (e.g. 4.3.2) Agreed. > > Point 2) Section placement is incorrect. Non-sequitor as follows: > Briefly speaking: what I have realized is that there are no similar sections for CMS signatures as per time-stamp verification steps. Writing a 4.5.1 Timestamp Verification procedure within 4.5 Basic Processing for CMS signatures would imply repeating quite a lot of text, so would it be crazy toextract 4.3.2 and its contents and make it 4.6 Timestamp verification procedure, and then adequate the text so that it actually applies to both CMS and XML signatures?. > 4.3 Basic Processing for XML Signatures > 4.3.1 Multi-Signature Verification > 4.3.2 Timestamp Verification procedure > 4.3.2.1 Processing for CMS RFC 3161 timestamp tokens > 4.3.2.2 Processing for XML timestamp tokens > > 4.3.2.1 deals with CMS yet it is in a section reserved for XML Not exactly: it deals with CMS-based time-stamps, but this type of time-stamps may also be inserted within a XML Signature: in fact, this is what XAdES does!. --->COMMENT ON THE CORE TEXT: line 979: I think that “who’s MessageImprint” should be changed to “whose MessageImprint”. > > Point 3) Add a comment after Line 977 "The optional Type attribute of > AddTimestamp may be omitted if it is the same as the SignatureType. > Agreed. > Point 4) As it pertains to Line 985 starting with "... , the client should > ..." the <AddTimestamp> OptionalInput of the Verify protocol section is > missing from the core document. > I think that what you are pointing out is that in fact <AddTimeStamp> is a COMMON OptionalInput, and that maybe it should be moved in the document and become 2.8.6 and maybe its text slightly modified to fit there. I think that this would be the best and shortest option instead of including a new subsection in the verify profile. Would you agree on that? > Point 5) Line 980 remove "passed in on the request" and replace with "just > created" I agree with this change. My understanding is that with this change you are saying that a SignRequest with an AddTimeStamp is actually a request for generating a signature and adding a time-stamp within it (whether on the signature itself or on the signed data object(s)). I agree with this view, but then, another change must be done in this section: --->The text in lines 960-961: "..as a property or attribute of the resultant signature (VerifyRequest) or the supplied signature (SignRequest)." should be changed to: "as a property or attribute of the supplied signature (VerifyRequest) or the requested signature (SignRequest). " > > Point 6) On Line 1458 remove "If the timestamp is a standalone content > timestamp, then simply verify it." replace with "Similarly if the timestamp > is embedded as an authenticated attribute and represents a content > timestamp, extract the timestamp token and verify it." Agreed. > > Point 7) Line 1439-1441 remove "additional data passed ... Right up until > the end of the paragraph" and replace with "content that was used to derive > the MessageImprint hash value. The content timestamp which is embedded as an > authenticated attribute has a MessageImprint value that was derived from the > eContent of the signature itself." > I agree on the whole idea: we leave the core for dealing with embedded time-stamps in the signatures. But in my opinion the "eContent" mention makes this text applicable only for CMS signatures, while I think that we could try to write text applicable for CMS and XML signatures embedding timestamps. My proposal would be leave your text as you propose except by substituting: "eContent of the signature itself." by: "eContent if the time-stamp token is embedded within a CMS signature, or the corresponding signed data object(s) referenced in <ds:Reference> element(s) if the time-stamp token is embedded within a XML signature." > Point 8) Line 1434 change "CMS RFC 3161 timestamp tokens" to "CMS RFC 3161 > embedded timestamp tokens" The reason for this change is the assumption that > all treatment of standalone timestamps is dealt with in the Timestamp > profile. > Agreed. > Point 9) Line 1468 remove "For a content timestamp, this data must be passed > in as a separate InputDocument." and replace with "For a content timestamp > which is embedded as an authenticated attribute, this data is the eContent > of the enclosing signature. The special case where the enclosing signature > is detached is not directly supported by the core. It is felt that it would > be unlikely that a signature would contain an embedded content timestamp yet > leave the signature content detached from the signature itself. This > scenario could be addressed by a profile. > As before, I would suggest to sligthly change your text for covering both CMS and XML enveloping signatures.... "For a content timestamp which is embedded as an authenticated attribute, this data is the eContent if the enclosing signature is a CMS one, or the corresponding signed data object(s) referenced in <ds:Reference> element(s) if the enclosing signature is a XML one." I guess that you would also suggest delete the last sentence of the paragraph: "Thus verification of "content timestamps" requires two inputs, the timestamp token and the original data that was time stamped". wouldn't you? Regards Juan Carlos. > Cheers, > Ed > > P.S. I guess I should volunteer to fix up the Timestamp Profile, but I'll > wait for the next call to discuss this. > > > -----Original Message----- > From: Nick Pope [mailto:pope@secstan.com] > Sent: January 23, 2006 1:04 PM > To: Nick Pope; Ed Shallow; Juan Carlos Cruellas; Konrad Lanz > Cc: Stefan Drees; OASIS DSS TC > Subject: RE: [dss] Time-stamping issue closed? > > Major apologies to Stefan - I mean to say: > > Stefan has NOW updated the Core with the restucturing of the Core as > discussed at the last meeting. Can you confirm that this now closes the the > Time-stamp issue. > > > Nick > >> -----Original Message----- >> From: Nick Pope [mailto:pope@secstan.com] >> Sent: 23 January 2006 17:56 >> To: Ed Shallow; Juan Carlos Cruellas; Konrad Lanz >> Cc: Stefan Drees; OASIS DSS TC >> Subject: [dss] Time-stamping issue closed? >> >> >> Dear All, >> >> Stefan has not updated the Core with the restucturing of the Core as >> discussed at the last meeting. Can yu confirm that this now closes >> the the Time-stamp issue. >> >> Nick Pope >> Mob: +44 (0) 777 567 2590 >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]