[saag] PKIX - TLS Feature Extension

Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com> Mon, 30 May 2016 10:26 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A8612D1A8 for <saag@ietfa.amsl.com>; Mon, 30 May 2016 03:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 71zbtBSxgwIj for <saag@ietfa.amsl.com>; Mon, 30 May 2016 03:26:58 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B84512B034 for <saag@ietf.org>; Mon, 30 May 2016 03:26:58 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id c189so217208842vkb.1 for <saag@ietf.org>; Mon, 30 May 2016 03:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UmjmoO8LBVR8uTKe1RRm+VqHPevsBUdmhD0ZAzWRpGc=; b=BaUu3fYqkxR2iAf40p57thibKwkeaPNsODOomcmWDjBGievaBOnVP0RG0BLwicDIu8 fnEJvF+ERmjVx3265xNFcEK+DX4a5ZX3tWBiueEz/08nZedL4jWjravF0WEw8hLmXZTU BMTklA5W8xC391ZcxxRbLHTpFbtW+mrMRM3KXMCu4KJ0qhglXm8pcy7VLRvD4lmYXD5A QCrAXY9CS/oxpAzMu/d+gCY0r8sw/56ipl53hG5vosQr5iwZcHf+KaWwMro2pz+/E9we GeNgNABgKb44U/svILHgBVroAX4FJDQeefIMR6lfZFuJFghRsS4kDPVZlmKtlC5RiqG3 aAYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UmjmoO8LBVR8uTKe1RRm+VqHPevsBUdmhD0ZAzWRpGc=; b=VAToheBrDeEh/OBu3PbUp41pvTEbbIQ383s7uu93AlbuZf2IqWpdpc6D5dLTtXEWt1 Lfy6qoL/EdtM3tGp8uZyb/UTI/zHdz3t7ETdhtcQKWnI4W0h9K0ncA2GKd33BZ/EpNwf 50H8DSK/rI9vJ4aWGaWGxgCVvWfcDUIqN5eKKJKt1LtdQWNB5ikiUAHnvNnVE7I4wURi K96EqkkCLZ5kKGiETQWLTLchMxkSPZYNBo3/+gBXF7ugFuSx18Ckl99YZHoI5RwVcu0u bphoBDSAIX0DG5e22eH3HNynejUUzvkuTxUKib/Fet6EKvUckSFokDNHeGgTIZvD6dW0 vL2Q==
X-Gm-Message-State: ALyK8tLaVNEq8O6/WeDtltU/9BhmTJ32XmAa9ISF2SaQJ+z0Y8KuOrDmQdihkO6PQlabZ0tIOcObsnBHmWhFSw==
X-Received: by 10.31.84.2 with SMTP id i2mr14305377vkb.132.1464604017208; Mon, 30 May 2016 03:26:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.72.132 with HTTP; Mon, 30 May 2016 03:26:17 -0700 (PDT)
From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Date: Mon, 30 May 2016 12:26:17 +0200
Message-ID: <CAJU7zaKmCFYWB12mjV4nyR08EF_rb4VPMYht-v+2omz1Xfr0pA@mail.gmail.com>
To: IETF SAAG <saag@ietf.org>, philliph@comodo.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/52aBuwqIP30dIcIVCkDw6v59YN0>
Subject: [saag] PKIX - TLS Feature Extension
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2016 10:26:59 -0000

Hi,
 RFC7633 describes a PKIX certificate extension to indicate mandatory
to be present TLS extensions (called feature extensions in the text).
In particular this draft while generic, is mainly about requiring an
OCSP staple from the connecting server if the certificate mandates it.

However, the rfc text doesn't go into details on how to do that. My
understanding and as far as I've seen in practice certificates will
include a "Feature" extension containing integer 5 which is the OCSP
status request.

If the reading above is correct, how does this scale with
status_request_v2 (which has TLS extension ID 17)? How could the
certificate be used to indicate that the server can provide any of
these TLS extensions? Should both the numbers 5,17 be listed as TLS
features (which can also mean that both TLS extensions must be used),
or having 5 listed is sufficient?

regards,
Nikos