pkinit: using RSA modulus to locate private key

[Mark Phalan]

On Mon, 2008-10-06 at 15:10 -0500, Douglas E. Engert wrote:
> 
> Tom Yu wrote:
> > Mark Phalan <Mark.Phalan at Sun.COM> writes:
> > 
> >> One issue I ran into when working with PKINIT on OpenSolaris was that
> >> our tool for storing certs and keys in PKCS11 tokens (pkinit(1)) doesn't
> >> generate a CKA_ID for private keys - it leaves it blank. 
> 
> Can you change your pkinit utility? 

Yes, I've filed a bug against pktool(1). 
http://bugs.opensolaris.org/view_bug.do?bug_id=6744761
I've no idea when the KMF team will fix it though.

> But since many tokens don't store
> the CKA_ID then what?

Not sure I totally understand the question. If there is no CKA_ID set
and the RSA modulus from a cert matches a key in the token then, with
the proposed patch, that key can be used.

> 
> >> When PKINIT
> >> finds a suitable cert and then looks for a corresponding private key it
> >> fails to locate it (unless it's the only key available). I've
> >> implemented a fallback so that if PKINIT can't find a suitable key by
> >> CKA_ID it will try to find a private key matching the RSA modulus
> >> associated with its key.
> 
> Assuming you are using RSA key, that might work.

Currently PKINIT only looks for RSA keys.

> PKCS#11 2.20 says 12.1.3:
> "The only attributes from Table 36 for which a Cryptoki implementation
>   is required to be able to return values are CKA_MODULUS and
>   CKA_PRIVATE_EXPONENT"
> 
> But there might be cards where this is not true, as the card may not
> store this information.

The proposed RSA modulus fallback is only used when a key cannot be
found using the current methods. If the CKA_MODULUS is not stored then I
guess the fallback will also fail.

> 
> >> As the CKA_ID is typically a hash of the
> >> modulus it seemed to me to be a suitable fallback.
> 
> I don't believe that setting CK_ID to the hash is typical.
> OpenSC can present a PKCS#11 view of many cards, it will
> typically use 1, 2, 3... for the CK_ID and keep the same CK_ID
> for the cert, public key and matching private key,
> assuming that a CK_ID is unique only across a card.
> 
> Note that if  the MIT x509_identity with cert_id= is
> defined in the krb5.conf or pam_krb5 it will be in effect a
> constant,and thus each card used must use the same CKA_ID,
> for the "authentication" cert/key.

Right, I was wondering about the utility of that setting in krb5.conf.
However if it can be easily set manually or is "well-known" (as in your
example above for OpenSC) then it makes more sense.

> 
> >>
> >> Does this sound reasonable? I can contribute a patch.
> 
> Yes it does. I believe the Heimdal code already does something
> like this.

The patch is pretty trivial, I'll open a ticket soon.

-M