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.
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?
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?
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.)
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?
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.
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.)
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.
Wan-Teh Chang
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf