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

Peter Williams <home_pw@msn.com> Wed, 31 January 2007 04:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7Wc-0003Lk-4P; Tue, 30 Jan 2007 23:56:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7Wb-0003Lf-4q for tls@ietf.org; Tue, 30 Jan 2007 23:56:49 -0500
Received: from bay0-omc3-s18.bay0.hotmail.com ([65.54.246.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7WX-0008Ds-JG for tls@ietf.org; Tue, 30 Jan 2007 23:56:49 -0500
Received: from BAY126-W2 ([65.55.131.37]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 30 Jan 2007 20:56:45 -0800
X-Originating-IP: [70.142.20.165]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY126-W26894C8731425A107C14092A50@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: martin.rex@sap.com, Russ Housley <housley@vigilsec.com>
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00<
Date: Tue, 30 Jan 2007 20:56:45 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Jan 2007 04:56:45.0141 (UTC) FILETIME=[34C56850:01C744F4]
X-Spam-Score: 2.4 (++)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: tls@ietf.org
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>
Content-Type: multipart/mixed; boundary="===============0819271127=="
Errors-To: tls-bounces@lists.ietf.org

 
> > Subject key identifiers were added to CMS by me. They were not in > > PKCS #7 as specified by RSA Labs. They first appeared in > > draft-ietf-smime-cms-10.txt in December 1998. They were added in > > recognition that the combination of issuer name and serial number was > > quite large.
FYI:- The issues are much older than 1998. http://www.imc.org/ietf-pkix/old-archive-93-96/msg00249.html
 
Its quite true that the original PKCS#7 used DN+serial to refer to keys. A few billion cert citations later, its been amazingly successful though. Its hard to know which generates more bytes, certs, or arguments against this or that feature of the cert specification.
 
I'm personally delighted Russ ran with the PKCS#7 initiative , updated it all a bit, and made CMS - though its true I've personally never used it, given PKCS#10 and PKCS#7 in a simple email do 80% of the job just fine - like PEM's equivalents predicted. I got PKCS#7 into S/MIME (Windows), PKCS#7 SCEP (cisco routers worldwide), and PKCS#7 into CMS (US govt key management, MSFT Cert Server). Much better engineers than me took over and made it work properly. But boy, was it hard road of (emotional level) argument to get folks to do the "right thing". 
 
Sometimes its a real advantage being really dumb (UK "thick"), like me. There was something just "right" about PKCS#7 when I first saw it (and Djamal Hadj Sadok re-implemented it) in 1993. No religion, no agenda, no posturing, no red/black, no I hate ASN.1 because its foreign .... just clarity - for implementors attempting to build open systems.
 
I was fortunate enough to see the RSADSI source code, and meet the 2 of folk (both vietnamese refugees) who wrote the C classes for the first implementation of PKCS#7 (which did its own virtual functions, with incredibly convoluted C macros). What was amazing was the way in which the original code base and the spec aligned. They were like two sides of the same coin, once you learned to appreciate the architecture of the code base.
 
One of the unfortunate sideefects of the the subject cert referring to its parent cert via a hash is that it destroyed the best bit that DARPA design folk ever added to certs: the ability to have multiple paths through a semi-hierarchical CA graph, where a caching scheme could select the best path that fit - based on the context (like routing) and heuristics. With static citation of certs paths, we lost the best of what certs really ever had to offer. I'm really not sure static back-references to certs were that good an idea, except for enforcing control.
_________________________________________________________________
Check out all that glitters with the MSN Entertainment Guide to the Oscars
http://Movies.msn.com/movies/oscars2007
_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls