[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO
New version.The change between this one and the previous version is simply that a token may or may not support the use of CKA_PUBLIC_KEY_INFO in templates of commands that create a private key - token's choice. If a token does support that attribute for those commands, it is required to validate the relationship between the public key info and the private key before creating the private key.
This I think addresses both Peter's concern about being able to figure out what is going on (and dealing with inconsistency) and Robert's concerns about needing to implement a DER parser.
Unless I hear further on this with specific proposals for change in the next 2 weeks, I'm going to declare victory and move on.
Mike On 5/13/2013 12:25 AM, Peter Gutmann wrote:
Michael StJohns <msj@nthpermutation.com> writes:For DSA and EC keys, the public key can be derived from the private key info. For example, the public key for an EC private key is Pub = priv * G where G is the generator point on the curve and "priv" is the scalar that makes up the EC private key. This is a multiplication on the curve. Given that the curve info (including G) is part of the required info for an EC private key in PKCS11, you can always derive the public key from a private key.This works OK in a software-only implementation where you've got access to both the key components and a set of bignum maths routines, but how is it supposed to work for hardware? In software it's easy enough to calculate y = g^x mod p (for DLP) or Q = d * G (for ECDLP), but if your x or d are locked up in hardware (which I assume they are) then your token will need to perform the operations, you can't do them in your driver and you definitely shouldn't be asking the user to do them in their application (which they can't anyway, since they can't get at x/d).Again - this was a compromise based on a push back. I'm perfectly happy to make this a MUST, but there was sufficient FUD being tossed about that I just punted. I agree with you, but I wasn't willing to force all products to comply.As an application developer I would rather have it a MUST and some vendors can choose to be non-compliant, rather than have it a MAY and have to guess at which vendors do it, add kludges if possible, and otherwise just tell users "you can't use tokens from this vendor". If the vendor doesn't implement the MUST then it makes it obvious that you can't use their tokens, with a MAY you have to experiment around with every token to see what it does and how it reacts to attempts to get the public components. Peter.
Attachment:
pkcs11-cka-public-key-info-r3.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]