Re: [pkix] reminder

Scott Schmit <i.grok@comcast.net> Sat, 04 August 2012 01:16 UTC

Return-Path: <i.grok@comcast.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9A21F8DB4 for <pkix@ietfa.amsl.com>; Fri, 3 Aug 2012 18:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Level:
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+NnrYwWig4j for <pkix@ietfa.amsl.com>; Fri, 3 Aug 2012 18:16:38 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF8521F8BFA for <pkix@ietf.org>; Fri, 3 Aug 2012 18:16:37 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id iRE41j0060EZKEL51RGfiy; Sat, 04 Aug 2012 01:16:39 +0000
Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id iRGn1j00L2Ekl483MRGoKi; Sat, 04 Aug 2012 01:16:49 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q741GYam025628 for <pkix@ietf.org>; Fri, 3 Aug 2012 21:16:34 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q741GYkT025627 for pkix@ietf.org; Fri, 3 Aug 2012 21:16:34 -0400
Date: Fri, 03 Aug 2012 21:16:34 -0400
From: Scott Schmit <i.grok@comcast.net>
To: pkix@ietf.org
Message-ID: <20120804011634.GA25458@odin.ulthar.us>
Mail-Followup-To: pkix@ietf.org
References: <501AB3A3.4020209@bbn.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="dDRMvlgZJXvWKvBx"
Content-Disposition: inline
In-Reply-To: <501AB3A3.4020209@bbn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [pkix] reminder
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Aug 2012 01:16:38 -0000

On Thu, Aug 02, 2012 at 01:06:43PM -0400, Stephen Kent wrote:
> Below is the text that was briefed in the PKIX meeting yesterday and
> that represents the current, proposed text for addition to Section
> 3.2. Russ noted that we need to add a reference to the 2008 version of
> X.509 from which we have cited text.  Peter will reissue the doc with
> this change. I plan to forward that version to the IESG a week after
> it is posted, unless we hear otherwise.
> 
> Steve
> -----
> 
> Add the following paragraph to the end of RFC 5280, Section 3.2:
> 
> Consistent with Section 3.4.61 of X.509 (11/2008) we note that use
> of self-issued certificates and self-signed certificates issued by
> other than CAs are outside the scope of this specification. Thus,
> for example, a web server or client might generate a self-signed
> certificate to identify itself. These certificates, and how a
> relying party uses them to authenticate asserted identities, are
> both outside the scope of RFC 5280.

As I read it, if you aren't a CA and generate a self-signed certificate,
then that certificate isn't a PKIX certificate.  Is that statement
right?

If so, it sort of screws up draft-ietf-dane-protocol:

From section 2.2.1:
#     3 -- Certificate usage 3 is used to specify a certificate, or the
#     public key of such a certificate, that MUST match the end entity
#     certificate given by the server in TLS.  This certificate usage is
#     sometimes referred to as "domain-issued certificate" because it
#     allows for a domain name administrator to issue certificates for a
#     domain without involving a third-party CA.  The target certificate
#     MUST match the TLSA record.  The difference between certificate
#     usage 1 and certificate usage 3 is that certificate usage 1
#     requires that the certificate pass PKIX validation, but PKIX
#     validation is not tested for certificate usage 3.
#
#  The certificate usages defined in this document explicitly only apply
#  to PKIX-formatted certificates in DER encoding [X.690].  If TLS
#  allows other formats later, or if extensions to this RRtype are made
#  that accept other formats for certificates, those certificates will
#  need their own certificate usage values.

(TLSA Certificate usage 3 is intended for self-signed "PKIX"
certificates.)

Maybe the problem is that we talk about PKIX-formatted certificates vs.
PKIX-validated certificates, but both are handled in RFC 5280.

Can we distinguish the two?

-- 
Scott Schmit