I was made aware of these comments that in some mysterious way didn't make its way to my inbox. Sorry for the delay.
Comments in-line; Stefan Santesson Program Manager, Standards Liaison Windows Security >Date: Tue, 28 Feb 2006 10:54:35 -0800 >From: Wan-Teh Chang <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: ietf@ietf.org >Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping > Extension' toProposedStandard > >Russ Housley wrote: >> >>We all know that there is not going to be a single name form that is >>useful in all situations. We also know that you cannot put every >>useful name form into the certificate. In fact, the appropriate value >>can change within the normal lifetime of a certificate, so putting it >>in the certificate will result in high revocation rates. >>This is the reason that I believe this TLS extension will be useful in >>environments beyond the one that was considered by the Microsoft >>authors. Your perspective may differ .... > >I agree. A rationale like the above would be a good addition to the >Internet-Draft to strengthen its motivation. > <Stefan> This could easily be accommodated in the rationale section. >Re: EKR's suggested alternatives > >While adding a new HandshakeType will incur the costs of a Standards >track RFC, we should not go out of our way to avoid it. The proposed >solution in the Internet-Draft looks clean and natural to me. > >Instead of adding a new HandshakeType, can we extend the Certificate >message to include the user mapping data list as ancillary data? > <Stefan> I really don't think we should mess with the certificate message as it is widely deployed as it is and does not include extensibility to accommodate name hints. >Re: draft 02 > >1. Sec. 5 "Security Considerations" says: > > - The client SHOULD further only send this information > if the server belongs to a domain to which the client > intends to authenticate using the UPN as identifier. > >I have some questions about this paragraph. > >How does the client determine which domain the server belongs to >without asking the server? > <Stefan> This must be up to local policy. There are many ways the client can have or obtain this knowledge. E.g. the client could know this from the host address it is using for connecting to the server. >Should the server send its domain to the client in the ServerHello >user-mapping extension? (This would be analogous to the >certificate_authorities field in the CertificateRequest message.) > <Stefan> I don't think there is a need for any new mechanisms here. >Is it possible or common for a client to belong to multiple domains and >have multiple UPNs? If so, how does a client that belongs to multiple >domains pick a UPN to send to the server? > <Stefan> Yes, that is possible and also a typical issue for local policy on the application layer. The client application, in cooperation with the user will know what account it is trying to access, this will according to local policy translate to a UPN. The protocol we define here only describes how to communicate that UPN, not how you conclude the UPN for a client. The important fact is that having many UPNs for a single user is possible using the same certificate. This standard proposal enables that. >2. It would be good to define at least one other UserMappingType as a >proof that the framework can be applied to a non-Microsoft environment. > <Stefan> We can't define a new user mapping type just to have one more. There has to be a use case with a need for one. The current hint can be used with a wide set of account names in practically any environment that use the principles of [EMAIL PROTECTED] But the extensibility is there in case a new need is there in the future. The security AD (Russ) has assisted in developing that part of the document. It also worth noting that the RedHat team has publicly said that they are also considering using this standard with the same name form. >3. If the UserMappingDataList and Certificate messages may be sent in >either order, it would be good to specify that UserMappingDataList be >sent after Certificate. >This order would highlight UserMappingDataList's role of providing >additional information to augment the certificate, and the implicit >requirement that UserMappingDataList only be used in conjunction with a >client certificate. (I assume that the server cannot send a >ServerHello with user-mapping extension without following with a >CertificateRequest message.) > <Stefan> No, you need the user mapping before you can validate the certificate. The server uses that data to locate the information it needs to successfully verify the certificate sent in the next step. The current order is therefore more logical. >4. I'd be interested in a use case that elaborates how a server uses >the UpnDomainHint and the client certificate to locate a user in a >directory database and what the server can do when the user has been >located. > <Stefan> In our current primary use case the UpnDomainHint carries the name of an domain user account. The server locates that account and retrieves the certificate of that user that maps to this account. The server then checks that the validated certificate sent over the TLS handshake is consistent with the internally retrieved certificate. This relieves the client from the requirement in current environments to carry a UPN name in the client's certificate and as such enables use of legacy PKI deployments. It is important to note that this relieves the user from dependency on Microsoft PKI deployment. That is the customer's requirement and the rationale for doing this. >Wan-Teh Chang > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf