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.
- Another query on draft-ietf-ipsec-pki-req-03.txt Walker, Jesse