Re: Newbie assumptions & questions
Bruno Costacurta schrieb: [...] - serial information within the certificate is useless If you are still talking of only the serial number you are correct. But if you also know the issuing CA you can uniquely identify the certificate. A CRL (Certificate Revocation List) for example works by publishing the serial numbers which have been revoked by a CA and OCSP also tells you the status of a certificate if you only tell the (CA specific) responder the serial number. As far as I understand, the serial information within the certificate is only useful as a reference for the CA. This reference can be used by the CA to revoke the certificate. Is this correct ? Yes. Is there other action that can be made by the CA on a specific certificate (ie. renew, some metadata changes...) ? The CA may keep a database, indexed by the serial number, containing some information about the certificate (OpenSSL's CA command does this in the form of the index-file). So like you said the serial can help the CA to find metadata about a certificate, probably including the certificate itself (like in the OpenSSL CA). If the metadata contain the CSR (OpenSSL CA index does not) it would be possible to re-issue a certificate, possibly with modified metadata. Thanks, Bruno Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: Newbie assumptions & questions
On Friday 23 February 2007 15:32:54 Bernhard Froehlich wrote: > Bruno Costacurta schrieb: > > Hello, > > > > as a newbie, I have some assumptions / questions hereafter about OpenSSL > > and certificates. Many thanks to correct / confirm me. > > > > - a certificate is a public key with metadata > > - metadata contain mandatories (ie. subject and issuer) and optional > > parameters > > - there is no relation between the key algorithm (ie.RSA) and the format > > of the certificate (ie.PKCS#12) > > - a certificate can always be converted to another format > > - the certificate request (.csr) is obsolete (and so should be deleted) > > once the certificate is created by the CA > > - technically speaking a 'home-made' CA is egual to a 'professional' CA > > Almost 100% correct till here (PKCS#12 is not a format specific for > certificates but "a bag" which can contain certificates, keys and > probably other things). > > > - the CA remains fully secure as long its private key remains > > undistributed / uncompromised > > ... and the key is strong enough not to be broken (brute force or > otherwise). And your procedures are good enough that noone can trick you > into issuing fake certificates. And many things more. So what you are > saying is one important part of the truth, but you can probably spend a > lifetime with the rest of it. > > > - for a CA, files serial & index files allows to maintain a (type of) > > database to persist which certificates (with related metadata values) > > were created by this CA > > Almost correct. The serial file has to make sure that there are no two > certificates with the same serial number issued by the same CA. > > > - serial information within the certificate is useless > > If you are still talking of only the serial number you are correct. But > if you also know the issuing CA you can uniquely identify the > certificate. A CRL (Certificate Revocation List) for example works by > publishing the serial numbers which have been revoked by a CA and OCSP > also tells you the status of a certificate if you only tell the (CA > specific) responder the serial number. > As far as I understand, the serial information within the certificate is only useful as a reference for the CA. This reference can be used by the CA to revoke the certificate. Is this correct ? Is there other action that can be made by the CA on a specific certificate (ie. renew, some metadata changes...) ? Thanks, Bruno > > - can a certificate contain more than one public key ? > > That beats me. I don't think the typical client (that is, a browser) can > handle multiple keys of the subject if it would be possible to encode > it. And I cannot think of possible uses for multiple keys in one > certificate. Of course more public keys could be included as certificate > extensions if you write your own sofware that does something with these > extensions. > > > Thanks for attention. > > Bye, > > Bruno > > Hope it helps. > Ted > ;) -- Bruno Costacurta PGP key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- pgpB8RZB00mvt.pgp Description: PGP signature
Re: Newbie assumptions & questions
Bruno Costacurta schrieb: Hello, as a newbie, I have some assumptions / questions hereafter about OpenSSL and certificates. Many thanks to correct / confirm me. - a certificate is a public key with metadata - metadata contain mandatories (ie. subject and issuer) and optional parameters - there is no relation between the key algorithm (ie.RSA) and the format of the certificate (ie.PKCS#12) - a certificate can always be converted to another format - the certificate request (.csr) is obsolete (and so should be deleted) once the certificate is created by the CA - technically speaking a 'home-made' CA is egual to a 'professional' CA Almost 100% correct till here (PKCS#12 is not a format specific for certificates but "a bag" which can contain certificates, keys and probably other things). - the CA remains fully secure as long its private key remains undistributed / uncompromised ... and the key is strong enough not to be broken (brute force or otherwise). And your procedures are good enough that noone can trick you into issuing fake certificates. And many things more. So what you are saying is one important part of the truth, but you can probably spend a lifetime with the rest of it. - for a CA, files serial & index files allows to maintain a (type of) database to persist which certificates (with related metadata values) were created by this CA Almost correct. The serial file has to make sure that there are no two certificates with the same serial number issued by the same CA. - serial information within the certificate is useless If you are still talking of only the serial number you are correct. But if you also know the issuing CA you can uniquely identify the certificate. A CRL (Certificate Revocation List) for example works by publishing the serial numbers which have been revoked by a CA and OCSP also tells you the status of a certificate if you only tell the (CA specific) responder the serial number. - can a certificate contain more than one public key ? That beats me. I don't think the typical client (that is, a browser) can handle multiple keys of the subject if it would be possible to encode it. And I cannot think of possible uses for multiple keys in one certificate. Of course more public keys could be included as certificate extensions if you write your own sofware that does something with these extensions. Thanks for attention. Bye, Bruno Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Newbie assumptions & questions
Hello, as a newbie, I have some assumptions / questions hereafter about OpenSSL and certificates. Many thanks to correct / confirm me. - a certificate is a public key with metadata - metadata contain mandatories (ie. subject and issuer) and optional parameters - there is no relation between the key algorithm (ie.RSA) and the format of the certificate (ie.PKCS#12) - a certificate can always be converted to another format - the certificate request (.csr) is obsolete (and so should be deleted) once the certificate is created by the CA - technically speaking a 'home-made' CA is egual to a 'professional' CA - the CA remains fully secure as long its private key remains undistributed / uncompromised - for a CA, files serial & index files allows to maintain a (type of) database to persist which certificates (with related metadata values) were created by this CA - serial information within the certificate is useless - can a certificate contain more than one public key ? Thanks for attention. Bye, Bruno -- Bruno Costacurta PGP key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- pgpEJ1qgajTmB.pgp Description: PGP signature
