-----Original Message-----
From: tls-bounces(_at_)ietf(_dot_)org
[mailto:tls-bounces(_at_)ietf(_dot_)org] On Behalf Of Paul
Hoffman
Sent: Wednesday, September 22, 2010 9:44 AM
To: Peter Saint-Andre; Stefan Santesson
Cc: IETF cert-based identity; ietf(_at_)ietf(_dot_)org;
tls(_at_)ietf(_dot_)org
Subject: [TLS] Why require EKU for certid?
At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote:
On 9/14/10 12:51 AM, Stefan Santesson wrote:
General:
I would consider stating that server certificates according to this
profile either MUST or SHOULD have the serverAuth EKU set since it is
allways related to the use of TSL and server authentication. At least
it MUST be set when allowing checks of the CN-ID (see 2.3 below).
Jeff and I are still discussing this topic and do not yet have
editorial agreement about how to proceed.
This is not editorial, this is definitely technical. What possible
advantage is
there to making certificates that do not have this flag set be excluded
from the
practices you are defining? That is, if a TLS client gets a certificate
from a TLS
server that the TLS server says is its authentication certificate, why
should the
client care whether or not that flag is set? That flag is an assertion
from the CA,
not from the server who is authenticating.
2.3
It would be good if we could restrict the use of CN-ID for storing a
domain name to the case when the serverAuth EKU is set. 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.
That makes no sense from an operational standpoint. The inclusion of an
EKU
has nothing to do with the decision-making for the domain name location.
In many deployments, this also affects the name constraints
processing to
perform domain name constraints also on the CN attribute.
True, and irrelevant.
There should at least 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 name constraints set
for
domain names.
Fully disagree.
I also agree that this is not something that I would ever like to see as a
required element. Applying name constraint logic in places that it should
not be performed is something that is very hard on any certificate
evaluation logic.
I think it would be much more an issue of "asking" CAs not to issue
certificates that have this characteristic.
Jim
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
TLS mailing list
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf