Justin Karneges wrote: > Right, PEM is just the DER format encoded in Base64 with linebreaks and > header/footer. If you're going to hack PEM apart, I'd suggest simply > specifying the format here as DER encoded in Base64 without linebreaks. > Forget PEM.
OK >> Fingerprint is the fingerprint of the X.509 certificate. Evey SSL lib >> should be able to provide this. > > There is no standard fingerprint process for X.509 like there is with > OpenPGP. > X.509 certificates are commonly hashed into MD5 or SHA1. You should pick an > algorithm type and mention it in the document, or you should allow arbitrary > algorithms to be used (and specified in the XML somehow). Oh, I did not know that. In that case, yes, I need to add the hash algorithm somewhere. What about signing stuff? It also uses a hash. A quick look at the source code of tlslite looks like that the algorithm is encoded in the signature. Am I right? > For those unaware, when you see MD5 and SHA1 fingerprint hashes of > certificates, it is simply a hashing of the DER format. Therefore, everyone > should be capable of calculating fingerprints with any algorithm, even if > your X.509 library doesn't offer a direct method for doing so. > >> <signature fingerprint='428b1358a286430f628da23fb33ddaf6e474f5c5'> >> oMt+lwgGms8Ep9zBZMWteAy+LD/hZ7VzO4IiS2e+eQbSoyIF2Lh2257jX9dUJgD8 >> sr1XxMY7yYamorUY2SfzfBjKsvC4btAv7H4fCd6JEnH6PpkLifZ4Y5vZL7WAojqM >> wxLLCg420sVEuEJW56D/f+GWj+uvrQ/cAhKSx2mSY7o= >> </signature> >> >> The signature is created by calling the hash and sign function of my >> TLS library on everything between <certificate> and </certificate> >> without the whitespaces or line break. So, it is a signature of the >> PEM encoded certificate. This signature was transformed to Base64 >> after signing. > > You lost me here. Who is creating this signature? Is the certificate > signing > itself? What's the 'fingerprint' in <signature> for in this case? I admit I > didn't read the whole discussion. Maybe this is some Web-of-Trust stuff? Yes. The idea was to have clients with a different certificate. The client key was signed by a user key. This is important for bot communication. There is no CA and I need a way to mark my bot certificates as belonging-to-me. > Also, if you're going to sign the certificate, you should sign the DER. That > format is already canonicalized, no need to specially treat the PEM first, > and it would be more consistent with my earlier suggestion about DER usage. You mean sign the binary data, not the Base64 one. I thought about that, too, but it looked nicer to sign the stuff that was transmitted over XMPP. But it is ok to sign the DER certificate, that is why I wanted comments :) >> The signature is optional and there can be more than one signature. >> Besides the certificate and the signature the keyinfo may also contain >> <revoked/> or <expired/>. In that case the key should not be used >> anymore. > > What is the purpose of <revoked/> and <expired/> here? Without signatures, > they can only act as hints to the receiver to perform real validity checks. > But the receiver should be doing real validity checks all the time then > anyway, so I don't see the value in these hints. Well, the expired is more or less useless, I agree. It is only here as a hint. About the revoke: can you revoke a certificate and add that information in the certificate? The problem is a have no CA and when a client gets stolen, I want to revoke the certificate. My understanding is that you have to check the CA for revoked keys. Without a CA I need something else. The basic idea is also to use these keys for SASL-External later to provide a login for clients without giving away the password. In that case the XMPP server MUST know if a certificate is valid and allowed to be used for login. Dirk -- Due to financial problems, the light at the end of the tunnel will be shut down until further notice.
