IETF Logo Mail Archive

Re: [TLS] the use cases for GSS-based TLS and the plea for

Martin Rex <Martin.Rex@sap.com> Fri, 20 July 2007 19:12 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxtk-000719-2I; Fri, 20 Jul 2007 15:12:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxti-000712-LK for tls@ietf.org; Fri, 20 Jul 2007 15:12:18 -0400
Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxti-0005tw-71 for tls@ietf.org; Fri, 20 Jul 2007 15:12:18 -0400
Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA17031; Fri, 20 Jul 2007 21:12:14 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707201912.l6KJCE7Y014140@fs4113.wdf.sap.corp>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
To: DPKemp@missi.ncsc.mil
Date: Fri, 20 Jul 2007 21:12:14 +0200
In-Reply-To: <FA998122A677CF4390C1E291BFCF598907D6058D@EXCH.missi.ncsc.mil> from "Kemp, David P." at Jul 20, 7 02:49:25 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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

Kemp, David P. wrote:
> 
> It seems strange to criticize SPKM and SPNEGO for being ASN.1-based
> while not making the same criticism of Kerberos.   To what extent
> has the adoption and theoretical review of Kerberos been hampered
> by this "huge" roadblock?

When ASN.1 was less of a problem, then the ambiguity about
the AlgOID within PKCS#1 would not have been earlier detected,
it would not even exist!

Or you may want to look at the pity the PKI guys created with
certificate chains in ASN.1 containers (SOAP/WS-Security).
The PKI guys messed abused PKCS#7 containers and CertificatePairs
until they finally came up with a PKIPath.

The text of the defect report describing PKIPath (not easy to find)
is much better than what was added to the spec document.  But
both do not say a word whether a self-signed RootCA certs is
either prohibited, allowed, expected, required.  TLSv1.0
already recognized this ambiguity in SSLv3 and fixed it long ago.


-Martin

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

v2.29.0 | Report a Bug | By Email | System Status