On 2011-01-29 06:06 PDT, Ambroz Bizjak wrote:
> Hello. I have a problem with NSS. Here's what I'm trying to achieve:

[  If I may paraphrase, system C sends a cert to systems A and B.  ]
[  A forwards its copy to B.  B must compare the two copies.       ]

> Here's how I encoded the certificate (on system A once handshake is 
> done, and on B inside the SSL_AuthCertificateHook callback): [snip]

Whoa!
You (re)encoded the cert from its components in A and B to compare them?
Don't!  Do compare the original encoded copies made by the cert's issuer.
Don't ever count on the ability of a decoder/encoder pair to reproduce
exactly what was input.  You always have a copy of the original DER
encoded one intact in the CERTCertificate.  cert->derCert

> However, now I decided that B needs to know the common name of C before
> C actually connects to B, for logging purposes.

B is going to log about the connection from C before it happens?
uh ...

> It could determine that by parsing the DER cerificate provided by 
> system A. [snip]

Is the connection between A and B secure?  If not, then an attacker
can defeat your design by MITMing that connection.

> Also, is this a portable way of comparing cetificates (e.g. can I be 
> sure that another SSL library will produce the same data)?

I think "this" means "re-encoding the cert from the parts and then
comparing the re-encoded certs".  IMO, No.  Maybe in a perfect world...

> I read that the DER format is specifically designed so that there is 
> only one way to encode a given input.

Yes, that was the design intent.  IMO, DER failed to deliver that intent
in several ways.  Don't count on every issuer doing perfect DER encoding.

> Is there some function that provides me with the raw certificate as 
> provided by the peer (rather than NSS deconding it and my program 
> encoding it back)?

CERTCertificate should have been opaque with accessor functions, but alas.
Just reach in and grab cert->derCert.

> Or, should I be comparing only specific parts of the certificate
> (common name, public key)?

Depends on what you're trying to accomplish, what question you're trying
to answer.  If the question is merely "are these two certs identical"
then comparing both from stem to stern is a very good way.  If you're
trying to ask "do these two certs identify the same subject", then you
may need to do much more work.

-- 
/Nelson Bolyard
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to