Hi,
Thank you for your comprehensive reply.
--- About the algorithm from rfc 3280 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). ---
Does this SECItem contain the value of the BIT STRING subjectPublicKey? CERTCertificateRequest.subjectPublicKeyInfo.subjectPublicKey
What does "the value of" mean? is it like the modulus in a RSA key?
Nelson B wrote:
Emil Assarsson wrote:
I want to create a "Subject Key ID" extension and place in a certificate. My plan is to follow RFC 3280 (Page 27) and sha-1-hash the public key.
Are you a CA?
The software I'm trying to build is a CA software, yes. I want it to be able to issue certificates with SKI.
If the administrator wants certificates to have SKI extension, he should be able to choose witch algorithm to use. My plan is to implement the sha1-hash method first.Subject Key ID and Authority Key ID extensions are generally created by a CA, not by the party requesting the cert.
Can I use CERTCertificateRequest.subjectPublicKeyInfo.subjectPublicKey? Or must I encode the key to DER first?
As the CA, you can use any algorithm that you see fit, that is likely to produce unique results for each key that you certify. You can hash the key, raw or encoded; you could even keep a table of all the keys you receive, and use the index into that table (a monotonically increasing index) as the key id, if that's what you choose as the CA. But you should be consistent about it. And no two CAs need to choose the same algorithm for mapping keys into key IDs.
I think it's better to use a algorithm that don't need to have a database.
As a CA, if you receive a cert request that contains a particular subject key ID value, you are not obligated to use that value, and probably should not use it, unless it just happens to match the value that you would choose anyway. The discussion in RFC 3280 on page 27 about a "previously established identifier" doesn't mean "identifier found in the request". Rather it means that if the CA has previously issued a cert with this public key in it, and that cert has a subject key ID, then the CA should use that same subject key ID in any subsequently issued certs with that same public key in them.
This is the part I want to comply with: --- from rfc 3280 For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates.
For end entity certificates, subject key identifiers SHOULD be derived from the public key. Two common methods for generating key identifiers from the public key are identified above. ---
By cross-certifications I mean to use a certificate issued by one issuer and sign it with a new.I can't find any example code for this.
This is what I have for the moment. It works but the SKI does not match the original certificate when I'm doing cross-certifications (on a bunch of certs).
Doesn't match the original certificate?
I do this mostly to test if I get the same results as other CA softwares. Thereby filtering out a lot off strange bugs.
But Hey! All the others may be wrong :-(
Let me explain: No code except the CA's own code that issues the cert, should ever be trying to create the key ID from the key. USERS of issued certs should be trying to match the "authority key ID" in one cert against the "subject key ID" in the issuer's (CA's) cert, and they should do so without any knowledge of the issuer's key id generation algorithm. They should NOT be trying to compute a key ID of their own from some cert and then match that up with key IDs computed by someone else.
BTW, This is why RFC 3280 says that only CA certs need subject key IDs, and root CA certs do not need authority Key IDs.
--- ski = PK11_MakeIDFromPubKey( &(request->subjectPublicKeyInfo.subjectPublicKey));
This function doesn't create a Subject Key ID extension. It creates a PKCS11 ID attribute (CKA_ID) value. (And it's just a duplicate of SHA1_HashBuf.)
As a CA, you *could* choose to use this function to generate your SKID. But it sounds to me like you're not a CA, and you're trying to duplicate the key->SKID generation algorithm used by some CA, for some reason. That approach is doomed, I'm afraid. Remember, not all CAs use the same algorithm to map keys to key IDs.
if(NULL != ski) { encodedSki = SEC_ASN1EncodeItem (NULL, NULL, ski, CERTSubjectKeyIDTemplate); CERT_AddExtension(extHandle, SEC_OID_X509_SUBJECT_KEY_ID, encodedSki, PR_FALSE, PR_TRUE); } else { puts("failed to create SKI"); }; ---
Emil Assarsson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
