As a matter of fact RFC1422 is quite clear on this point -- it states that the
cert chain must trace all the way to the PCA root. Paragraph 4 of Section 2
makes this clear in the case of selecting a recipient public key for
encryption, and paragraph 6 makes it clear in the case of signature
validation.
OK. I'd agree in that case that we ought to either revise 1422 toaccommodate
sefl-signed certs, or that you ought to override that assertion in the PEM/MIME
spec. the override might be easier, clearner, and infinitely faster and opening
up 1422 again for even such a small change.
Unless such usage is specifically prohibited (and I doubt that it was, or
Steve
and JIm wouldn't have implemented it, or at least would have screamed),
TIS didn't implement it, at least not in any useful or obvious way.
I'll go back through the last month's messages if you like and find either
Steve's or Jim's assertion that they did implement it, and that no one used it,
and that that's why they concluded that the entire certificate business was a
non-starter. I tried to gently suggest that at best the documentation didn't
exactly highlight that capability and that's perhaps why no one used it, but
they didn't seem to get the point.
I have no problem with discarding features of RFC1422. It is your position
that doing so may weaken things to the point of unusability. My only point
here is that you can't stick with this position and have self-signed
certs as well.
Discard, smishcard. I just want to know what's in and what's out, and what it
does to the integrity of the overall system. 1422 was hashed and rehashed for
more than three years, and improvements were steadily made as various faults
were uncovered and fixed. That is the nature of cryptographic protocols, more
so than almost any other of man's endeavors, I would claim (except for trying
to come up with a perfect message digest algorithm, as I know from repeated and
painful personal experience -- ask Don Coppersmith.) A small group of you folks
have gone through that process with the revised spec, but not having been part
of it I can't judge whether the examination was sufficiently thorough or not.
The rest of us are just starting to catch up now.
Actually though, Ned, that was more Steve Kent's position than mine. It isn't
that I'm not concerned, but I haven't been quite so adament on the assurance
issue as I think those issues would eventually sort themselves out in
implementations, and maybe only time will tell. I am much more concerned about
what the various forms of names and key selectors used by the recipient may
imply as far as what the originator has to know, plus questions of how the keys
are distributed and particularly how a key is revoked in the case of
compromise, and the impact that a proliferation of new forms will have on the
now-emerging PKI infrastructure. Will the groundhog see his shadow and return
to his burrow for another five years? I'm afraid so, but I might be proven
wrong.
But as I said earlier, if there is a new document coming out soon, I will
withhold further comment until I can read it. Maybe lightning will strike and
all my concerns will go away. Maybe buffaloes will sprout wings and fly over
the SuperBowl delivering pizzas.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820