Hi Eliot You bring up a good point, namely the deployment environment. Are we are talking about an IoT, an enterprise deployment environment or something else? Clearly there will be differences. Reading through the text my impression was that this is about an enterprise (or university) deployment environment.. I might, however, be on the wrong track here.
Having the references to where deployment problems with large certificates/certificate chains occur would shine light on this aspect. Ciao Hannes From: Eliot Lear <[email protected]> Sent: Tuesday, March 24, 2020 10:02 AM To: Hannes Tschofenig <[email protected]> Cc: Michael Richardson <[email protected]>; [email protected] Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Good morning Hannes Also, from deployment experience, EAP peers typically have longer certificate chains than servers. I would like a reference to be included here. Theoretically, it makes no sense to have a certificate chain for an EAP peer to have a longer certificate chain than a server given a EAP peer talks to one EAP server. In network access authentication it is not only about authentication but the most important part is authorization. Hence, you pretty much always have a one-to-one relationship between the EAP peer and the EAP server. There are no good reasons to have complex CA hierarchies here. Not sure I entirely understand you. A few places are promoting new roots for manufacturers. And so the initial chain for a peer might look like CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it may be possible to remove one of the intermediates, but probably not both. It seems to me that this is an onboarding problem, and the best way to reduce the cert chain size on a day to day basis would be to swap out for an operational cert where the trust anchor is within the enterprise. That means you get one of those Big Fat transactions and then things settle down, and that transaction may be handled specially anyway. One comment I have in the draft relates to this text: o Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate. This statement is just a little too general. It very much depends WHICH certificate we are discussing. If it is a manufacturer certificate, as long as you can roll to an enterprise cert, then who cares? If it is an enterprise certificate, then we have to look more closely. So for instance, as Hannes mentions, authorization is a big issue. Some of that can be done outside of the certificate using ACE or similar, but some may need to be present in the cert. What we would rather not have is people working the SAN to introduce authorization attributes. Eliot IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
