On Thu, 2004-05-06 at 17:52, Ian Grigg wrote:
> c.  much less emphasis on deductive no-risk
> systems (PKIs like x.509 with SSL) due to the
> poor security and market results of the CA
> model.
> 

at the nist pki r&d workship (mentioned elsewhere in some other post
in this mailing list) there was discussion of 

1) using private key signing for things like signature (like in human
signature) agreement/authorization as opposed to straight
authentication. one of the issues is that if you ever use a private key
to digitally some random challenge/response data in a authentication
paradigm ... you might be at risk ever using the same private key for
signature purposes ... since it might be possible that some of the
random data you may have signed might not have been truely random after
all

2) naked public keys ... aka w/o certificates at all

3) and in some of the breaks the certificate use in payment
transactions. sort of two issues in payment transactions were/are a)
privacy and b) size bloat. in the mid-90s, the traditional x.509
identity certificate from the early 90s was drastically cut back to
relying-party-only, "account number" certificate because of privacy
issues with identity information. The work on certificate-based
financial transaction started with taking a 60-80 byte payment
transaction, instead of ISO8583, using ASN.1 encoding to blow it up to
200-300 bytes; added a 128-byte RSA signature (then adding in the ASN.1
encoding) and a relying-party-only certificate that typically ran 4k-12k
bytes; having starting from a 60byte normal transaction, the
certificate-based stuff would blow it up by factor of one hundred times
to 6k to 12k bytes. The certificate was totally redundant and
superfluous since the financial institution was the relying party and
already had all the information. In the X9.59 work it was observed that
it was possible to encode an ECDSA signature in an ISO8583 transaction
in 42 bytes ... so absolute minimum for authenticated payment
transaction would go from 60 bytes to a little over 100 bytes ... w/o
throwing in a bunch of extraneous, duplicated and/or superfluous data
that provided absolutely no added value (the payment transaction still
contained the same data, digital signature authentication was added ...
and all the payload carried in a certificate was totally redundant and
superfluous since the relying-party had a superset). It isn't exactly
that payment security requirements have to be proportional to the cost
of certificate security ... it was that certificate security increased
the payload costs by a factor of one hundred times and provided NO added
value.

some of my further observations about mixing authentication signing and
signature signing ... as well as nature of naked public keys ...
recently posted to thread in sci.crypt:
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures

and "the future of security" ... somewhat orthogonal to cryptography ...
there was recently a letter from NSF to some former multician that was
posted to the alt.os.multics n.g. that started a thread on (not
necessarily crypto) system security (and multics never having been
broken). a couple posts in the thread
http://www.garlic.com/~lynn/2004e.html#27 NSF itnerest in Multics
security
http://www.garlic.com/~lynn/2004e.html#36 NSF itnerest in Multics
security


-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

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

Reply via email to