Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM

[Nicolas Williams <[e-mail]>]

On Fri, Apr 03, 2009 at 02:33:47PM +0200, [e-mail] wrote:
> Nicolas Williams wrote:
> 
> > Questions:
> > 
> > 1) Do many/most/all TLS implementations output the DER-encoded form of
> >    the server cert?  Which ones do/don't?
> > 
> > 2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
> >    hard would it be to change this?  (e.g., re-encode the cert and
> >    restart apps?)
> 
> Although the TLS spec doesn't explicitly say this, the on-the-wire
> certificate is DER encoded. There's no field specifying what the
> encoding is, so if you attempt sending PER or XER, it simply won't
> work.

Right, I doubt anyone re-encodes certs in PER or XER :)

It's BER that one should worry about.

> Some implementations might accept some limited subset of BER (to
> work around CA bugs), but even in those cases, nobody's going to
> re-encode it to DER (most likely the CA calculated the signature over
> BER encoded version -- violating all possible standards -- and the
> API would return the octets sent on the wire).

OK, thanks.

> So I don't see any problem in using the tls-server-end-point channel
> binding...

Excellent.  Thanks!

>            (and it seems it would work for OpenPGP, too)

It could be made to, but tls-server-end-point refers to the first cert
in the 'certificate_list' field of the server's Certificate message --
there's no such field in the OpenPGP case.  It'd be a trivial updat to
tls-server-end-point to allow the use of a server's OpenPGP cert though.

Nico
--