[Security] XEP-0189 Update Proposal Part 1

Justin Karneges justin at affinix.com
Sat Sep 6 16:01:40 CDT 2008


On Saturday 06 September 2008 12:54:57 Dirk Meyer wrote:
> I want to replace KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig# to
> something self-defined. xmlsig is very complicated and developers know
> how to handle X.509 certificates in PEM format. There is also much
> better support for that in SSL libraries. On the downside my proposal
> is not so XMLish. This should also be used for XEP-0250.

I think it's fine to skip the W3C KeyInfo format.  It doesn't really buy us 
anything.

> Certificate is the certificate in PEM format. If I understand it
> correctly, the PEM format is the DER format encoded with Base64. The
> BEGIN CERTIFICATE and END CERTIFACE stuff from PEM was removed.

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).

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?

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.

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

-Justin


More information about the Security mailing list