Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices

<home_pw@msn.com> Mon, 01 January 2007 02:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1DFD-0007NH-6X; Sun, 31 Dec 2006 21:49:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1DFB-0007N8-OE for tls@ietf.org; Sun, 31 Dec 2006 21:49:45 -0500
Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1DFA-0003gW-D6 for tls@ietf.org; Sun, 31 Dec 2006 21:49:45 -0500
Received: from hotmail.com ([65.54.174.89]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 18:49:43 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 18:49:43 -0800
Message-ID: <BAY103-DAV17A24AB7E3C84104974C0492BB0@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV17.phx.gbl with DAV; Mon, 01 Jan 2007 02:49:41 +0000
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
To: Mike <mike-list@pobox.com>, tls@ietf.org
References: <BAY103-DAV10609A530D84AA68BD08B792C40@phx.gbl> <45985FA9.5070307@pobox.com>
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices
Date: Sun, 31 Dec 2006 18:49:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 01 Jan 2007 02:49:43.0582 (UTC) FILETIME=[7D934BE0:01C72D4F]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
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

I agree; that's very practical and simple. The declaration is also opaque. 
So, what you say is what one SHOULD do, using formal reasoning, too. Its not 
the problem of the protocol state machine; its FOR a message/value handling 
module to deal with. The protocol machine is NOT ALLOWED to interpret an 
opaque byte.

The certificates in the traditional messages can still be BER, as far as I 
can tell. But, again, they are opaques. Most if not all the other recent 
imports of ASN.1 into the standard are required to be DER on the wire.

Once CA certs and trust anchors etc are cached, presumably upon signature 
verification (which necessarily includes DER recoding), the index of the 
cache can be a suitably hashed-DER-form of the issuerDN, for
efficient search.

--------------


There is an interesting legal side-argument there, for TLS Evidence. If the 
SSL Record Layer
is signing handshakes, it necessarily is signing uninterpreted bytes, vs 
signing "information".

it would be funny if when pinging the whitehouse.gov SSL server, one could 
be getting the formal
record in the national archives to have a digitally signed rendition of 
"long live Sadaam's stockpile; good riddance to Pinochet & torture" etc etc, 
as present in the uninterpreted data. One could be disclosing one's patent 
idea, in the cert fields, more usefully. Its going to get signed and data 
retained, even before the https application gets to decode it as syntactic 
rubbish. Stick your social security number in it, claim it as PII, add a 
copyright notice, claim it as IP, add a securid OTP to the clientHello.nonce 
and time, claim its timestamped, and viola! free storage for posterity at 
govt expense.

Strange things happen, when you don't carefully type check everything in 
security protocols, in my (highly ASN.1-centric) implementation experience. 
But there we are; that's what the spec says; this
is what do therefore do.

----- Original Message -----
From: "Mike" <mike-list@pobox.com>
To: <tls@ietf.org>
Sent: Sunday, December 31, 2006 5:11 PM
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, 
authoirzationspaces, registration practices

>> In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding 
>> of the DNs. The field has to
>> be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the 
>> format/encoding is defined
>> by the ClientCertificateType). (Tell Peter DER, and he assumes he has to 
>> type check it, now, as DER,
>> raising an exception if it fails the encoding rules for each attribute 
>> type's value; this is a lot of code!)
>
> I don't think you need to validate the DER encoding (or not) of the
> distinguished names.  Just compare them to your own and if you find
> a match, it must be DER encoded.  If you don't find a match, maybe
> it wasn't DER encoded, or maybe your DN isn't supported.  Either way
> you know what to do.
>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

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