Public key identifier

     >So, *do* you actually have any legitimate issues to be raised
     >regarding the PEM-MIME document?  If you do, please raise them now.  
     >This is the time!!!
     
Thanks Ted for that compelling invitation.

Of all the identifier forms outlined in the PEM/MIME draft for use in 
Originator-ID and Recipient-ID fields, we believe that the public key 
identifier alone is sufficient:
     
     <id-publickey>  ::= "PK"  "," <publickey> [ "," <id-subset> ] CRLF
     
     <publickey>     ::= <encbin>
                        ; a printably encoded, ASN.1 encoded public key (as 
                        ; defined by the 'SubjectPublicKeyInfo' production 
                        ; specified in X.509)
     
     The optional <id-subset> should be omitted.
     
Our position is that the public key is a sufficient key identifier for 
use in signing and encrypting and that adding name forms or key 
selectors in the main messaging protocol is an unnecessary 
complication:
     
* The public key is sufficient information for the application to 
determine the name it has bound to the key, whether it be a 
distinguished name in an X.509 certificate, an email address in an 
authenticated table, etc.  The application may then present the name 
to the user.
     
* Putting a name form such as a distinguished name or email address in 
the message is cryptographically irrelevant.  Especially in the case 
there there are multiple names associated with a key pair, only the 
public key is used for encryption (or the associated private key for 
signing), and therefore only this can be cryptographically verified.  A 
secure application should not trust any transmitted name information.  
Instead, it should use its own certification or other local 
authentication mechanisms to look up the trusted name binding based on 
the public key and display this to the user.
     
* An application has the option to "suggest" a name/key binding when 
sending a message by including an application/key-data body part 
containing a certificate.  The receiving application can use this, for 
example, to get a candidate distinguished name if a directory server 
is being used which cannot be indexed by public key.
     
* For similar reasons, there is no need for "backwards compatibility" 
with the issuer/serial identifier from RFC 1421.  If an application is 
converting from an RFC 1421 message to a MIME message, it can use the 
issuer/serial to look up the public key to put in the MIME message. 
And an application which has a certificate database from an RFC 1421 
implementation already has the public keys.  No new information is 
required.
     
For use in Originator-ID and Recipient-ID field, we find no cogent 
argument, either in the Draft or in the various discussions, for the 
complication of the variety of name forms and key selectors.  
Therefore, in our cryptography toolkits and implementations we intend
to only support the public key identifier.

Since there seems to be no "minimal subset requirements" surrounding 
the key identification (and since the spec. feedback process seems to
be broken) we are left with the assumption that our implementation will
not be compliant.
     
For anyone interested in interoperating with our applications and 
applications which use our toolkits, we are asking for prompt 
feedback as we proceed in designing the next version of our software. 
Have you found a compelling reason why we should use other than just 
the public key identifier?
     
     
     Steve Dusse
     RSA