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_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
