Re: Digital signatures have a big problem with meaning

2005-06-13 Thread Peter Gutmann
Rich Salz [EMAIL PROTECTED] writes:

Peter's shared earlier drafts with me, and we've exchanged email about this.
The only complaint that has a factual basis is this:

I don't want to have to implement XML processing to do
XML Digital Signatures

 I don't want to have to re-implement Apache in order to do
 an SSL implementation.
 
 I don't want to have to re-implement MS Exchange in order to
 do a PGP implementation.
 
 I don't want to have to re-implement ext2fs in order to encrypt
 a file.

Makes sense to me.  The other problem with XML sigs (also pointed out in the
writeup) is the fact that it gives you 10 ways to do everything, of which only
1 is actually correct/secure/usable, but is indistinguishable from the other
9.  Since ease of use/secure-by-default is a major goal of my work, I'm rather
reluctant to implement something that lets users blow their feet off in a
dozen different ways without even knowing it.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-13 Thread Rich Salz

 I don't want to have to re-implement Apache in order to do
 an SSL implementation. ...


Those analogies aren't apt.  XML is a data format, so it's more like
I don't want to have to implement ASN1/DER to do S/MIME
Which is a nonsensical complaint.


Makes sense to me.  The other problem with XML sigs (also pointed out in the
writeup) is the fact that it gives you 10 ways to do everything, of which only
1 is actually correct/secure/usable, but is indistinguishable from the other
9.


I don't see it.  Yes, XML DSIG makes it possible to sign parts of an XML 
document.  And there are broken applications.  Er, so what?  Is the lack 
of certificate validation in outlook proof that S/MIME is broken?



reluctant to implement something that lets users blow their feet off in a
dozen different ways without even knowing it.


So have your API take an XML document and output a signature that signs 
the exclusive canonicalization of that document, and includes the 
signer's certificate in the keydata.  Problem solved.  And that's a fair 
comparison, since S/MIME is just a profile of PKCS#7 applied to email, 
right?  So use WS-Security which is a profile of XML DSIG applied to 
SOAP messages, for example.


In other postings, you've pointed out that nobody re-generates the 
DER, but instead keeps it around to verify the signature.  In the XML 
world we do it all the time; recreating and re-canonicalizing works.  I 
guess that proves S/MIME and PGP are fundamentally broken. :)


/r$

--
Rich Salz, Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-08 Thread Peter Gutmann
Ben Laurie [EMAIL PROTECTED] writes:
Anne  Lynn Wheeler wrote:
 Peter Gutmann wrote:
 That cuts both ways though.  Since so many systems *do* screw with
 data (in
 insignificant ways, e.g. stripping trailing blanks), anyone who does
 massage
 data in such a way that any trivial change will be detected is going
 to be
 inundated with false positives.  Just ask any OpenPGP implementor about
 handling text canonicalisation.

 this was one of the big issues in the asn.1 encoding vis-a-vis xml
 encoding wars.

 asn.1 encoding provided deterministic encoding for signed material,

You mean it _would_ have done if anyone could implement it correctly. Sadly,
experience shows that no-one can.

Right, but that's lead to a de-facto encoding rule of The originator encodes
it however they like, and everyone else re-encodes it (if required) using
memcpy().  The advantage of the format is that it's never tried to be
anything other than a pure binary-only format, so moving it over text-only
channels is handled at the next layer down (usually base64), rather than
trying to make the encoding itself text-only-capable and then finding yourself
in a world of pain when half the systems the stuff passes through mangle the
text.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-07 Thread Rich Salz
Peter Gutmann wrote:
 Yup, see Why XML Security is Broken,
 http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this.

Peter's shared earlier drafts with me, and we've exchanged email about this.
The only complaint that has a factual basis is this:
I don't want to have to implement XML processing to do
XML Digital Signatures

The others are just blowing smoke, or proof by snarkiness. :)

/r$

-- 
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-07 Thread Ben Laurie

Ian G wrote:

On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote:


Ian G writes:
| In the end, the digital signature was just crypto
| candy...

On the one hand a digital signature should matter more
the bigger the transaction that it protects.  On the
other hand, the bigger the transaction the lower the
probability that it is between strangers who have no
other leverage for recourse.



Yes, indeed!  The thing about a signature is that
*it* itself - the mark on paper or the digital result
of some formula - isn't the essence of signing.

The essence of the process is something that
lawyers call intent (I'm definately not clear on
these words so if there are any real lawyers in
the house...).  And, when the dispute comes to
court, the process is not one of proving the
signature but of showing intent.


Perhaps this is a good moment to remind people of my paper Signatures: 
an Interface between Law and Technology (written with Nicholas Bohm, a 
lawyer) which discusses this and other issues.


http://www.apache-ssl.org/tech-legal.pdf

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-07 Thread Ben Laurie

Anne  Lynn Wheeler wrote:

Peter Gutmann wrote:

That cuts both ways though.  Since so many systems *do* screw with 
data (in
insignificant ways, e.g. stripping trailing blanks), anyone who does 
massage
data in such a way that any trivial change will be detected is going 
to be

inundated with false positives.  Just ask any OpenPGP implementor about
handling text canonicalisation.



this was one of the big issues in the asn.1 encoding vis-a-vis xml 
encoding wars.


asn.1 encoding provided deterministic encoding for signed material, 


You mean it _would_ have done if anyone could implement it correctly. 
Sadly, experience shows that no-one can.


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-06 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

Yup, see Why XML Security is Broken,
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this.  Mind
you ASN.1 is little better, there are rules for deterministic encoding, but so
many things get them wrong that experience has shown the only safe way to
handle it is to do an exact bit-for-bit copy from A to B, rather than trying
to re-code at any point.  I've frequently commented that there is only one
workable rule for encoding objects like X.500 DNs, and that's memcpy().


there was another issue with digital signatures supposedly acquiring 
attributes of human signatures  aka implication that human had 
actually read, understood, approves, agrees, and/or authorizes the 
content ... as well as intent.


so at least some financial institutions in the mid-90s were realizing 
that x.509 identity certificate ... potentially overloaded with enormous 
amounts of personal information, represented significant liability and 
privacy concerns ... were looked at switching to relying party only 
certificates ... basically containing some sort of database record 
locator (where all the real information was located) and a public key. 
however, it was trivial to demonstrate that such certificates were 
redundant and superfluous.

http://www.garlic.com/~lynn/subpubkey.html#rpo

there was another issue involving the typical 4k-12k byte size of such 
certificates ... when appended to a typical payment transaction of 60-80 
bytes ... besides being redundant and superfluous ... also would 
represent horrendous payload bloat.


now the certificate crazed periods of the 90s also had something called 
the certificate non-repudiation bit ... which large segments of the 
market was interpreting as meaning that digital signatures with appended 
certificates containing the non-repudiation bit ... couldn't be 
repudiated by the person making the digital signature.


in the retail payments scenario ... the task was to convince consumers 
to pay $100/annum for redundant and superfluous, payload bloating 
relying party only certificates with the non-repudiation bit set. 
supposedly the scenario being sold retail merchant industry was that 
while the current retail payment environment had the burden of proof (in 
any consumer dispute) placed on the merchant ... if the consumer would 
be so kind to append an redundant and superfluous, enormous payload 
bloating certificate with the non-repudiation bit set ... the burden of 
proof in a dispute would be shifted from the merchant to the consumer.


there was some hypothetical investigation that even if the consumer did 
digitally sign a retail payment transaction and appended a redundant and 
supefluous, payload bloating relying party only certificate ... w/o the 
non-repudiation bit set  that merchants could possibly substitute a 
similar certificate which did have the non-repudiation bit turned on ... 
possibly harvested from some convenient, cooperating LDAP trusted 
certificate repository.


besides all the other practical and legal issues about digital 
signatures being interpreted as simply something you have 
authentication ... from 3-factor authentication model

http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

and NOT as human signature implying intent, read, understood, agree, 
approve, and/or authorize 


... there was the issue that the non-repudiation bit within a 
certificate was supposedly creating liability on behalf of the digital 
signer ... however the PKI protocols contained no provision for proving 
what specific certificate the person applying a digital signature had 
actually appended to any specific transaction ... aka the digital 
signature was only on the transaction itself ... and there was no 
digital signature armoring/binding which digital certificate might 
actually have been originally appended to any specific digitally signed 
transaction (possibly allowing merchants to substitute non-repudiation 
certificates when none had been intended).


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-03 Thread Peter Gutmann
Rich Salz [EMAIL PROTECTED] writes:

I think signatures are increasingly being used for technical reasons, not
legal.  That is, sign and verify just to prove that all the layers of
middleware and Internet and general bugaboos didn't screw with it. 

That cuts both ways though.  Since so many systems *do* screw with data (in
insignificant ways, e.g. stripping trailing blanks), anyone who does massage
data in such a way that any trivial change will be detected is going to be
inundated with false positives.  Just ask any OpenPGP implementor about
handling text canonicalisation.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-03 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

That cuts both ways though.  Since so many systems *do* screw with data (in
insignificant ways, e.g. stripping trailing blanks), anyone who does massage
data in such a way that any trivial change will be detected is going to be
inundated with false positives.  Just ask any OpenPGP implementor about
handling text canonicalisation.


this was one of the big issues in the asn.1 encoding vis-a-vis xml 
encoding wars.


asn.1 encoding provided deterministic encoding for signed material, 
although some of the more common applications of digital signature have 
what is transmitted is the original encoded material along with the 
signature of that encoded material.


fstc/e-check project wanted to digital sign stuff that was xml encoded 
... but not transmit the xml encoded fields. they wanted to take 
standard financial transaction fields ... momentarily xml encode the 
standard fields, digitally sign the encoded material ... and then append 
the resulting digital signature to the (original) standard transaction 
for transmission.


the problem was that xml didn't have a deterministic definition for 
encoding fields. when the recipient/relying party received the 
transmission ... they had to take the standard transaction fields and 
re-encode in xml in order to verifiy the digital signature. fstc/e-check 
came up with fsml for deterministic encoding of fields ... so that the 
encoding done by the originator (of the digital signature) and the 
encoding done by the relying party (for verifying the digital signature) 
would have identical bit patterns.


fsml was subsequently contributed to the xml digital signature project.

xml is descendent of gml invented by G, M, and L in 1969 at the 
science center

http://www.garlic.com/~lynn/subtopic.html#545tech
and then standardized at ISO in the 70s
http://www.garlic.com/~lynn/subtopic.html#sgml

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-03 Thread Peter Gutmann
Anne  Lynn Wheeler [EMAIL PROTECTED] writes:

the problem was that xml didn't have a deterministic definition for encoding
fields.

Yup, see Why XML Security is Broken,
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this.  Mind
you ASN.1 is little better, there are rules for deterministic encoding, but so
many things get them wrong that experience has shown the only safe way to
handle it is to do an exact bit-for-bit copy from A to B, rather than trying
to re-code at any point.  I've frequently commented that there is only one
workable rule for encoding objects like X.500 DNs, and that's memcpy().

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-03 Thread John Gilmore
 That cuts both ways though.  Since so many systems *do* screw with data (in
 insignificant ways, e.g. stripping trailing blanks), anyone who does massage
 data in such a way that any trivial change will be detected is going to be
 inundated with false positives.  Just ask any OpenPGP implementor about
 handling text canonicalisation.

Even mere hash checks are turning up obscure data corruptions.  Some
people reported that BitTorrent would never finish certain files,
getting to 99.9% and stalling.  The problem is that their NAT box was
replacing its external IP address with its internal address --
anywhere in a packet.  This is called Game mode in some NAT boxes.
Their router was corrupting random binary data (and altering the TCP,
UDP, and Ethernet packet checksums!).  They never noticed until
BitTorrent used end-to-end application-level SHA1 hash checks and
retransmission to detect and correct it.

  http://azureus.aelitis.com/wiki/index.php/NinetyNine

John

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-02 Thread Ian G
On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote:
 Ian G writes:
  | In the end, the digital signature was just crypto
  | candy...

 On the one hand a digital signature should matter more
 the bigger the transaction that it protects.  On the
 other hand, the bigger the transaction the lower the
 probability that it is between strangers who have no
 other leverage for recourse.

Yes, indeed!  The thing about a signature is that
*it* itself - the mark on paper or the digital result
of some formula - isn't the essence of signing.

The essence of the process is something that
lawyers call intent (I'm definately not clear on
these words so if there are any real lawyers in
the house...).  And, when the dispute comes to
court, the process is not one of proving the
signature but of showing intent.

And as the transaction gets bigger, the process
of making and showing intent gets more involved,
more complex.  So it is naturally ramped up to the
transaction, in a way that digsigs just totally miss
out on.

Which means that the digital signature school
got it completely wrong.  A digital signature is
only just one more element in a process that
is quite complex, involved, and goes back into
history more years than we can count.  It is
therefore completely unlikely that a digsig will
ever replace all that;  however it is quite possible
that a digsig could comfortably add a new element
to that process.

(Speaking here of common law, which is not
universally applicable...)

 And, of course, proving anything by way of dueling
 experts doesn't provide much predictability in a jury
 system, e.g., OJ Simpson.

And this is where we found for example the OpenPGP
cleartext digital signature to be the only one that
has any merit.  Because it can be printed on paper,
and that piece of paper can be presented to the
jury of an O.J.Simpson style case, or even a Homer
Simpson style case, this carries weight.

An OpenPGP clear text signature carries weight
because it is there, in black and white, and no
side would dare to deny that because they know
it would be a simple matter to go to the next level.

But any other form of non-printable digital signature
is not presentable to a jury.  What are you going
to do? Throw a number in front of a jury and say its a
signature on another number?  It's a mental leap of
orders of magnitude more effort, and there are many
ways the other side could sidestep that.

iang

PS: To get this in x.509, we coded up cleartext
sigs into the x.509 format.
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-02 Thread Anne Lynn Wheeler

[EMAIL PROTECTED] wrote:

On the one hand a digital signature should matter more
the bigger the transaction that it protects.  On the
other hand, the bigger the transaction the lower the
probability that it is between strangers who have no
other leverage for recourse.

And, of course, proving anything by way of dueling 
experts doesn't provide much predictability in a jury

system, e.g., OJ Simpson.


the bigger the transaction that the digital signature verifies  the 
more the relying party is going to be interested in fundamental 
integrity issues surrounding the digital signature generation


from 3-factor authentication paradigm

* something you have
* something you know
* something you are

simple digital signature verification is basically something you have 
authentication ... implying that the originator has access to and use of 
the corresponding private key (in addition to the transaction not having 
been modified in transit).


fundamental issues surrounding digital signature can be the integrity 
level of the infrastructure preventing compromise of the private key aka 
is the private key protected in a software file, is the private key in a 
hardware token, was the private key generated in a hardware token and 
can never leave the hardare token. also if it is a hardware token, is a 
pin/password also required to make the token operate correctly i.e. 
knowing characteristics of the hardware token, the relying party might 
be able to infer two-factor authentication and assess the risk/threats 
involved.


also what is the integrity level of the infrastructure in which the 
digital signature was generated ... for instance some of the EU finread

standard
http://www.garlic.com/~lynn/subpubkey.html#finread

which try and specify the minimum constraints for generation of a 
digital signature on a financial transaction.


this isn't so much proving anything ... this is risk management ... what 
is the likelyhood/exposure of a compromise for the relying party ... or 
security proportional to risk

http://www.garlic.com/~lynn/2001h.html#61

standard types of things that you would find at financial institutions 
and/or insurance institutions.


part of the confusion possibly is because of the extensive deployment of 
PKI literature ... which tends to focus the attention on the 
certification process ... as opposed to the integrity of the 
authentication process. the issue is that for the majority of business 
operations ... the PKI certificate process tends to be duplication of 
extensive relationship management business process that they already 
have in use (and therefor is redundant and superfluous) ... and there is 
much less focus on the basic risk, threat and vulnerability issues 
related directly to the authentcation.


and as i've frequently postulated ... that same may have an interest in 
creating semantic confusion ... implying that because the term digital 
signature includes the word signature ... that it somehow bears some 
relationship to human signatures.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-02 Thread Rich Salz

On the one hand a digital signature should matter more
the bigger the transaction that it protects.  On the
other hand, the bigger the transaction the lower the
probability that it is between strangers who have no
other leverage for recourse.


I think signatures are increasingly being used for technical reasons, 
not legal.  That is, sign and verify just to prove that all the layers 
of middleware and Internet and general bugaboos didn't screw with it. 
People seem to be building systems that assume proper operation, and use 
signatures as an application-level way to check, and also as a line of 
defense to screen out outsiders, rather than hold insiders liable.


Loosly coupled, tightly contracted.

/r$

--
Rich Salz, Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Digital signatures have a big problem with meaning

2005-06-01 Thread Ian G
On Tuesday 31 May 2005 23:43, Anne  Lynn Wheeler wrote:
 in most business scenarios ... the relying party has previous knowledge
 and contact with the entity that they are dealing with (making the
 introduction of PKI digital certificates redundant and superfluous).

Yes, this is directly what we found with the signed
contracts for digital instruments (aka ecash).  We did
all the normal digital signature infrastructure (using PGP
WoT and even x.509 PKI for a while) but the digsig
never actually made or delivered any meaningful biz
results.  In contrast, it was all the other steps that
we considered from the biz environment that made
the difference:  a readable contract, a guaruntee
that it wouldn't change, a solid linkage to every
transaction, and so forth and so on.

In the end, the digital signature was just crypto
candy.  We preserve it still because we want to
experiment with WoT between issuers and governance
roles, and because we need a signing process of
some form.  In any small scenario (1000 users)
that sort of linkage is better done outside the tech
and for large scenarios it is simply unproven whether
it can deliver.

http://iang.org/papers/ricardian_contract.html

iang

PS: must look up the exec summary of aads one day!
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Digital signatures have a big problem with meaning

2005-06-01 Thread dan

Ian G writes:
 | 
 | In the end, the digital signature was just crypto
 | candy...
 |


On the one hand a digital signature should matter more
the bigger the transaction that it protects.  On the
other hand, the bigger the transaction the lower the
probability that it is between strangers who have no
other leverage for recourse.

And, of course, proving anything by way of dueling 
experts doesn't provide much predictability in a jury
system, e.g., OJ Simpson.

--dan


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]