Hi Joe, I’m okay with most of this text except for as follows:
> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU > specified in RFC 3770. The above sentence is unnecessary. Of COURSE CAs can issue certs with that EKU or any other. What I think you mean is this: CAs issuing certificates intended for use by EAP servers SHOULD specify the id-kp-eapOverLAN EKU specified in RFC 3770. [I am even tempted to say MUST, but I don’t think we ca go that far.] […] > 3. If the above options are not available then separate trust roots need to > be used to issue certificates for EAP-TLS server and for TLS servers. I don’t think this is sufficient. Rather, I would discuss the logic behind it. In particular, I would state quite clearly something along the following lines: “EAP peers need to have some basis to decide which networks are authorized. A key signal for this purpose is the validation of the server certificate. To prevent use of the wrong server, the peer SHOULD have some means to select and update appropriate trust anchors. How this happens is beyond the scope of this memo." > EAP TLS peer implementations MUST allow for configuration of a unique trust > root to validate the server's certificate. This statement seems independent of the previous one, and may be overly broad. Let me give you an example: a device may be designed only to operate as part of a federation. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
