[Security] XEP-0189 Update Proposal Part 1

Dirk Meyer 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.

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.


More information about the Security mailing list