This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kwatsen
Recipients Hiroaki.Kawai, asmodai, chaen, chet, chrisburr, christian.heimes, dsoprea, dstufft, jcea, joernheissler, kwatsen, maker, miki725, mmasztalerczuk, njs, pitrou, underrun
Date 2020-01-31.15:23:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580484197.75.0.110408090094.issue18233@roundup.psfhosted.org>
In-reply-to
Content
I agree that having both would be best, but there is a world of difference between a must-have (peer_cert_chain) and what seems to be a nice-to-have (authed_peer_cert_chain).

My request for clarification was not that I don't understand bags, etc. (see my first message), but that I don't understand the concrete use case in mind.  That is, when is it that the app-logic would differ because the EE cert validated using one path versus another?

To explain the 'must-have' better, imagine one peer sending [A, B, C], where 'A' is the EE cert, and the other peer having TA [F, E, D], where 'F' is the self-signed root TA and 'D' is the Issuer that signed 'C'.  The complete chain is [A-F] and this is what the SSL-level code will use during the handshake.  But post-handshake, without peer_chain_cert(), there is NO WAY for the app-logic to create a valid chain.  This is broken, for the reason mentioned in my first message.
History
Date User Action Args
2020-01-31 15:23:17kwatsensetrecipients: + kwatsen, jcea, pitrou, christian.heimes, asmodai, njs, maker, Hiroaki.Kawai, underrun, dstufft, dsoprea, miki725, mmasztalerczuk, chet, joernheissler, chaen, chrisburr
2020-01-31 15:23:17kwatsensetmessageid: <1580484197.75.0.110408090094.issue18233@roundup.psfhosted.org>
2020-01-31 15:23:17kwatsenlinkissue18233 messages
2020-01-31 15:23:17kwatsencreate