Re: Perspective on signing XML 2

Responses indicated by ###

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668



"John Boyer" <jboyer@uwi.com> on 04/22/99 03:12:48 PM

To:   rdbrown@globeset.com
cc:   "Dsig group" <w3c-xml-sig-ws@w3.org> (bcc: Donald
      Eastlake/Hawthorne/IBM)
Subject:  Perspective on signing XML 2

[...]

the W3C's reference implementation code, and the W3C will not want to get
into the business of certifying as correct implementations that connect to
particular commercial packages.  Therefore, it is best to create a spec in
which one can be certified as a correct signed XML implementation because
correctness only means that you call the module of a given name with the
right parameters and the right message content.

### Please stop with this totally irrelevant hammering away on reference
code in message after message.

### There is no requirement for the W3C to produce reference code.  There
is no requirement for the W3C to certify any implementation of anything as
correct.  In fact, based on the assumption that the W3C's lawyers are not
idiots, I doubt that the W3C ever has ever or ever will certify any
particular
software implementation of anything non-trivial as perfect and defect free.

### Whether reference code is produced or not and whether or not bio-metric
systems like Pen Ops are easily accommodated, I believe the
mandatory to implement algorithms for interoperability with be
cryptographic.  And they will be defined in terms of the crypto algorithm,
not any particular software provider's API.  The mandatory to implement
algorithm(s) will include something like "DSA" not something like "Foobar
CryptoAPI with algorithm selector = 7".  Of course people should be able
to select and do whatever sort of proprietary and/or non-interoperable
stuff they want, but open standards bodies are not normally in the
business of mandating particular products.

4) By separating the cryptography from the act of signing, we can freely
distribute the reference implementation and it becomes the deployer's
responsibility to select and install signing technologies that are
commensurate with the needs of the target organization.  The companies that
produce the crypto layer have the export problems.  Whereas if the W3C
reference implementation (complete with source code) has to have a crypto
layer, it will be illegal for MIT to distribute it.

### Somehow I suspect the W3C is interested is interoperable security of
resources on the web.  That is, that one should be able to authenticate
them even if your are using a Macintosh or AS/400 or Palm Pilot or VMS or
even an Intel based Windows machine, etc.  While there are lots of other
aspects to this question, I sure that W3C's desire that I'm guessing at
here is widespread and is only met by an algorithmically specific
authentication process using crypto that has been or will very quickly be
actually implemented more or less universally.  Just saying, "lets put
together a bare skeleton with no signing or authentication meat and
everyone can just plug in their own engine" is a complete non-starter at
meeting this requirement (which is, of course, only one of many
requirements...).

### No doubt MIT appreciates you constant worry about they legal problems
but I just don't see it.  I don't think that complete authentication only
source code is export restricted (unless it is easy to use for encryption).
I don't think that partial authentication only source code with crypto
calls
in it is export restricted (witness DNSSEC).  However, I'm not a lawyer and
even if I am wrong, I'm not sure this makes much difference is creating a
global interoperable secure standard.

### We need to come up with a standard or standards the meet the
requirements including multinational interoperable web resource
authentication.  If export restrictions require it to be implemented
separately in several parts of the world, as may arguably be true of the
IETF IPSEC standard for example, that's just the way it is and people will
have to live with it as best they can.

[...]

2) The reference implementation will need to have all crypto algorithms
suggested by the markup in order to demonstrate full compliance with the
spec.  MIT will not be able to distribute.  Moreover, all companies
creating
compliant implementations will have those lousy export restrictions
imposed.

### Compliance requires only the implementation of the mandatory parts of
the standard.  That's why, if there are multiple algorithms, some are
labeled mandatory and some labeled optional.  Since you are being
redundant in your message hammering away at this irrelevant reference
implementation stuff, hope you won't mind my being redundant:  Since
it's authentication only, I believe MIT could distribute.  But whether
I'm right in that or not, mandated interoperable crypto algorithms are
essential in meeting one major requirement, that of interoperable web
resource authentication.  Therefore, as I see it, there will be mandatory
to
implement crypto algorithms in the standard regardless of who, if anyone,
implements any type of reference and regardless of whether that reference
is exportable from or importable into any particular nation.

### If the only goal is to guarantee correctness in implementing the
standard and exportability and there are no other requirements, we
could probably achieve this by standardizing on null signatures.

[...]

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

### Donald

Received on Friday, 23 April 1999 00:29:00 UTC