On Tue, Dec 26, 2023 at 04:28:52PM +0200, Ilari Liusvaara wrote:
> On Tue, Dec 26, 2023 at 09:48:32PM +0900, Kazu Yamamoto (山本和彦) wrote:
> > Hi,
> >
> > I'm trying to implement channel bindings defined RFC 5929.
> > I have three questions:
>
> Also note RFC 9266. That defines how to perform SCRAM/GSS-API with TLS
> 1.3.
I'll note that during the creation of RFC 9266 the presumption was that
the relevant channel binding simply was not defined for TLS 1.3 at all, and
should not be attempted until there was an adequate specification for how to do
so.
>
> > Q2) Can "tls-server-end-point" apply to TLS 1.3?
>
> It could be appiled, but that is probably not a good idea.
I agree (on both counts).
> For SCRAM and GSS-API, "tls-server-end-point" is not used in TLS 1.3.
>
>
> > Q3) If the answer to Q2 is yes, which part is hashed?
> >
> > RFC 8446 defines Certificate as:
> >
> > struct {
> > opaque certificate_request_context<0..2^8-1>;
> > CertificateEntry certificate_list<0..2^24-1>;
> > } Certificate;
> >
> >
> > hash(Certificate) or hash(Handshake:Certificate) or
> > hash(certificate_list)?
>
> I don't think it is specified anywhere, but I think the most reasonable
> thing is neither of those, but instead re-encoding the certificate_list
> into TLS 1.2 form and hashing that. So the resulting binding values are
> compatible with TLS 1.2.
My reading of 5929 is that you are supposed to just hash the DER of the X.509
cert, not any TLS framing (but I did not check what has been implemented
anywhere), so no re-encoding would be needed, just extracting out the
right bits of cert_data (TLS 1.3) or ASN.1Cert (TLS 1.2).
But if there is any real question of ambiguity it seems that a tiny RFC is
called for.
-Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
