Steve Hanna:
I agree with you that both 3280 and X.509 require name chaining. However,
the security implications and security importance of name chaining is
overstated.
For example, if signatures chain properly for the certificate and CRL and
the relying party has appropriate means (e.g., e-mail address) to identify
the subscriber, name chaining offers little in terms of security.
My statement should be read purely in security (and NOT interoperability)
context.
-----Original Message-----
From: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: ejnorman(_at_)doit(_dot_)wisc(_dot_)edu; ietf-pkix(_at_)imc(_dot_)org;
ietf-smime(_at_)imc(_dot_)org
Subject: Re: Request change in son-of-rfc2633
Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation
needs to have their eyes checked. RFC 3280 says in many
places that name chaining MUST be checked.
In section 6.1:
To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
In section 6.1.3:
(a) Verify the basic certificate information. The certificate MUST
satisfy each of the following:
[...]
(4) The certificate issuer name is the working_issuer_name.
In section 4.1.2.6:
If the subject is a CA (e.g., the basic constraints extension, as
discussed in 4.2.1.10, is present and the value of cA is TRUE), then
the subject field MUST be populated with a non-empty distinguished
name matching the contents of the issuer field (section 4.1.2.4) in
all certificates issued by the subject CA.
RFC 2459 and X.509 both agree with this.
Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical security checks
to keep them happy. What's next? Don't bother checking the signature on
certificates. That takes too much time!
If somebody has implemented path validation without name chaining checks,
then they haven't implemented it according to IETF or X.509 standards. In
fact, they may have opened themselves and their customers up to security
holes and perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards. Users also
have a reasonable expectation of this. If someone deliberately violates
the standards in a way that opens up security holes, that sounds like
gross negligence to me.
This reminds me of Microsoft's decision to not check the
Basic Constraints extension, treating every certificate
as a CA certificate. This decision, presumably made in
to please a customer, resulted in a HUGE security hole.
I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass things because
you find it convenient.
Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.
Thanks,
Steve
Peter Gutmann wrote:
[Cross-posted back to S/MIME, where the thread started]
Eric Norman <ejnorman(_at_)doit(_dot_)wisc(_dot_)edu> writes:
Is there a claim (#1 above) that you can have the DN in the subject
of a parent's (signer's) certificate be different from (as in
different bunch of
bytes) the DN in the issuer of one of its offspring and yet the chain
is
still valid because the xKIDs match?
Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
that violates the original X.509 design, i.e. with re-parenting,
arbitrary cross- certification, etc etc where issuers no longer match
subjects). For example MS apparently implemented chaining by sKID in
Windows because of user demand for this when the users broke chaining
by issuer name through spaghetti PKI design practices, and various
other implementations no doubt do similar things, depending on how
they've read the PKIX tea leaves.
Peter.
smime.p7s
Description: S/MIME cryptographic signature