With one minor concern, I do believe this draft is ready for publication as a proposed standard. However I think this draft is fairly rough as proposed standards go; I expect that we will end up needing a new revision of this spec at some future point that refines some of the details based on implementation experience. That's what our process is all about, so I am not bothered. The following requirement is impossible to implement: > If a client requires anonymous communication then the client MUST > check to make sure that the ticket in the reply is actually anonymous > by checking the presence of the anonymous ticket flag. This is As it turns out, a client cannot check ticket flags: it doesn't actually know the key needed to decrypt the ticket. Perhaps you mean that the client should check the KDC flags. Additionally, there are a few areas in which the spec is unclear. These could be fixed now or fixed in a future revision of the spec. First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Second, if I provide the anonymous name to a KDC in an AS-REP with the anonymous option set, but don't provide padata, should I expect a preauth_required error from the KDC listing pkinit? _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf