[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PKCS 7 + PKCS 10 Proposal
Hi,
I have a number of major concerns with the proposal that was submitted
to these lists recently, along with several serious, but less critical,
concerns. I'll only mention the major ones here.
>----------
>From: mmyers@verisign.com[SMTP:mmyers@verisign.com]
>Sent: Thursday, July 31, 1997 9:39 PM
>To: ietf-pkix@tandem.com
>Cc: ipsec@tis.com
>Subject: PKCS 7 + PKCS 10 Proposal
>
>All--
>
>
>Back in San Jose and again in Memphis the PKIX WG expressed interest in
>considering the use of PKCS 7 and PKCS 10 for PKI administrative
>messaging. The draft below follows up on this topic from Memphis.
>
>
>The question naturally emerges: How does this relate to PKIX Part 3,
>considering that PKIX Part 3 accepted changes at the last IETF which
>accomodate PKCS 7 and PKCS 10?
>
>
>(Carlisle, if I've misrepresented your position, I'm sure you'll have no
>reservation whatsoever in correcting the public record!)
Now that I'm back in town, I will take Mike up on his generous offer!
:-)
>Carlisle and I today discussed the issues surrounding this question, in
>the context of the draft below. We concluded it proposes a reasonable
>approach towards leveraging the installed base of PKCS 7 capabilities.
>To that end, I propose we consider this framework in Munich and determine
>if and how it should move forward.
This puts a slightly more positive spin on my position than I think is
warranted. What I actually concluded was that if you wanted to take
advantage of the installed base of PKCS #7 and #10, this approach was
probably about the best you could do. However, it has significant
disadvantages and security problems and (at best) solves a limited
subset of the required functionality for limited, very specific,
environments.
>The authors also feel that this work merits attention within the IPSEC
>Working Group, hence it cross-posting to that list.
>
>
>
>Carlisle had the following specific observations:
Let me re-word that slightly: "Carlisle had the following specific
reservations with respect to the usefulness of this proposed protocol:"
>1. The draft continues to promote the notion that one need only have a
>single key.
The draft does not simply promote the notion that one need only have a
single key. Rather, it fundamentally relies on that notion. [See, for
example, the first sentence of Section 5.1.1.2 which says, "Because the
response is encrypted with the user's public key.... This is the
response to the certification request, which (being a PKCS #10 request)
was signed with the user's private key. One key pair for both signing
and encryption. Didn't I hear a (loud) call from the group recently
saying that DSA should be mandatory for the PKIX protocols and that RSA
should be optional?]
The impression I get from many, many quarters is that, collectively, we
have (or should have) put this issue to rest by now. Of course there
are a number of systems out there that operate as single-key systems for
historical and backward-compatibility reasons. However, there is no
valid argument for fundamentally building in a single-key assumption in
new protocols that we propose. I suspect there will be no shortage of
people who oppose this if we try to promote such a limited and flawed
design.
>2. It provides no means to certify a D-H key. Recognizing that the WG
>has received a proposal to do so using PKCS 10 constructs, there still
>remains a problem of coordinating parameters between the client and the
>CA.
It is not a "problem of coordinating parameters". It is that trying to
force-fit D-H certification into PKCS #10 requires two things: (a) it
requires that the CA has a D-H certificate for this purpose; and (b) it
requires that the end entity be content to use the specific parameters
in the CA's D-H certificate for its own D-H key pair. Condition (a)
seems like an unnecessary extra burden to place on CAs, but this is not
a serious problem. Condition (b), on the other hand, seems far too
limiting for a general solution. If an end entity wants to create its
own key pair it should be free to create it in any way it likes, for
whatever purposes it likes, and get the resulting public key certified
(subject to policy, etc.).
>3. It does not adequately address the subscriber bootstrapping
>problem.
"Does not adequately address" is a little understated. It does not
address this problem at all. In other words, there is no
(cryptographically secure) way for a brand-new end entity to get
initialized and begin functioning in the system. I don't want to sound
extremist here, but this is not a small shortcoming. What you end up
with in this proposal is an infrastructure full of certificates that you
can't trust. [Note that the "most secure", manual mode, where a phone
call is made and hashes are read out, is prone to user error. More
significantly, it does not scale: requiring CA administrators to
contact end users by telephone when organizations span multiple
continents, time zones, and languages will prove challenging and will
almost certainly lead to (at least the occasional) use of
unauthenticated certificates. Since unauthenticated certificates cannot
be distinguished from properly-authenticated certificates, you end up in
a situation where you can't really trust any certificate.]
>4. More generally, the current draft clearly falls short of addressing
>the entire set of capabilities provided by Part 3.
This point is worded exactly as I would wish, except that I might have
started with "More importantly, ..."
>For each of these there exists a reasonable counter position. It's
>tempting to rebut each, but in the interest of brevity I will address
>only the last point, leaving the others to the list and Munich.
I would be interested in seeing the rebuttals, but I am not optimistic
that they can be made to be convincing with respect to the actual needs
for general certificate management protocols.
>To the last point, I would observe that the draft is intended to address
>only the most essential elements of a PKI service, with the thought in
>mind that additional work would be needed to expand upon these basic
>services.
In other words, the plan seems to be to essentially re-do everything
that has already been done in the past 1-1/2 to 2 years with PKIX-3.
Mike has repeatedly said to me that a lot of effort and thinking has
gone into PKIX-3 to construct a secure, general set of protocols for
certificate management. Does it make sense to do this all again for
this new proposal (and wait another 1-1/2 to 2 years to get something
that is strong enough and general enough to be useful)? My personal
feeling is, "No".
Ultimately, what PKIX is all about is the definition and standardization
of a Public-Key Infrastructure for the Internet. The proposal given
here cannot (and does not) claim to build such an infrastructure. It
may provide *some* of the necessary functionality for *some*
environments (although I still worry about not being able to securely
initialize entities), but this limited focus is clearly inadequate for
an IPKI. Considering that this work has already been done in PKIX-3,
and that it is ready to go to Working Group Last Call, it seems to me
that the proposal given here may be suitable as a (standardized or
proprietary) protocol in some other context, but not within the stated
scope of the PKIX Working Group.
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------
Follow-Ups: