[Emu] slight table glitch in Section 4.3.2 of draft-ietf-emu-rfc7170bis

[Eliot Lear]

I think there’s some confusion (and maybe it’s mine) with regard to when a TLV is permitted.  The Table in 4.3.2 suggests that a PKCS#10 TLV can only be sent as a response.  But as the peer may do so in an unsolicited fashion (e.g., with a certificate request), it can be sent as a request.  Similarly, a PKCS#7 TLV is likely to be sent as a response in any case.

   0-1 0-1         0-10PKCS#7

0-1 0-100PKCS#10


Eliot

I am not sure we should simply reverse these fields.  I am a little concerned that we’ll end up in some deadlocked situations.  I think it’s safe to say that if the client isn’t requesting anything but needs to respond, it’s using a response, but in all other instances.  I’m also a little uncomfortable with requests and responses being unprotected, while the content is.  That may represent a reveal.  I don’t think that can be fixed in this version, tho. In any case, at least for the time being, I propose that the table be updated as follows:

OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org