[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: FW: [dss] OASIS DSS - SignatureObject on Input
At 01:34 PM 9/16/2004 -0400, ed.shallow@rogers.com wrote: >OK lets get crunchy. You concede we need change, let's get down to exactly >what we have to change. > >Edward Shallow wrote: >> >> >> >>-----Original Message----- >>From: Trevor Perrin [<mailto:trevp@trevp.net>mailto:trevp@trevp.net] >>Sent: September 16, 2004 3:13 AM >>To: <mailto:ed.shallow@rogers.com>ed.shallow@rogers.com >>Subject: Re: FW: [dss] OASIS DSS - SignatureObject on Input >> >>At 05:30 PM 9/15/2004 -0400, >><mailto:ed.shallow@rogers.com>ed.shallow@rogers.com wrote: >> >> >>> >>>Before we proceed , some background. >>> >>>I assumed we all agreed that ReturnUpdatedSignature on the Verify when >>>in fact we are not even doing a Verify is too fundamentally >>>inconsistent and is a semantic mortal sin. I also assumed that we had >>>consensus on performing timestamps of existing signatures on the back >>>of the Sign protocol. I'll send you the list links if you can't find them. >>> >> >> >>I don't mind signing signatures. I mind digging a new trench in the >>protocol just for this. Signing a signature should be like signing anything >>else. >> >Decision 1: The notion of timestamping signatures which do not require >verification, utilizing the Verify protocol with ReturnUpdatedSignature is >dead. The Sign protocol, or better the Timestamp profile of the Sign >protocol, can legitimately timestamp inbound signatures thus producing >what is by definition a signature timestamp. Agreed. > This capability is not mentioned anywhere in either the core or > Timestamp profile and must be added to the text of the core directly, or > at a minimum mention it and refer off to the Timestamp Profile for details. Okay. >>>>>Trevor, >>>>> >>>>>As it applies to the "timestamp this CMS signature please" scenario, >>>>>your suggestion works technically (although it is much messier for >>>>>you and the protocol), but not semantically. Both the request and the >>>>>response are just >>>>>CMS/PKCS7 SignedData signatures. If one assumes that this is all >>>>>driven by an AddTimestamp optional input and the SignatureType is >>>>>RFC3161, then why would the client be sending in more than one >>>>>signature/document ? Hence <SignaturePlacement> and <WhichDocument> >>>>>are superfluous in the CMS scenario. For XMLSig everything is fine. >>>>>However, the AddTimestamp optional input section could use some >>>>>beefing up in the XMLSig area as well. >>>>>Examples: If the AddTimestamp attribute specifies a content >>>>>timestamp, then SignaturePlacement should be used; If the >>>>>AddTimestamp attribute specifies a signature timestamp, then the >>>>>timestamp will be placed in the same document as the signature, and >>>>>SignaturePlacement should be be used to specify the exact placement >>>>>(i.e. XpathAfter). This whole timestamp area should be clarified for >>>>>both CMS and XMLSig. >>>So this does not get lost in the shuffle, will you be improving the >>>text here ? >>> >> >> >>I wasn't planning on it. With <AddTimestamp> the server sticks a time-stamp >>on the produced signature. The client can control the time-stamp only by >>specifying a "Type" URI (a profile could define URIs for content timestamps, >>signature timestamps, etc). >> >>In other words, optional inputs like <SignaturePlacement> don't control the >>time-stamp, they control the "primary" signature. >Absolutely wrong. In the case of a request for a Timestamp, which by the >way is on the Sign protocol, the timestamp (signature) IS the primary >signature. In your own words ... In the case of <AddTimestamp>, the timestamp is the secondary signature. Your request, I thought, was to add text about using <SignaturePlacement> with <AddTimestamp> to apply to the 2ndary signature. I pointed out that <AddTimestamp> doesn't apply to the 2ndary signature, but to the primary one. >"... In the Sign case, the server is treating the signature as just a data >element to be signed..." We need to be careful to distinguish: - Use of <AddTimestamp> on a Sign Request to produce a signature timestamp as a secondary signature - Use of timestamp profile to produce a signature timestamp as a primary signature >Now the text is totally void on this subtlety because it is void on the >whole subject of signature timestamp !!! > >When are you going to concede that the core doc needs fixing? I agree this is subtle and not mentioned. Adding text to explain things is fine with me. >> You're proposing that the >>client can use optional inputs to control the time-stamp as well. >> >No I'm not. If I remember correctly all I asked was that you provide >better support AND text for signatures on Sign (i.e. Timestamp) requests. >Essentially, either add SignatureObject (preferred), or add text which >officially legitimizes use of the Document w/ MimeType >"application/pkcs7-signature" claiming it was always there, because it is not. >> >>Controlling multiple signatures in a single Request would get complicated, >>which is why we've specified only a minimal, simple form of it with >><AddTimestamp>. >> >You are not controlling multiple signatures. It is fundamnetally a simple >sign whose scope is part of the incoming thing as you call it. At this point we're talking about different things. I was responding to your request under "Examples:", above, not your proposal as a whole. [...] >> >Decision 2: DocumentWithSignature only addresses XML and must be >generalized if you are advocating returning the timestamped signature this >way. Additionally the text must reflect the rationale as to why this >generalization exisits. Agreed. >>>2) Add SignatureObject as a valid optional input element as suggested. >>> >> >> >>Like I've said, I'd prefer to handle to-be-signed signatures like any other >>to-be-signed element. >> >> >> >>> >>>Issue: The problem with current spec if that there isn't sufficient >>>generalization of a base Document, or consistency across usage scnearios. >>>We have documents, we have signatures, and we have documents with >>>signatures, Documents can only be used on input, DocumentWithSignature can >>>only be used on output, SignatureObject can only be used on output. >>> >> >> >>Sounds fine to me. Except that currently <DocumentWithSignature> can only >>be XML, so we should extend it to contain the same things <Document> can. >> >Decision 3: Change DocumentWithSignature to be a subclass of Document so >as to pick up the choices. >P.S. What I was suggesting earlier, is to simply collapse >DocumentWithSignature and use Document. The flexibility of MimeType >already supports your arbitrary separation of these 2 elements. Then you >have a nice simple setup where your only dealing with Documents and >Signatures. Due to all the optional choices and attributes of >SignatureObject, I agree we should resist a more total collapse. The only >down side is that you have the possibility of signatures in both >constructs. But at least it is down to 2 instead of 3 possible vehicles. Maybe we should have a DocumentType, which <Document> and <DocumentWithSignature> are both instances of. The problem with just using <Document> as an optional output, is it might become ambigous which optional input this corresponds to (say some other profile wants to return a <Document> optional output). So calling it <DocumentWithSignature> makes its semantics clear, and ties it to the the <SignaturePlacement> input. [...] >> >Decision 4: See above. I vote for a partial collapse eliminating >DocumentWithSignature which is already handled admirably bu Document. In >the real world a document is a document regardless of whether it is signed >or not. The signature is in fact just an attribute (read MimeType) which >qualifies the Document. It is not an entirely different thing. This is the >beauty of advanced dialects like XML. I vote for collapsing them in contents but not name (see previous). [...] >> >Decision 5: More than not mentioning it to me, you haven't included any >text at all in the core covering this scenario and MimeType use. At least >a sentence or 2 !!! I'll make a text proposal before the next meeting. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]