On 25.03.23 14:28, Alexander Clouter wrote:
On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote:I ask that as you consider this thread, you think beyond Basic-Auth to the PKCS operations.I definitely am not qualified to think on this, I would be a fool to not yield to those using those attributes!Other than your group, is anyone aware of any other implementation of the PKCS machinery and using it in anger?
My group is a group of partners.
Does the draft for RFC7170bis describe completely something that your group implemented? Does it need your proposed CSR related TLV attribute to be included?
The CSR helps, and is a hindrance if it's not there. We implemented an earlier version of the spec in which we added a new mode to wpa_supplicant in which there is no intermediate result required for those last components, but it won't be a lot of trouble to reimplement based on what is in the spec.
Maybe worth bringing up is I have no idea what the language mentioned in https://github.com/emu-wg/rfc7170bis/issues/8 actually does to an implementation using these attributes; ""..in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]." what is 'degenerate' here do or mean?
Sorry- 'degenerate case'. There are two normal uses of TEAP in this case: * Just a simple EAP-TLS-like authentication (no inner eap). * Renewal flow (whether that's the trust anchor or the client cert or both).But we should be prepared for other stuff in the future. Consider a RATS attestation token as an extension, for instance. That might become part of a regular flow.
Eliot
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
