Another query on draft-ietf-ipsec-pki-req-03.txt

"Walker, Jesse" <jesse.walker@intel.com> Tue, 19 October 1999 16:40 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA01934; Tue, 19 Oct 1999 09:40:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21353 Tue, 19 Oct 1999 11:04:30 -0400 (EDT)
Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242C57@hdsmsx31.hd.intel.com>
From: "Walker, Jesse" <jesse.walker@intel.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Another query on draft-ietf-ipsec-pki-req-03.txt
Date: Tue, 19 Oct 1999 08:06:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Section 3.2 says
	The subject field in IPsec certificates SHOULD be populated and
non-null
	(this is contrary to the PKIX certificate profile, which says
thatthe subject
	MUST NOT be populated if the identification is in thesubjectAltName
	field). The exact contents of this field are notstandardized. By
convention, a
	minimal subject field containscountryName and commonName.
Distinguished
	names SHOULD be no more thanfour attribute/value pairs, each of
which
	SHOULD be no more than 128 characters in length (these restrictions
do
	not appear in the PKIXcertificate profile). An IKE implementation
that
	conforms to thisprofile SHOULD NOT reject a certificate that does
not
	follow theserules.

Why? The rationale for this requirement is not immediately obvious.