RE: PKCS 7/10 Security Issues

[<mmyers@xxxxxxxxxxxx>]

Carlisle--

Yes, the slides and text would have been useful.  I kept looking for them
but they never showed up.  Warwick didn't receive them either.  I don't
know if Steve received  them or not.  In any case, I've read through your
comments and arrive at different interpretations of the requirements and
the essential issues surrounding them.

--Mike





At 06:03 PM 9/9/97 -0400, Carlisle Adams wrote:
>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 :-).

Remember, we seek to establish the basis for interoperable implementations,
not assert key management policy.  Mandatory key management requirements
should be beyond the scope of a protocol specification.  It is however very
relevant to an enclave's security policy.  Given the abundant number of
alternatives to establishing a trusted public key (including those
suggested in Part 3), I would strengthen the proposed language to reflect
"critical assumptions" regarding the security of the process by which a
trusted public key is established.

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

While it may be natural to think of the RA as brokering all exchanges
between a subscriber and a CA, extensive discussions with potential RAs
suggest practical alternatives.  An RA's most important role is to affirm
to a CA the authenticity of a proposed subscriber's attributes.  To this
end, an RA could easily connect to a CA via an SSL-secured channel and
exchange application status information in whatever means is convenient to
the RA and the CA.  Given the ease with which this can be done--and it's
inherent flexibility--a standard to this effect does not add primary value.
 I must restate an opposition to complex solutions where simple
alternatives exist.  I can get the RA job done without reference to a
standard--or is it Part 3's assertion that no RA can go online on the
Internet and interact with a CA unless it uses a Part 3 interface?

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

So by inference, 7/10 is faulted because it leads to the conclusion that CA
(or some other entity) must assign DNs to users.  This is where we started
so I doubt the slides would have done much good.  Let us then call it a
"conclusion" vs. an "observation".

7/10 makes no assertions about what specific Attributes must be present in
a DN, nor does it constrain any specific Attribute to a subset of values.
Requirements on the AVAs that form a DN are implementation and operational
concerns, not protocol specification issues.

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

The issues here are readily apparent even in the absence of the slides.  It
is a false assumption that the 7 and 10 specifications can't or won't be
changed to reflect emerging market requirements.  I strongly suspect they
will be--perhaps within an IETF context.  I would welcome any comments that
contribute constructively to this evolution.


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

Actually, the slides (would) mislead the casually attentive.  A moment's
thought to the issues at hand would conclude that one should place little
trust in this self-signed certificate--it's an artifact of existing toolkit
restrictions.  Trust is established by the CA's authentication and
certificate acceptance policies.  The focus is on the public key and DN in
the PKCS 10, not the self-signed certificate.  There is no constructive
issue here.

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