Re: [IPsec] #120: CA indication with cert req - allowed types

David Wierbowski <wierbows@us.ibm.com> Fri, 30 October 2009 21:56 UTC

Return-Path: <wierbows@us.ibm.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BDF3A6A20 for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 14:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.854
X-Spam-Level:
X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS9CiUak0rSV for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 14:56:09 -0700 (PDT)
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 68C573A6A13 for <ipsec@ietf.org>; Fri, 30 Oct 2009 14:56:09 -0700 (PDT)
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9ULqoKl029927 for <ipsec@ietf.org>; Fri, 30 Oct 2009 17:52:50 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9ULuH8t1527994 for <ipsec@ietf.org>; Fri, 30 Oct 2009 17:56:19 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UHrnuw021453 for <ipsec@ietf.org>; Fri, 30 Oct 2009 13:53:49 -0400
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UHrnI5021450 for <ipsec@ietf.org>; Fri, 30 Oct 2009 13:53:49 -0400
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com>
X-KeepSent: 9CA175E0:D4783FD4-8525765F:0076DA73; type=4; name=$KeepSent
To: IPsecme WG <ipsec@ietf.org>
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: <OF9CA175E0.D4783FD4-ON8525765F.0076DA73-8525765F.00788169@us.ibm.com>
From: David Wierbowski <wierbows@us.ibm.com>
Date: Fri, 30 Oct 2009 17:56:15 -0400
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/30/2009 17:56:16
MIME-Version: 1.0
Content-type: multipart/alternative; Boundary="0__=0ABBFCCCDFE55CE38f9e8a93df938690918c0ABBFCCCDFE55CE3"
Content-Disposition: inline
Subject: Re: [IPsec] #120: CA indication with cert req - allowed types
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 21:56:10 -0000

> Sec. 3.7 has:


      > The contents of the "Certification Authority" field are defined
      only for X.509 certificates, which are types 4, 10, 12, and 13. >
      Other values SHOULD NOT be used until standards-track specifications
      that specify their use are published.


> This excludes certificate requests of type 7, i.e. for CRLs. For
requesting a specific CRL type 7 would make sense, in particular in > chain
situations. Should we add it to the list of allowed types here?


RFC 4945 states that implementations SHOULD NOT send CERTREQs for types 7
and 8.  If they are sent then an implementation MUST NOT require the
recipient to respond and the recipient MAY ignore the request.  Given that
I don't expect that it is common that implementations send CERTREQs with
type 7 or 8 to begin with.  If they do I agree with Tero that an empty
certificate authority field is probably sufficient.


OTOH, I would not be opposed to adding RFC 4945's "SHOULD NOT send CERTREQs
for type 7 and 8" statement here.


> OTOH, this allows type 10, which is unspecified and should be removed.




Dave Wierbowski


z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055