Message-ID: <3F9FD56A.771A262C@sun.com>
Date: Wed, 29 Oct 2003 09:57:46 -0500
From: Steve Hanna <steve.hanna@sun.com>
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
CC: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org
Subject: Re: Request change in son-of-rfc2633
References: <200310290337.h9T3bu208738@cs.auckland.ac.nz>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
 micalg=sha1; boundary="------------ms58E8539260192E6D326EA0C4"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk


This is a cryptographically signed message in MIME format.

--------------ms58E8539260192E6D326EA0C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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@doit.wisc.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.
--------------ms58E8539260192E6D326EA0C4
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMDI5MTQ1NzQ2WjAjBgkqhkiG9w0BCQQxFgQU4GYH3SPbd16nT9xTo5bjvv/V
bmMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBJKLwc
TwwpH14dBh0aE4gn3MRkvi2+fKiDitHUq5TeivEOYZK5rN0eXbxESLuxNnYl+Cp5zrdhvokV
8ThIbRyqfsorBhQ0P0GB7h72pEkfCxExzHBjtQsfqP6q5JMpup/zWWm3xHLbQlz9XtpGSwKo
xHrTgWBxWsHAMTWnOKeeSA==
--------------ms58E8539260192E6D326EA0C4--