RE: [TLS] Please discuss: draft-housley-evidence-extns-00<

"Kemp, David P." <DPKemp@missi.ncsc.mil> Mon, 29 January 2007 22:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfN0-0006WE-W6; Mon, 29 Jan 2007 17:53:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfN0-0006W7-JI for tls@ietf.org; Mon, 29 Jan 2007 17:53:02 -0500
Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfMz-00074W-2B for tls@ietf.org; Mon, 29 Jan 2007 17:53:02 -0500
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0TMr0ZI006202 for <tls@ietf.org>; Mon, 29 Jan 2007 17:53:00 -0500 (EST)
Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 29 Jan 2007 17:53:00 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Jan 2007 17:53:00 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00<
Date: Mon, 29 Jan 2007 17:53:00 -0500
Message-ID: <FA998122A677CF4390C1E291BFCF59890683B8B6@EXCH.missi.ncsc.mil>
In-reply-to: <200701292003.VAA15960@uw1048.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00<
Thread-Index: AcdD4OmAMWsTj3oCR+q4HeGiPKayxgAAXqMw
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 29 Jan 2007 22:53:00.0657 (UTC) FILETIME=[39F3AE10:01C743F8]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14966000
X-TM-AS-Result: : Yes-0.458100-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : 147018-150567-139006-700073-139010-701298-704793-701632-701294-700618-703366-702358-702106-701387-702135-711874-700661-700906-706443-701933-707182-121119-700185-700551-701592-701887-700243-703278-701455-703590-701588-709418-711077-708039-706774-106580-704445-106660-704277-705526-702076-704407-702942-700516-700807-703468-711989-708792-148050-20042
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

-----Original Message-----
From: Martin Rex [mailto:martin.rex@sap.com]

> The IETF didn't transform PEM into PKI.  SPKI was an IETF
> approach, but it seemed to have died down (OpenPGP and SSH
> do their own formats).

Both PEM and S/MIME are email security applications
that use an infrastructure, as opposed to local interaction,
for key and identity management.  Neither PGP keys (in the
days of keysigning parties, before keyservers) nor SSH keys
qualify as "infrastructure" products generated by public
utilities and consumed by the public.  SPKI is not an
identity-based PKI at all, it is a privilege management
scheme that uses keys as principals.  The claim that PEM
was not the sole IETF predecessor of PKIX (and S/MIME)
is based on what sequence of events and RFCs?


> What happened was, that after the OSI communication protocols
> had failed miserably in the marketplace, many of the participants
> of the OSI/ISO standards organization started staffing IETF
> working groups and with pretty complete Proposals (X.509, SSL,
> S/Mime) and tried to prevent the IETF from killing further of
> their existing work as well.

The idea that RSA's PKCS-7, on which RSA's trademarked
S/MIME was based before being submitted to the IETF, originated
with OSI/ISO, is simply bizarre.  Same for Netscape's SSL.
What planet are you living on? 


> A lot of stuff in PKI X.509 is complex bloat and burden,
> and impairs interoperability for political or business model
> purposes, and not for its technical merit.
>
> One of the cumbersome legacy problems resulting from this
> approach are the X.500 distinguished names, which are equally
> unusable for humans and software.

Do you believe that DNS names, RFC822 names and IP addresses
are reasonably usable by humans and software?
Do you believe that the X.509 Subject Alternative Name extension
is politically-motivated bloat with no technical merit?

Certainly X.500 directory names based on a legacy DIT
are cumbersome.  But the X.509 syntax permits both simple and
complex names to be represented as appropriate to the business
at hand.  It is a failure of imagination among profile authors,
not IETF's use of X.509 syntax, that results in difficult
distinguished names.  An "E" distinguished name, by itself,
is perfectly reasonable, as is (for its intended purpose) a
DN composed of C's, O's and OU's.  Mixing them together
creates a truly unpalatable mishmash, but X.509 cannot be
blamed for that any more than rope can be blamed for capital
punishment.


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls