RE: PKCS 7/10 Security Issues

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Mike,

After being out of the office (and away from e-mail) for over a week, I
returned to find your message regarding security issues in the PKCS 7/10
Certificate Management proposal.  I have several comments, but to keep
this short, I'll just mention the places where I think you forgot or
misinterpreted what I said in Munich (so that we can all work from the
same starting point).

>----------
>From: 	mmyers@verisign.com[SMTP:mmyers@verisign.com]
>Sent: 	Sunday, August 31, 1997 3:13 AM
>To: 	ietf-pkix@tandem.com
>Subject: 	PKCS 7/10 Security Issues
>
>All--
>
>In order to properly bound the security work in particular, it's
>essential we understand and agree to the security requirements of the 7/10
>supplement's intended client audience.  We have a good start along those
>lines from Munich.  It's important however to conclude which among those
>observations establish the basis for further work.   Having not received an
>advanced copy of the analysis, the following is based on my best
>recollection of the points raised during the meeting:

Precisely in order to avoid the situation you describe in your last
sentence above, I sent you (on Wed., Aug. 20th) a copy of the slides and
associated notes that I used in Munich.  [I sent this to Warwick & Steve
for inclusion in the minutes, and copied you and a few others who had
specifically asked for the slides.]

I can only assume that you somehow never received that message...




>Secure Boostrap
>---------------
>It was observed that the 7/10 proposal lacks specification of the means by
>which vendors are required to establish a trusted public key. While
>accurate in fact, the analysis failed to acknowledge the utility of simple
>out-of-band measures (indeed, Part 3 provides many examples of how to do so.)
>
>It is only necessary to note that out-of-band establishment of a trusted
>public key meets the need for simplicity. Under many circumstances this is
>a perfectly valid approach.  Security environments that rely on hardware
>tokens are a prime example.
>
>Proposed Resolution: The exact means by which clients of the 7/10
>supplement establish trusted public keys are out of scope of the draft.
>The Security Considerations section will provide some general guidance on
>the topic.

It's not clear to me how the procedure for getting an end entity
initialized in the PKI can be relegated to some "general guidance" in
the Security Considerations section.  This is a critical function (if
EEs can't get securely initialized in the PKI, you don't have a PKI).
It must be specified in a way that is interoperable across the Internet.
 That's why Part 3 provides several examples, but mandates one (used to
be two :-).




>Support for RAs
>---------------
>It was claimed that the draft provides no means to accommodate RAs.  This
>too is an accurate observation but again we need to consider the full
>context. We take for guidance this excerpt from Part 3:
>
>"This specification explicitly allows for cases where an end entity
>supplies the relevant proof to an RA and the RA subsequently attests to the
>CA that the required proof has been received (and validated!). For example,
>an end entity wishing to have a signing key certified could send the
>appropriate signature to the RA which then simply notifies the relevant CA
>that the end entity has supplied the required proof. Of course, such a
>situation may be disallowed by some policies."
>
>Proposed Resolution:  No additional work required, other than perhaps to
>reiterate the above guidance in the 7/10 supplement.  There doesn't seem to
>be a compelling need to create additional complexity where none is required.

The difference between this proposal and Part 3 is that the Part 3
messages, as defined, can be used between an EE and an RA as well as
between an RA and a CA (this is why Part 3 accommodates RAs).  The
messages defined in this proposal cannot be used between an RA and a CA
(on behalf of some other EE).

I therefore disagree with the statement that no additional work is
required.




>CA Specification of Subject DN
>------------------------------
>It was claimed the draft requires CAs to specify subject DNs. It is however
>difficult to detect a firm basis for this observation.

I'm not surprised that you found this difficult, because this was not
the observation at all.

>Proposed Resolution:  There appears to be a misunderstanding here. There is
>no such limitation in 7/10 protocol to require the CA to decide the DNs.

This is where you having the slides from Munich would have been helpful.
 My point was exactly the opposite:  it is not that the 7/10 protocol
requires the CA to decide DNs; it is that the 7/10 protocol requires EEs
to decide DNs (because PKCS #7 and PKCS #10 require DNs in their
messages).  An EE cannot, by definition, choose its DN because there is
no guarantee of uniqueness; you *need* someone else (perhaps the CA) to
make this choice.

This gets back to the point I keep making:  in their present form, PKCS
#7 and #10 make use of an *existing* PKI (including the DNs already
assigned) to secure messages and to request new certificates.  They
cannot be used to *create* that PKI in the first place.




>D-H Certification
>-----------------
>It is true the submitted preliminary draft gave no discussion towards the
>certification of a D-H key.  However, the group would recall Dave Solo's
>delivery of Hemma Prafulchandra's paper on this topic in San Jose.  The
>7/10 draft was submitted with this work in mind.
>
>Proposed Resolution:  Adopt Hemma's paper as a baseline and reflect
>comments that propose to overcome noted limitations in parameter
>dependencies.

Again, this is where the slides would have come in handy for you.  I
discussed Hemma's proposal and showed why it could not be used in the
7/10 proposal as it stands.  [Even if you could somehow kludge things to
make it work, however, I also discussed why the limitations are too
severe and cannot be overcome  --  there is no good reason to force the
CA to have a DH certificate and even less reason to force all EEs to use
the parameters chosen by the CA.]




>Access to Public in PKCS 10 to validate message signature
>---------------------------------------------------------
>A point was raised that the only way one can implement the protocol is
>through a modification of known toolkits in order to prove possession of
>the private key.
>
>Proposed Resolution: To the contrary, the draft specifically proposes an
>alternate mechanism that enables use of off-the-shelf components.  Working
>within these constraints, a self-signed certificate is included in the
>PKCSReq message.

Again, the slides would have helped you here.  I discussed this
alternate mechanism and noted that this still doesn't work with existing
toolkits.  Certainly the self-signed certificate allows the CA to get
the public key without digging into the message content, but the CA has
no reason to trust this key (because it can't possibly build a trust
path from itself to this self-signed certificate).  Existing toolkits
will therefore have to be modified to accept as valid a message signed
with an untrusted key (a pretty undesirable situation).  [Furthermore,
this is why Hemma's proposal for PKCS #10 DH won't work; the EE will not
be able to construct a self-signed cert. using DH.]


--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------