Impersonation Certificates - proofing IC requesters

["Carlin Covey" <ccovey@xxxxxxxxxx>]

Gentlepersons,

draft-ietf-pkix-impersonation-00.txt describes a mechanism for 
delegating authority from entity A (who is not a CA) to entity B 
by issuing an "Impersonation Certificate" (IC) to entity B that 
is signed using entity A's PKC.  

Below step 5 of section 2.4. the following text appears:

   "The process of creating an IC is as follows: 
    
   1. A new public and private key pair is generated. 
       
   2. An unsigned IC request is created, conforming to the profile 
      described in this document. 
       
   3. The IC request is signed by the private key of the EEC, or by 
      another IC.  During this process, the unsigned IC is verified to 
      ensure that it is valid (e.g. it is not an EEC, the IC fields are 
      appropriately set, etc). 
    
   When an IC is created as part of a delegation from entity A to 
   entity B, this process is modified by performing steps #1 and #2 
   within entity B, then passing the IC request from entity B to entity 
   A over an integrity checked channel, then entity A performs step #3. "

[Carlin's comments/questions]:
I'm trying to understand some of the security aspects.
I don't see any discussion of proofing the IC requester.  How 
does the EE authenticate the identity of the IC requester?  
A CA or RA normally has some sort of proofing facilities 
available that are used to authenticate the identity of a 
human being (e.g. a database of employee information, some 
expertise in recognizing legitimate paper identity documents, 
etc.)  An EE is probably not well-equipped to do this sort 
of human identity proofing.  Moreover, in the example in 
section 2.3 the IC requester appears to be some automated 
process.  How does the EE authenticate the identity of this 
process?  Even if the EE can authenticate the source of the 
IC request, how are man-in-the-middle attacks prevented 
during the IC request process?  

- Carlin Covey
  Cylink Corporation