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
- [TLS] TLS1.2: focus on non X.509 certs, cert URLs… home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … EKR
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- [TLS] server auth on renegoiate home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … Mike
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … Martin Rex