Alan DeKok <[email protected]> wrote: >> Alan DeKok <[email protected]> wrote: >>> * CAs should validate (somehow) any CSR they receive, to check that >>> the contents are reasonable >> >> I guess this is the new section 3.2.8.
> Yes.
>> There are quite a number of subtlies here. First, the CSR is not
>> really that complex :-)
>>
>> more importantly, there are not really any standard ways to
>> communicate with CAs about exceptions, about things that in the CSR
>> that need to be added or ignored.
> I don't think there's a possibility for such negotiation. I'm not
> even sure such negotiation would be a good idea.
I mean, between the EAP-peer and the CA.
(Not between the EAP-peer and supplicant)
> That doesn't solve the issue of what the EAP peer does, though.
> Mostly it could be "have a GUI / API to expose a few fields for
> configuring the CSR", and that's about it.
I think that's probably even excessive.
It would be good to have an operational document that says what operators
actually need what. I think that it's mostly a question of if you give
operators options, they will just do weird things for not well understood
reasons.
I think that the client certificate needs a SubjectAltName, probably an
rfc822Name, but MAYBE another GeneralName.
And, maybe, a DN. There is no CSRattributes that can specify the DN today.
> The only thing this document can do is to suggest "here be dragons",
> and then move on to other subjects. It may take operational experience
> to fully understand what are the best options here.
CSRattributes gives lots of power, but I don't think the end user needs any
input other than inputting their email address. (Assuming, it can't be
gotten from elsewhere on the system. I'm thinking @me.com, @live.com, ubuntu-1
account)
>> Probably some reference to the 4.2.18. CSR-Attributes TLV section.
>> And I see that you have dealt with the Base64 goof (RFC8951), and the
>> new format. I would welcome your comments on the latest document, and
>> to David van Oheim's proposal that is coming up in some slides at the
>> next meeting. TEAP is likely a good greenfield for his simplified
>> view.
> I'll take a look.
It's not written up, having been discussed in detail only last Wednesday.
I'll get slides posted to LAMPS in the next week.
But, the short of it: Here is an CSR, please fill in the blanks.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
