[xmpp] RFC 6120 CA cert keyUsage digitalSignature bit requirement?

Simon Josefsson <simon@josefsson.org> Wed, 13 August 2014 20:55 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25A1A0087 for <xmpp@ietfa.amsl.com>; Wed, 13 Aug 2014 13:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Level:
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4b59pxTYEwP for <xmpp@ietfa.amsl.com>; Wed, 13 Aug 2014 13:55:20 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF83B1A0099 for <xmpp@ietf.org>; Wed, 13 Aug 2014 13:55:19 -0700 (PDT)
Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:f2de:f1ff:fe16:509b]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7DKtEnj000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <xmpp@ietf.org>; Wed, 13 Aug 2014 22:55:15 +0200
X-Hashcash: 1:22:140813:xmpp@ietf.org::nIpL5uq+P8c/gLXQ:2gPm
From: Simon Josefsson <simon@josefsson.org>
To: xmpp@ietf.org
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
Date: Wed, 13 Aug 2014 22:55:13 +0200
Message-ID: <87egwkw1n2.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130011 (Ma Gnus v0.11) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/oNHxm-lf0TJlEuVadSolRoQ3js8
Subject: [xmpp] RFC 6120 CA cert keyUsage digitalSignature bit requirement?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 20:55:22 -0000

Hi,

I'm generating certificates for use in a XMPP environment, and I'm
seeking clarification of one aspect of RFC 6120:

   The following rules apply to certification authority (CA)
   certificates that are used by issuers of XMPP end entity
   certificates:
...
   2.  The certificate MUST contain a keyUsage extension with the
       digitalSignature bit set.

My question: Why is the digitalSignature bit a requirement?

Speculation: Was the keyCertSign bit intended here?  Reading RFC 5280 it
seems the keyCertSign would be more appropriate than digitalSignature.
What non-certificate/CRL objects is it that XMPP environments expect to
be signed by the CA?

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
...
           keyCertSign             (5),
...
      The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.
...
      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.
...
   If the keyUsage extension is present, then the subject public key
   MUST NOT be used to verify signatures on certificates or CRLs unless
   the corresponding keyCertSign or cRLSign bit is set.  If the subject
   public key is only to be used for verifying signatures on
   certificates and/or CRLs, then the digitalSignature and
   nonRepudiation bits SHOULD NOT be set.  However, the digitalSignature
   and/or nonRepudiation bits MAY be set in addition to the keyCertSign
   and/or cRLSign bits if the subject public key is to be used to verify
   signatures on certificates and/or CRLs as well as other objects.

Thanks,
/Simon