pkinit: using RSA modulus to locate private key

[Mark Phalan]

On Wed, 2008-10-08 at 11:56 -0400, tsitkova wrote:
> On Oct 7, 2008, at 8:16 AM, Mark Phalan wrote:
> 
> > 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.
> 
> According to PKCS11 X509 the certs and the associated key pairs must  
> have the same CKA_ID.

I don't see any such statement in PKCS #11 v2.20. In fact the following
is found in section 10.6.3:

"It is intended in the interests of interoperability that the subject
name and key identifier for a certificate will be the same as those for
the corresponding public and private keys (though it is not required
that all be stored in the same token). However, Cryptoki does not
enforce this association, or even the uniqueness of the key identifier
for a given subject; in particular, an application may leave the key
identifier empty."


> 
> >
> >
> >> 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.
> >>
> 
> CKA_ID may be generated in the numerous ways. It may be a modulus of  
> RSA, a public value of DSA,  SHA1/MD5 hash of the RSA modulus or any  
> other unique to the token identifier that maps the cert to the  
> associated key pair.
> Keeping this in mind, as a work around, it might be sufficient just to  
> extract RSA pub keys both  from the cert and the priv key and compare  
> their modulus, rather than cert's CKA_ID and the hash value of the  
> modulus of the key pair.

Indeed thats essentially what I'm proposing (except I'm asking PKCS11 to
do the comparison for me rather than doing it myself).

-M