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

From: Peter Williams <[email-masked]>
Date: Tue, 30 Jan 2007 20:56:45 -0800

> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 31 Jan 2007 12:44:58 -0500

________________________________________
From: Peter Williams [mailto:[email-masked]] 

> 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.

Peter,

What has been destroyed?  If there are multiple
valid paths through a graph to a subject, then all parents of
that subject must have the same public key regardless of
whether SKI/AKI are populated.  In other words, the certificate
signature is already a static back-reference to its parent
cert(s).  (btw, there are no forward references at all - no
data object that lists all certs issued by a CA.  They can
only be discovered, not enumerated.)

No single AKI/SKI failure will cause any problem at all; two
independent failures are required to preclude acceptance of
valid paths:
1) CAs issue certs with incorrect values (CA A issues cert to
CA B containing SKI that does not match the AKI of certs issued
by CA B), and
2) applications check SKI/AKI chaining during path validation,
violating of the 3280 expectation that they not do so.

Now whether the extra bandwidth of using SKI/AKI is justified
by occasionally saving some computation is a different question;
the answer depends on context.

Dave
(who must be even thicker, having learned and internalized many
of Peter's lessons and undoubtedly forgotten many others.)