First of all, I'm sorry for my late review.
Time has been totally crazy after my vacation and I have worked nights and
weekends in order to get to the point where I could go through this with the
care it deserves.
In case it matters, here are my comments:
General:
consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI
systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively
include [PKIX] brackets to clarify that it references RFC 5280.
General:
I find the distinction of target and source domain as both confusing and
unnecessary for defining rules for name matching. This seems only to be
relevant in the discussion of whether the source information need to be
derived from a user but I don't find that distinction useful. See discussion
concerning section 5.1. I think the document would benefit from reducing
this discussion to the distinction between reference identifier and
presented identifier.
General:
I would consider stating that server certificates according to this profile
either MUST or SHOULD have the serverAuth EKU set. At least it MUST be set
when allowing checks of the CN-ID (see 2.3 below).
1.3.2 and section 3
SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt
Name (otherName form) RFC 4985.
This error is repeated in section 3, bullet 4, on page 16.
1.1.
s/an application services/an application service
1.2
I find the following text is hard to understand:
³(this document addresses only the DNS domain name of the application
service itself, not the entire trust chain)²
I¹m not sure what the DNS domain name has to do with checking the entire
trust chain. Further, this document discuss more name forms than the DNS
domain name.
Perhaps this sentence was meant to say:
"(this document only addresses name forms in the leaf server certificate,
not any name forms in the chain of certificate used to validate the server
certificate)"
2.3
Allowing use of CN-ID, especially commonName for storing a domain name
should be restricted to the use of the serverAuth EKU. It should not be
allowed to do this matching in absence of this EKU. Requiring the EKU reduce
the probability that the CN-ID appears to be a domain name by accident or is
a domain name in the wrong context.
In many deployments, this also affects the name constraints processing to
perform domain name constraints also on the CN attribute.
There should be a rule stating that any client that accepts the CN attribute
to carry the domain name MUST also perform name constraints on this
attribute using the domain name logic if name constraints is applied to the
path. Failing this requirement poses a security threat if the claimed domain
name in CN-ID violated the neame constrints set for domain names.
4.4.3 checking wildcard labels
The restriction to match agains only one subdomain seems to not be
compatible with FRC 4592. RFC 4592 states:
A wildcard domain name can have subdomains. There is no need to
inspect the subdomains to see if there is another asterisk label in
any subdomain.
Further, I'm pretty sure that the rule of this draft is incompatible with
many deployments of wildcard matching.
4.6.2
States:
In this case, the
client MUSTverify that the presented certificate matches the cached
certificate and (if it is an interactive client) MUST notify the
user if the certificate has changed since the last time a secure
connection was successfully negotiated
How does the client know if the certificate has changed or whether it just
obtained an unauthorized certificate?
I guess in some cases it would work but I feel sure there are exception
cases where the client just has a configured certificate but no knowledge of
what it obtained the last time it talked to the server.
5.1. Service delegation:
It seems reasonable that service type can be selected by the client
application (which obviously may know what service it want to communicate
with) and consequently need not to be provided by a human user).
The requirement in this section that the service name MUST be provided by
user input:
When the connecting application is an interactive client, the source
domain name and _service type_ MUST be provided by a human user (e.g.
when specifying the server portion of the user's account name on the
server or when explicitly configuring the client to connect to a
particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
the user inputs in an automated fashion (e.g., a host name or domain
name discovered through DNS resolution of the source domain).
Seems to contradict the corresponding description in 3.1:
o An SRV-ID can be either direct (provided by a user) or more
typically indirect (resolved by a client) and is restricted (can
be used for only a single application).
I can also see valid cases where the domain name is provided by automatic
resolution of information retrieved from the internet or local network, like
redirects to a SAML IdP, obtaining URLs from downloaded data from trusted
sources and enterprise networks with central configuration (e.g group
policy).
I think it would be better if this section, and related discussions
throughout the document, talked about service and domain information in the
context of the client¹s ³reference identity² and the server¹s ³presented
identity², provided in section 1.1. I think that could clear things up.
With that change I think the whole notion of source and target domain can be
removed from the document.
/Stefan
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf