RFC 5280/6818 - X.509v3 Name Constraints Inconsistency(?)
"Vyron Tsingaras" <vtsingaras@it.auth.gr> Wed, 26 March 2014 20:49 UTC
Return-Path: <vtsingaras@it.auth.gr>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256B1A03C2 for <ietf@ietfa.amsl.com>; Wed, 26 Mar 2014 13:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 EimJvuaLGjgp for <ietf@ietfa.amsl.com>; Wed, 26 Mar 2014 13:49:07 -0700 (PDT)
Received: from hermes7.ccf.auth.gr (hermes7.ccf.auth.gr [155.207.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0C1A03C0 for <ietf@ietf.org>; Wed, 26 Mar 2014 13:49:06 -0700 (PDT)
Received: from myroompc (ppp079167184158.access.hol.gr [79.167.184.158]) (authenticated bits=0) by hermes7.ccf.auth.gr (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id s2QKn36b017541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ietf@ietf.org>; Wed, 26 Mar 2014 22:49:04 +0200
From: Vyron Tsingaras <vtsingaras@it.auth.gr>
To: ietf@ietf.org
Subject: RFC 5280/6818 - X.509v3 Name Constraints Inconsistency(?)
Date: Wed, 26 Mar 2014 22:48:56 +0200
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAPWLtQ2WTBVCrOWZQMmQVdsBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAAbG6Kd+37ASq4FD3cgSwJfAQAAAAA=@it.auth.gr>
X-Mailer: Microsoft Outlook 15.0
MIME-Version: 1.0
Thread-Index: Ac9JNMaQVbdNzmS/SQeeplONKq6XVw==
Content-Language: el
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.3"; boundary="----=_NextPart_000_008A_01CF4945.920388F0"
X-Virus-Scanned: clamav-milter 0.97.8 at hermes7
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/WN4DA9IUY7ftJgSACpARX-QR_W8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 20:51:58 -0000
I am not sure if this is the right place for this but here goes: What is the reasoning behind name constraints format for type "DNS name" as specified in RFC 5280? In other words why is it different from the URI scheme, where ".example.com" would satisfy *.example.com, *.*example.com BUT not example.com? Currently as it stands, a CA has no way to restrict itself from issuing certificates for example.com while allowing itself to issue for host.example.com. A NC for type DNS "example.com" will allow the CA to issue a certificate for example.com when the desired behavior would be to only allow ".example.com"(in URI scheme). This could be undesirable. It seems like while the scheme for URIs and email where updated whereas the DNS scheme was left untouched. Wouldn't it be better if the DNS scheme followed the other 2? The relevant section is 4.2.1.10 in RFC 5280
- RFC 5280/6818 - X.509v3 Name Constraints Inconsis… Vyron Tsingaras
- Re: RFC 5280/6818 - X.509v3 Name Constraints Inco… Russ Housley