[Security] XEP-0189 Update Proposal Part 1
dmeyer at tzi.de
Sat Sep 6 16:21:25 CDT 2008
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.
>> 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'>
>> 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
> 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
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.
Due to financial problems, the light at the end of
the tunnel will be shut down until further notice.
More information about the Security