[147496] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] encoding formats should not be committee'ized

daemon@ATHENA.MIT.EDU (Peter Gutmann)
Fri Oct 4 09:56:29 2013

X-Original-To: cryptography@metzdowd.com
Date: Fri, 04 Oct 2013 21:17:47 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: dan@geer.org, pgut001@cs.auckland.ac.nz
In-Reply-To: <20131003155954.0F11D228224@palinka.tinho.net>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

<dan@geer.org> writes:

>The (U.S.) medical records system that started at the Veterans'
>Administration and has now spread to all but all parts of the U.S. Federal
>government that handle electronic health records is ASCII encoded, and
>readable.  Called "The Blue Button,"[1] there is even an HL7->Blue Button
>file converter.[2]
>
>Score one for human readable.

Things like HL7 and EDIFACT/X12 (and ASN.1 in DER/BER form) were never meant
to be human-readable, they're meant to be easily machine readable and
processable.  This is why you have viewers to turn them into human-readable
form in any format you want.  The problem with formats like XML is that it's
never been quite sure what it wants to be, so that the result is neither
easily human-readable nor easily machine-readable.

Trying to get back on track, I think any attempt at TLS 2 is doomed.  We've
already gone through, what, about a million messages bikeshedding over the
encoding format and have barely started on the crypto.  Can you imagine any
two people on this list agreeing on what crypto mechanism to use?  Or whether
identity-hiding (at the expense of complexity/security) should trump
simplicity/security 9at the expense of exposing identity information)?

Peter.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post