Re: [TLS] CertficateRequest extension encoding
David Benjamin <davidben@chromium.org> Sun, 04 September 2016 17:42 UTC
Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6911312B0A1 for <tls@ietfa.amsl.com>; Sun, 4 Sep 2016 10:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 yGFczMNiHmBv for <tls@ietfa.amsl.com>; Sun, 4 Sep 2016 10:41:59 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 7435012B0A0 for <tls@ietf.org>; Sun, 4 Sep 2016 10:41:59 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id i184so116268228itf.1 for <tls@ietf.org>; Sun, 04 Sep 2016 10:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=s5WNUWcyWPLvO/85j82yP5FIAyoLWjsWzFJp2OBdHEc=; b=XK7ol608+S/DQD+faW3OP+F6hgtBP+6OBWBQX+QywEcvrzHDvdtlZgKk7FQD8GlvZp M+INNn/395VJgqUOxI0/pvPOrfsehKVwu+v/HSTnnUL11IzH0KhlTQwL3vEmmLo1nY1A B34TToKDSVvE04+Mm4oC/3nab9ObUr/o9v4sU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=s5WNUWcyWPLvO/85j82yP5FIAyoLWjsWzFJp2OBdHEc=; b=bW29MNhLAEwc2D/7GeKAbrvigA3ZMbHINOhEuFX8Dp5f6gWH9IHm+Lay9fnXfmEiMM AV+xLrXYLg8eXDkOi4azjDsZ17pdnoLdPREo6ooca0q2AOdEY0+b1H1/qsENyoKFh9FY DgAUKhkj0JkUNu4SBFtJPNeQmJ9KtxhJPUhl6sgCKfNE3RlpDhUlH1qDt4S04a3i9vTN vQWFC19eBogLpFx2hFep8RsanKA4nht5RQP+fgon77pKbviAOu6yl3Ii6IxtXHvL2ZAg 0aVHDhjK8pQv3vOElqNU2U9USHIC3nAQmfKdorgKuGpDg7RvogAvYwF7Njap75UcKtT3 gYZw==
X-Gm-Message-State: AE9vXwOzddjwB5ELjTXzpSrIp3DYLSdhtWOjOSE46FeMjTON40Qmz+2GsxhNTkC7C3LMH8S47TSoumou2Fvf3lZP
X-Received: by 10.36.87.212 with SMTP id u203mr17940737ita.7.1473010918612; Sun, 04 Sep 2016 10:41:58 -0700 (PDT)
MIME-Version: 1.0
References: <20160904105637.sjl4wmr2hc2mito6@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160904105637.sjl4wmr2hc2mito6@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin <davidben@chromium.org>
Date: Sun, 04 Sep 2016 17:41:47 +0000
Message-ID: <CAF8qwaApcZBC0K8m27CtYbUd3zb5HvVQbDxpN0kkY0c=Pj4Rcw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1143ad4e8e33b5053bb21484"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YKgCSERWs6UUtdLZVLip2oHwmm8>
Subject: Re: [TLS] CertficateRequest extension encoding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Sep 2016 17:42:01 -0000
I have no involvement in systems that would want this (our implementation just ignores it), but it seems a TLS-style registry would be better than using OIDs anyway. Concretely: A CertificateExtension is a hint to the client about what kind of certificates are acceptable. We have a registry of u16s for them. Clients ignore extensions they don't understand, so it is ultimately on the server to check the certificate is acceptable (as it always is). If we wish to filter on OIDs, we define, e.g., a key_usage value whose contents have some KeyUsage-specific meaning. That would buy us: - More consistency with other TLS fields. - More compact encoding. (At the cost of going getting to define 2^16 rule types, but this seems to have been everywhere else.) - It is easy to look up what a CertificateExtension means and avoid conflicts. I can go to the registry and see that type 43 means "match KeyUsage in this way". For OIDs, it's not obvious whether - Relatedly, we can define multiple kinds of matching rules on the same OID. Suppose we define it one way and we realize we got it wrong. The OID scheme means we're stuck with it. The TLS-style scheme allows us to define key_usage_v2 if needed. - Less confusion about known OIDs with unknown matching rules. The text is a little funny right now. There are plenty of known extension OIDs right now with unknown matching rules. Do we fallback to exact match (which means we can never change this) or should clients ignore those? That enforcing known OIDs is a MUST-level requirement makes this messier. - More flexibility in defining future rule types. Perhaps we want to say some extension is not present. Or some rule is really a combination of two OIDs. Or not an OID at all like "your RSA key must be at least 2048 bits". What do folks think? David On Sun, Sep 4, 2016 at 6:56 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > How are the OIDs and values in CertificateRequest extensions encoded > exactly (I can't make it out from the text)? > > > Does the OID part have the ASN.1 OID TLV tag and length (e.g. > is EKU 0x55 0x1D 0x25 or 0x06 0x03 0x55 0x1D 0x25)? > > > And how is the value encoded? Using the same encoding as > extnValue payload of respective extension in X.509 certifcates? > Or is it OID-specific (and if it is, what exactly goes to it > for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?) > > > (Currently the text just refers to DER encoding, and in a > way that could be read to apply to just to values). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Peter Gutmann
- Re: [TLS] CertficateRequest extension encoding Anders Rundgren
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding Geoffrey Keating
- Re: [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding Nick Sullivan
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Nick Sullivan
- Re: [TLS] CertficateRequest extension encoding Martin Thomson
- Re: [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding Martin Rex