Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS

[Trevor Perrin <trevp@trevp.net>]

Forwarding from Ed -

>Date: Wed, 09 Jul 2003 12:13:36 -0400
>
>Trevor, ... (please post to list)
>
>    Carlisle's "Corporate Seal" 2.1 and "Identified Requestor" 2.3 use cases
>are closely related, as he states in the use-case itself. The value is
>definitely coming from an "inside (the corporation) looking out"
>perspective. The Government of Canada also saw this value and requested the
>S2S EPM. This is the subset of the EPM I spoke of that actually uses the
>"External Sign" operation described in our WSDL. This Sign however was
>mandated (by the Canadian Security Establishment (CSE), one of only 2
>FIPS-140 certified accreditation labs in North America) to take place
>"within" the departments' of the GoC using departmentally-held and keying
>material. Each department within the government was mandated to use "their
>own" internally-controlled and deployed "Corporate Signing" service (using
>the EPM S2S Sub-Service of the Government Secure Channel as the vehicle).
>
>    In my opinion, this description above is what Carlisle seems to be
>alluding to. This very much constrained and controlled definition of
>"delegated signing" we would condone. Your description of "delegating
>signing" is an enormous leap from the above definition. I wonder what
>Carlisle originally envisioned ?
>
>    To take this all the way out to a definition where some 3rd party DSS
>signing service "holding the private keys of the corporations' of America"
>is what we find totally off the mark.
>
>    Perhaps this is once removed from the protocol itself, but a huge leap
>from one to the other.
>
>    I invite you to clarify Carlise's and the team's intent and see if it
>coincides with ours.
>
>Ed
>
>
>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: July 8, 2003 7:58 PM
>To: Edward Shallow; 'Gray Steve'
>Cc: roger.mccune@canadapost.ca
>
>
>you'll have to hunt for my responses, sorry-
>
>At 05:22 PM 7/8/2003 -0400, Edward Shallow wrote:
>
> >Her goes another round ... Your arguments will have to be brought down
> >to ground level where facts can be used to resolve differences. See
> >responses intermixed as <ed> ... </ed>.
> >
> >Steve, please post to list.
> >
> >Ed
> >
> >
> >-----Original Message-----
> >From: Trevor Perrin [mailto:trevp@trevp.net]
> >Sent: July 8, 2003 12:15 AM
> >To: Edward Shallow; 'Gray Steve'
> >Cc: roger.mccune@canadapost.ca
> >
> >
> >These are good things to debate, I wouldn't mind doing it on the list
> >where more people could observe and join in, if you wanted to take it
>there..
> >
> ><ed>Yes ... Go ahead and post these exchanges to the group.</ed>
>
>I'll wait for Steve to post, then follow-up.
>
>
> >At 11:13 PM 7/7/2003 -0400, Edward Shallow wrote:
> >
> > >Trevor,
> > >
> > >      Some high-level comments, so don't have to wade thru the document.
> > >
> > >- you have not as yet addressed the fundamental scope question as to
> > >whether non-repudiation is in or out.
> >
> >I hope you saw my mails of the 3rd, which made a stab at answering that:
> >http://lists.oasis-open.org/archives/dss/200307/msg00019.html
> >http://lists.oasis-open.org/archives/dss/200307/msg00020.html
> >
> >I think that question doesn't pertain to DSS.  DSS is a protocol that
> >supports many different use-cases, and could be deployed in many
> >different systems, in many different legal regimes, to produce many
> >different types of signatures, that accomplish many different goals.
> >
> >In some of these contexts, DSS-created signatures may be
> >non-repudiable.  In others, they may not.  DSS addresses only the
> >mechanics of delegated signing/verifying, and does not mandate that the
> >signatures created or verified have any particular meaning.
> >
> >So while certain profiles of DSS, and some systems that build on DSS
> >like EPM, may take non-repudiation into account, by mandating
> >authentication and key management technologies that are compliant with
> >particular legal regimes, and archiving data in a prescribed manner,
> >and so on, I think DSS aims only to create Signing and Verifying protocols
>that address:
> >INPUT: document
> >OUTPUT: signed document
> >and
> >INPUT: signed document
> >OUTPUT: yes/no
> >[this is an over-simplification]
> >
> >In other words, DSS is a building block, it's not a whole building like
> >EPM is.  I think NR is a "holistic" property that depends on an entire
> >architecture and the legal context it's deployed under, and it doesn't
> >make sense to ask whether DSS by itself achieves that property.  DSS
> >could be part of a system that achieves that property, but it doesn't have
>to be.
> >
> >Asking whether DSS supports NR is like asking whether TCP/IP supports
>email.
> >TCP/IP handles packets.  DSS handles signatures.  What these packets or
> >signatures accomplish in higher-level protocols and systems is out of
> >scope to the lower-level protocol.
> >
> ><ed>
> >I like your analogy, but I will use it to support my argument. If the
> >DSS foundation stays at the TCP/IP level then you will be forcing the
> >various profiles up into the TCP/IP payload or body. In SOAP's
> >request/response RPC encoding style (or even in SOAP's document-literal
> >style) you must define the XML structure of your requests and
> >responses. One cannot compose a WSDL leaving the payload largely
> >freeform. This is what you will end up doing and the profile specifics
> >may seem to you to be transparent to DSS, but they won't be to the
> >implementor. They must be defined right down to the primitive SOAP or
> >schema data types. Each profile definition will end up right in the
> >body the DSS strcuture, possibly selected via <choice> or identifer
> >constructs. Contrary to your assertion, you will create a confusing and
> >unmanageable profile inventory, which in the end will be too
> >overbearing and confusing to use. Not to mention the endless profile
>updates you will staddle the team with.
> ></ed>
> >
> >
> > >  If the business acts of signing and verifying have no larger
> > >motive, then what is another low-level protocol going to do to add
> > >value and increase adoption ?
> >
> >There currently do not exist client/server protocols for creating and
> >verifying digital signatures, or for XML timestamps.  DSS is going to
> >define these.
> >
> ><ed>
> >Not entirely true. RFC3161 timestamping describes the request and
> >response structures in their entirety. Shipping the request and
> >receiving the response is simply a transport issue. Even status and
> >completion codes are defined. Putting these into HTTP or SOAP is
> >trivial. As for XML rendering of timestamps, I believe Vincent Girier
> >ISSE, as well as Entrust have submitted viable proposals in this area to
>your own committee.
> >Are you intending on recasting or replacing those submissions as well ?
> ></ed>
>
>I don't think we've decided what the XML timestamp format should look like.
>I'm sure we'll take the input documents into account, and maybe adopt one of
>their formats wholesale if it's adequate.
>
>At the moment we're just deciding on requirements and scope.  A standard XML
>timestamp format doesn't exist, so we intend to standardize one.
>
>
>
> >We've identified many use cases where such protocols would be useful.  For
> >example:
> >   - the client wants corporate approval for a document.  The client
>submits
> >the document, and sometime later retrieves the signed version.
> >   - the client doesn't want to carry his email signing key around with
>him.
> >The client stores the signing key at the server and then when he wants to
> >sign an email, sends the hash of the mail to the server and asks the server
> >to apply his key for him.  But these signatures aren't for legal purposes,
> >the client just doesn't want people to spoof his mail.  Similar products
> >exist.
> >   - a notary authenticates clients and then signs, using its own key but
> >inserting the client's name.  Similar products exist.
> >
> ><ed>
> >I don't believe internally-deployed corporate signing services can be
> >described as truly delegated. These signatures would more than likely be
> >created with dedicated crypto infrastructure using corporately managed
> >keying material, and likely NOT be delegated to a 3rd party. These
> >corporations would be infintely more accountable for those signatures. As I
> >have previously stated, we encourage the deployment of a non-logging
> >departmentally-owned version of the EPM "within" the ministries of the
> >government. This we do NOT describe as "delegated signing". The Web Service
> >interface is not exposed outside the deparmental walls. They actually use
>it
> >as a transaction level VPN to authenticate themselves to each other.
> ></ed>
>
>I was giving examples of use cases where a DSS protocol might be useful,
>since you were questioning that.  You're right, some of these things might
>not be described as "delegated signing", DSS has other use cases besides
>that.
>
>
> >   - a corporation doesn't want to give its code-signing key to developers
> >for signing applets and ActiveX controls, and the corporation wants a
>record
> >of when this key is used to sign something, and who requested the signature
> >(I've worked for 2 companies where the private key was on a floppy in my
> >desk, and a lot of other developer's desks as well).  So the corporation
> >hosts a DSS service that the corporation's developers can access to sign
> >downloadable code modules.
> >
> >You've asked similar questions a number of times, about how is DSS going to
> >differentiate itself and add value to pre-existing standards.  But the
> >standards you mention are not request/response protocols for the production
> >and verification of signatures, so I'm mystified by what standards you
>think
> >DSS is redundant with.
> >
> ><ed>
> >I agree that the standards I quoted don't contain transport semantics. But
> >as you know, they do address content and payload formatting, while SOAP
> >addresses endpoints and payload delivery. What is left ?
>
>Protocols for creating and verifying signatures.  I.e., the client wants to
>produce a signature, but for whatever reason doesn't have the ability to do
>so himself and must enlist a server.  Same for verifying.
>
> >  You are now down to
> >a very thin "value" layer. Amongst other thinsg, the EPM does address this
> >"service requesting" you speak of through the basic operations and their
> >options. Why can you not acknowledge that ?
>
>what am I not acknowledging, exactly?  I agree that EPM does some of the
>same things as DSS.  That's why there's overlap, and why we're discussing
>how to rationalize that overlap.
>
>
> >On the specific standards redundancy subject: I've stated at least twice
> >before now, that you are not adequately assessing the SignaturePolicy
> >capabilities within ETSI 101 733/903 and RFC3126.
>
>What would you like to see me/us doing that would make you think we were
>adequately assessing this?
>
> >  Your example below in the
> >paragraph with the Alice@Acme.com reference makes it clear you don't see
>the
> >overlap with the objectives of SignaturePolicy. "this document has been
> >reviewed and approved" is an "intent phrase" or "commitment rule".
>
>Okay.  Then if a DSS server is producing a signature with that intent, in a
>format like XAdES that allows such an attribute, then it should put that
>SignaturePolicy in the signature.
>
> >  Are you
> >going to reinvent SignaturePolicy ?
> ></ed>
>
>No.  The request/response protocol is going to ignore it, like it ignores
>any other signed or unsigned attributes the server chooses to add into the
>signature.
>
>
>
> > >Perhaps the charter itself should be
> > >revisited in this area.
> >
> >You're welcome to propose that to the list.
> >
> >
> > >- if the answer to the first question above is that NR is in, then the
> > >1/3 of DSS' mandate intending to perform "delegated signing" will be
> > >out
> >
> >You claim "delegated signing" is incompatible with NR.  I disagree.  If NR
> >means anything, it means that the client should be held responsible for
> >things signed with the public key.
> >
> ><ed>
> >Things aren't signed with one's public key, they are signed with one's
> >private key.
> ></ed>
> >
> >If this responsibility was contingent on the client's private key
>management
> >practices, then it would be easy for the client to repudiate a signature by
> >claiming lax practices.
> >
> >Example:
> >
> >Alice gives her private key to Bob.
> >Alice signs a contract with Charlie
> >Alice tries to repudiate the contract
> >Alice points out that Bob has her private key.  Thus, since the private key
> >was not in her sole possession, the signature cannot be uniquely assigned
>to
> >her.
> >Alice has successfully repudiated the contract.
> >
> ><ed>
> >Absolutely incorrect. Alice is obliged to notify the Certificate Authority
> >the moment key compromise has taken place.
>
>Right, but in a repudiation attempt, Alice is the *attacker*.  You can't
>trust Alice to protect you from herself.  If non-repudiation depends on
>Alice keeping her private key private, then it's easy for Alice to
>repudiate signatures, and almost impossible for Charlie to prove the
>negative that no-one else ever gained access to Alice's private key.
>
>The only reasonable way to proceed is for Alice to enter some contractual
>relationship where she agrees to assume liability for *anything* that
>verifies with her public key, up to some limit.  In this situation, Alice
>can manage her private key however she wants.
>
>Lest you think I'm inventing things, many reputable crypto-technologists
>have similarly "repudiated" the concept of non-repudiation as being
>unworkable:
>http://www.cryptoapps.com/~peter/part2a.pdf
>http://www.counterpane.com/pki-risks.pdf
>
> >  If she does not, she would have
> >broken a fundamental precept of every Certificate Policy on the planet.
>
>Yup.  And she would have repudiated her signature.
>
> >  She
> >is also obliged by that same CP not to disclose the secret password or give
> >away the keying material, both of which she has done. It is similar to the
> >passport theft scenario, where you are obliged to notify the passport
>office
> >of passport theft the moment you find out. Conscious violation is an
> >extreme, but open and shut case.
>
>Sure.  Alice says "Bob has my private key".  So the signature can't be
>non-repudiably bound to me.  Alice walks away scot-free.  Open and
>shut.  Either that, or the judge says "I don't care, private key security
>is your responsibility", in which case Alice is free to do whatever she
>wants with her private key.  Like store it on a DSS server!
>
>
> ></ed>
> >
> >Thus, if you want NR, you have to hold Alice accountable no matter what she
> >does with her private key.
> >
> ><ed>
> >These obligations to protect your key and secret should not be news to you
>?
> >Clearly if one happens to have a clear disdain for PKI, one might find this
> >objectionable, but that is the current state of this popular technology,
> >which the largest players in the industry are now making pervasive (MS and
> >Adobe).
> ></ed>
> >
> >
> >If she wants to store it on a server and access it there, that's her own
> >business.
> >
> ><ed>
> >She I obliged to keep it under her protective custody. In fact one of the
> >largest PKI supplier's in the world supports a roaming certificate served
> >from a profile server, which they take emormous pains to double encrypt and
> >re-create on the signer's workstation just so they can claim the user signs
> >while in possession of the keying material. I invite you to study the
> >Entrust TruePass architecture.
>
>I'm familiar with these - RSA has a product, SingleSignOn.Net, Arcot,
>IETF's SACRED, SecureComputing, Hushmail.  In most cases the private key is
>encrypted with a password, so it would be easy for the server to
>brute-force, and the claim that the private key is in the client's sole
>possession is debatable.
>
> >  There are other examples of this in the
> >industry which show the clear concern for delegated signing and its obvious
> >weak authentication exposure. Why have a vault if you are going to let
> >people in with a simple weak password.
> ></ed>
>
>It was an Entrust guy who started this TC, and made the initial submission,
>and a different Entrust guy who submitted the Identified Requestor use case
>which you dislike so much.  And a 3rd Entrust guy who just today argued:
>
>"The rationale behind a services-oriented architecture is cost-reduction:
>the
>cost of maintaining complicated clients.  The instant a complicated client
>is deployed, it is wrong.  And the activity of replacing wrong clients is
>costly and unreliable.  Hence, the argument goes, deploy clients that are so
>simple, they can't possibly be wrong, and do the complicated stuff in a
>server setting, where there will be many fewer instances of the function and
>the software environment will be much more stable and predictable."
>
>which pretty clearly explains why a server-side approach has some
>advantages over client-side PKI.
>
>
>
>
> > >- the whole notion and role of profiling will probably lead to
> > >unmanageable permutations and combinations of service and request
> > >options,
> >
> >Disagree.  Different profiles won't affect the protocol itself.
> >
> ><ed>
> >Impossible. WSDL request parameters will have to be affected in order to
> >describe the nuances of each profile pre-requisite.
> ></ed>
>
>dunno what this means.  I don't think the TC has agreed (or disagreed) or
>even discussed whether we're using WSDL, and we probably don't mean the
>same things by profile.
>
>
> >   They'll affect the contents of the signatures that the protocol
>produces,
> >what bindings the protocol is transported over, what external requirements
> >are placed on the behavior of protocol participants (such as having to
> >archive data, or sign using a particular key), and how these signatures are
> >interpreted.
> >
> >TCP/IP doesn't change to take into account new applications.  Rather, it
> >carries a payload and higher-level protocols can stuff different things
>into
> >this payload.
> >
> >Similarly, the signatures DSS carries can have all sorts of different
> >policies and attributes attached to them, and can mean different things in
> >different contexts, and the DSS servers that process these payloads can do
> >all sorts of subsidiary things like archiving them, but the DSS protocol
> >doesn't care.
> >
> ><ed>
> >Once again, you overlap with the "terms and conditions" concepts embodied
>in
> >the SignaturePolicy work of the ETSI.
> ></ed>
>
>No.  DSS will leverage those concepts.  A DSS will produce a
>signature.  This signature might have an ETSI SignaturePolicy inside of it.
>
>DSS is going to standardize a protocol for producing signatures.  We're
>mostly not going to invent new stuff that goes inside these signatures,
>since we can rely on the good work of people like XAdES etc..
>
>This is a hugely important division, and maybe this is the thing I haven't
>communicated well.  From the point of view of the request/response
>protocol, signature contents like SignaturePolicy are opaque.  The protocol
>transports signatures, it doesn't care what's inside of them.  ETSI and
>XAdES stuff and whatever you want can be inside of them.
>
>
> >Whether a DSS signs a document to say "this document has been reviewed and
> >approved",
> >
> ><ed>
> >ETSI 101-733/903 SignaturePolicy CommitmentRules.
> ></ed>
>
>Yes!  That would be a great thing to be inside a DSS-produced
>signature.  You see, we're not as far apart as you think..
>
>
> >  or signs it to say "this document comes from Alice@Acme.com, who
> >authenticated herself to me", or signs it with the client's private key, is
> >a matter of signature contents, it doesn't affect the protocol.  Whether
>the
> >server archives the document in a NR DB, or what key he signs with, or what
> >directories and CRLs he consults for validating cert paths, and so on,
> >similarly doesn't affect the protocol.
> >
> > >  the EPM team
> > >has already lived thru that and has responded with the extensibility
> > >framework described below. We are willing to change and adapt, but
> > >can't condone an approach which will result in dozens of overlapping
> > >and unmanageable profiles.
> >
> >I don't think we want to put profile complexity into the protocol.  Rather,
> >we (or at least I) would like EPM to consider itself as a profile of DSS,
> >for those operations such as Verify and external Sign in which we overlap.
> >
> >In other words, if EPM has the requirement that Verify operations are
>logged
> >in a NR DB, that's fine, but it doesn't affect DSS.  We just define
>protocol
> >messages, and what an EPM service does to handle these messages is your own
> >business.
> >
> >
> > >- if bridging the gap between CMS/PKCS7 and XMLDSIG/XMLENC is DSS'
> > >primary raison-d'etre then my point 4 will have to be delved into much
> > >deeper, because the overlap issue will be way out in front. XMLDSIG can
> > >perform all the internal and external referencing and transformation
> > >one can throw at it. It needs no help in this area.
> >
> >We would like to define a protocol in which clients can request that
>servers
> >produce and verify signatures in the XMLDSIG format.
> >
> >Since this format is complicated, we have to allow clients to say things
> >like:
> >   - sign these 2 URIs, and these 3 elements within this document, and this
> >element within the document which I'm just going to send the hash of,
> >because the element itself is too large (but here's the transforms I
>applied
> >before hashing, which you need to know so you can insert them into the
>final
> >ds:SignedInfo)
> >   - apply these transforms to the URIs, and this transform to this
>element,
> >and so on
> >   - insert the resultant signature at this point in the document
> >   - but don't bother returning the whole document, just the signature,
> >because I'll splice it into the resulting document myself.
> >
> >This is an extreme example, but it shows the complications we have to
> >consider when producing and verifying XMLDSIG signatures.
> >
> >The point is not that XMLDSIG needs "help".  The point is that the protocol
> >aspects of how a client sends data to be signed/verified are complicated
> >because XMLDSIG is complicated, and handling these aspects will be DSS's
> >greatest challenge, and our greatest contribution.
> >
> ><ed>
> >You're in the domain of desktop authoring tools where this signing is
>really
> >taking place. Please familiarize yourself with Microsoft's InfoPath XML
>form
> >authoring tool, as well as Adobe Acrobat's V6 signing framework.
>
>I doubt I have time.
>
> >They don't need to be told how to sign documents, parts of documents,
>hashes
> >of docments, etc ... This is the domain of the authoring tool and subject
>to
> >the ergonomics of its user interface and usage scenarios. Very subjective
> >territory.
>
>I was clearly talking about how a *client* tells a *server* what to sign,
>and communicates the things it wants the server to sign.  This has nothing
>to do with "ergonomics" and user interface, it's a matter of protocol
>design.
>
>
> >P.S. You're too late anyway. See also MS Office 11 Beta and StarOffice 6.x
>
>Too late for what?  Do these define a client/server protocol for creating
>and verifying signatures?  If so, I'd like to know about it.
>
> >
> ></ed>
> >
> >If DSS handles all these mucky details, then EPM and other people can
>tackle
> >the more interesting, higher-level problems of building services that
> >augment the DSS protocol with NR logging and other things.
> >
> > >Detached signatures are academic in the XMLDSIG world. If things get
> > >too complex, one can simply break it apart with the EPM's Lifecycle
> > >support. This is where the EPM delegates to XMLDSIG and isn't trying to
> > >re-invent it's non-XML conterpart,
> >
> >We aren't trying to reinvent XMLDSIG, we're trying to support it.  You keep
> >comparing DSS to things like XMLDSIG, or XAdES, but those are inputs and
> >outputs to the DSS protocol, they aren't comparable to the protocol itself.
> >
> ><ed>
> >You are being inconsistent. You earlier stated applying transforms to URIs
> >and signature insertion were part of DSS' strongest offering ? Do you not
> >think XMLDSIG can address these requirements ?
>
>You misunderstood me.  The client has to tell the server which transforms
>to apply to input documents, and where to insert the resultant
>signature.  In other words, the client has to tell the server what type of
>signature to produce.
>
>We're not inventing our own way of doing transforms or inserting signatures
>into documents, we're inventing ways of a client telling a server how to do
>that.
>
>
> ></ed>
> >
> >   I don't know where you get the idea that DSS is competitive with
> >pre-existing signature formats.
> >
> > >  that capability is simply
> > >progress and is how complexity will be handled under complex
>circumstances.
> > >The DSS can benefit from learning to appreciate the relative strengths
> > >and weaknesses of the XML and binary approaches and not attempt to get
> > >both to accomplish the same job.
> > >
> > >      What does that comfortably leave DSS with in terms of defensible
> > >scope ? ... Perhaps a server-side Verify ?
> >
> >The 3 things mentioned in our charter, I still think.
> >
> >
> > >     I still contend the DSS team has a fundamental scope delineation
> > >problem which it needs to work through. However, the offer to start
> > >where the EPM leaves off is still being extended. Perhaps in the
> >face-to-face.
> >
> >What do you mean "start where EPM" leaves off?
> >
> >My preferred relationship would be for EPM to view itself as a profile of
> >DSS, for those operations where we overlap.  As for those operations where
> >we don't overlap, EPM is on its own.
> >
> >It seems the disagreement is that you think we should expand our charter to
> >include all of EPM ...
> >
> ><ed>
> >Never said that. In fact we are still concerned (for OASIS sake) with
> >exactly DSS intends to accomplish and were hoping to steer it in directions
> >which would add greater value and not sit on the shelf.
> ></ed>
>
>Okay.  That changes the scope of our discussion a little, if you're not
>just concerned with EPM but with DSS as a whole.
>
>It seems we have 2 themes in this round, at least:
>   - First, you don't like delegated signing.  That's fine.  Some people do,
>it adds very little, almost nothing to the protocol, it's a use case we've
>decided to consider, but everyone who works on the protocol doesn't have to
>be interested in every use case.
>   - Second, you seem to think we're trying to redefine XML-DSIG or XAdES
>and similar things.  I hope I've conveyed that we're not going to do
>this.  We are a protocol for creating and verifying signatures.  XadES and
>RFC 3126 define things that go inside signatures.  We can create signatures
>that have these things inside them.  No problem, no overlap.
>
>
>
> >  but I'd like to keep it how it is, and solve the more narrow
> >
> ><ed>
> >Well chosen word, narrow is exactly what I would call it. Deriving value
> >will be a challenge under these constraints.
> ></ed>
>
>Well, I've defended this by pointing out the use cases we will address, and
>you haven't explained what's wrong with these.  We have a TC of about 2
>dozen people who presumably are interested in these use cases, and several
>dozen observers, so some people perceive we have value..
>
>Trevor