AD asks: (16) section 11.3: might need to warn against dodgy username values,e.g. containing a null character or whatever. I think you need some more rules there to end up with a safe rfc822name in the cert. (Or else have an argument that that's not a problem for RELOAD - it has been a problem elsewhere.) Also, does the enrollment server choose the domain component of the rfc822 name or may that be supplied by the client?
First question I think we can address by an edit: change 11.3 says :"Enrollment servers SHOULD take care to only allow legal characters in the name (e.g., no embedded NULs), rather than simply accepting any name provided by the user." We can make the SHOULD a MUST and add reference to RFC 4013. The second question was raised at the meeting in IETF 85: Does the enrollment server choose the domain component of the rfc822 name or may that be supplied by the client? This is the same question as: Is the domain part of the username the same as the domain name of the overlay, or can the overlay support usernames in multiple domains? This has a big impact on some use cases, such as having multiple enterprise-specific name spaces in a shared overlay. For example, if [email protected] and [email protected] are two different people and neither wants to change their username part, can one overlay suit them both? -- Dean _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
