Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

Yoav Nir <ynir.ietf@gmail.com> Tue, 12 May 2015 21:11 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C891A901D for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_32=0.6, 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 xtE2qzCbVrLW for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:11:49 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 B79771A8A87 for <tls@ietf.org>; Tue, 12 May 2015 14:11:48 -0700 (PDT)
Received: by wgnd10 with SMTP id d10so21262684wgn.2 for <tls@ietf.org>; Tue, 12 May 2015 14:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O2WqTsAJ5JUxrmJcPW8pOrzswcAZOy1c1a2dyP6qXWw=; b=tXnzOPOrlBwt4EFH6bWhVKPqTOgEJQ3ofBhVdAc6V1krIKcZ32Sev7hs/AMdkE5HKV O7MPMVGajhtC+QGNvKFP5hLpxplAOcLHNe/9ISWqwBYD2kB4xNmNILV3MbT4xdIypI1J ZNMOld0p58pEF9O1WYxf9VdLAcruhN+8CG8iNeg72RUvuvsEVb7ttj87Zff9vJJ7+4AW MifWPy/hwuWmv7vzjwF1pLnW2bdVMs8Vc3ITmxTWag4DF4AoWxAUu4rFmuz8F8Ok6MkM c9ES2hbFrbCO6VZI7BLqHfbJjNLjOky/GgrTwXeb6TTfGnGpQgF10FEiHpTsc86uQMOw FWDw==
X-Received: by 10.180.84.201 with SMTP id b9mr32467268wiz.28.1431465107540; Tue, 12 May 2015 14:11:47 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fa8sm4665590wib.14.2015.05.12.14.11.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 14:11:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20150512205130.CBCF61B2EB@ld9781.wdf.sap.corp>
Date: Wed, 13 May 2015 00:11:44 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <D93C8958-BF9C-447D-916D-ED52D39056B7@gmail.com>
References: <20150512205130.CBCF61B2EB@ld9781.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rxxGwrx5nImA87cd79ADBviC2HM>
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 12 May 2015 21:11:50 -0000

> On May 12, 2015, at 11:51 PM, Martin Rex <mrex@sap.com> wrote:
> 
> Yoav Nir wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> 
>>> 
>>> But a machine/automata/algorithm that will automatically download objects
>>> from URLs from still-untrusted data provided by the peer is definitely
>>> insecure and irresponsible.
>> 
>> In that sense, how is AIA different from revocation checking?
>> Whether you use CRLs or OCSP, you?re following a URL in the
>> (still untrusted or at least possibly revoked) certificate
>> to retrieve an object.
> 
> Possibly revoked?  yes.
> 
> Untrusted? *NO*.  Look at the algorithm in rfc5280 again.

In case a CA mis-issues a certificate, such as when giving someone who is decidedly not Microsoft a certificate for www.microsoft.com, what it should do is to revoke that certificate. That’s the only way to un-emit the certificate other than patch all relying parties. So as long as you haven’t checked revocation, the certificate is not only potentially revoked (someone stole my private key), it’s also potentially mis-issued. 

I think the section you quote below says that. You haven’t done path validation until you’ve checked revocation for every certificate.

> https://tools.ietf.org/html/rfc5280#section-6.1.3
> 
>   6.1.3. Basic Certificate Processing
> 
> 
>   The basic path processing actions to be performed for certificate i
>   (for all i in [1..n]) are listed below.
> 
>      (a)  Verify the basic certificate information.  The certificate
>           MUST satisfy each of the following:
> 
>         (1)  The signature on the certificate can be verified using
>              working_public_key_algorithm, the working_public_key, and
>              the working_public_key_parameters.
> 
>         (2)  The certificate validity period includes the current time.
> 
>         (3)  At the current time, the certificate is not revoked.  This
>              may be determined by obtaining the appropriate CRL
>              (Section 6.3), by status information, or by out-of-band
>              mechanisms.
> 
>         (4)  The certificate issuer name is the working_issuer_name.
> 
> 
> 
> -Martin