[Twisted-web] Question regarding custom contextFactory for twisted.web.client.Agent

[Jean-Paul Calderone]

On Mon, Jul 3, 2017 at 12:58 AM, Jason Litzinger <jlitzingerdev at gmail.com>
wrote:

> > The cryptography APIs for making certs are pretty straightforward and
> well
> > documented.  But if another example helps, here's some code that creates
> a
> > self-signed ca cert and a client cert with an intermediate cert in
> between:
> >
> >
> > https://github.com/LeastAuthority/txkube/blob/
> faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/
> test_authentication.py#L17-L29
> >
> > https://github.com/LeastAuthority/txkube/blob/
> faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/
> test_authentication.py#L276-L309
>
> I'm diving into adding benchmarks for testing HTTPS and this has been
> very helpful.  I did have one question, in the cert function
> neither the pubkey or privkey parameters are used, rather, a_key is
> always used as both the public and the signing key.  Is that
> intentional?
>
Or, should the public key be the pubkey value and the signing key the
> privkey value?  Meaning, each cert uses the supplied public key and the
> signing order is:
>
>     a signs a
>     a signs b
>     b signs c
>
> If so, do you want me to send you a PR for this change?
>
>
Heya Jason,

Thanks for pointing this out.  Yes, it's a bug.  Also, it turns out
re-using serial numbers is a bad idea too.  I don't think their mistake
*currently* hurts the tests but it would be great to get them both fixed.
So a PR would be quite welcome.

Regarding Glyph's comments about where the chain is verified - that's still
handled by the TLS library.  The Chain invariant in _authentication.py is
just a superficial sanity check to catch the common problem of "a-b-c" vs
"c-b-a" chain certificate order.

Thanks!
Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-web/attachments/20170703/96d07f81/attachment.html>