Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

Eric Rescorla <> Sun, 18 August 2019 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E695912008C for <>; Sun, 18 Aug 2019 06:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zz_q8kM9ZJ9y for <>; Sun, 18 Aug 2019 06:48:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91DFF120024 for <>; Sun, 18 Aug 2019 06:48:17 -0700 (PDT)
Received: by with SMTP id c19so7073371lfm.10 for <>; Sun, 18 Aug 2019 06:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rhsbTLfeXQZmQ2HWPBI+u3RGzRbJgxiBRsOtXRDuXd0=; b=xtE81n/pG+Cq5NKJBsypwJlDN6Ig2sUV+qcfSLYiD+5euse4qIVbeqe9VS6IubT4wX XlJKgp9sqiusz5AWwWoU9xUgvIAjUhedybkMhQ8SCnQx1x39R8VpWIuBsmUGFs2wOJqQ pkZAhoNrcZmAJ+8FDBhd2l5LuoDHc2KThYaDwMYA9Kw+6KyAE5fmTAhJyoSErszL4i6u ivnwMtHhm0lPt+d3tZ8pxUuWMU1Ft8IdkEvzOM0+uf4wOdN0zxDuJjAO7C5M7fTHCybm 37iq3q9cNZ6RoeuNhxoFTLhBnEIqWHbvMzMHZJ0uqqSaYNg7m4WnhZgMRkZc6K25oykY eiJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rhsbTLfeXQZmQ2HWPBI+u3RGzRbJgxiBRsOtXRDuXd0=; b=DxoYLug0H/A+26O2MKfAtWKRiiYCwqZVpP/1cSpHehPrUKnlvsKk9RUqhJLE8/SIKw sGj1T0y/2rH2QpkBF2dFwd/u+IfTDXmSzaik3U+hKvldCPvnDk9wATwO4DeFf2WZphuB YfD/pInEcL9BGk1ySKNy0cR0HVprk2sWOpLiodrvx7bjehtcyMTPjLiYXhovgxZPTFuJ Gpk6haKy0DiqQtRiOfYC2in9PhvCIuXxFomuQeuEmU2F8gJMbAmxWX/tGrSy3HMqanQP 6MC9UFdXFdqRlasjaAWKcwrwSj7XAc5JusFJRfSAyoQYWtNGi3fcbG5cRDy5sxxPl6HU Uu4A==
X-Gm-Message-State: APjAAAVLsKTrsvQZ4gT5GWNRbAcU/91fZnVk/5p3yMkeq/XiCiPFv9tY uBs+7eADKaEWt8qaXlaqIcwhJnwSJWnojMblJwCGNw==
X-Google-Smtp-Source: APXvYqz+LmbO2wMrEhmVo2NdIWB8Tcr7sVhuHVxAc8w6Vv4sOQlfkAE/Qz+YF64Mmov/tYofN2ef29nuGGHVr+Mtrko=
X-Received: by 2002:ac2:51a3:: with SMTP id f3mr9384635lfk.94.1566136095733; Sun, 18 Aug 2019 06:48:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sun, 18 Aug 2019 15:47:39 +0200
Message-ID: <>
To: "Salz, Rich" <>
Cc: Kepeng Li <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000a80cc005906479d3"
Archived-At: <>
Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Aug 2019 13:48:20 -0000

The intent of the "Specification Required" requirement for registration is
that sufficient public information be available to allow an interoperable
implementation. Specifically, the text says:

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.
   This policy is the same as Expert Review, with the additional
   requirement of a formal public specification.  In addition to the
   normal review of such a request, the designated expert will review
   the public specification and evaluate whether it is sufficiently
   stable and permanent, and sufficiently clear and technically sound to
   allow interoperable implementations.

I don't think that a for-pay specification meets that threshold, though I'm
not aware of any IETF-wide policy on that (although I may just have missed

In the absence of that, it would as stated above, be on the Expert to
the standard.


On Sun, Aug 18, 2019 at 2:52 PM Salz, Rich <> wrote:

> Ø  This is one example:
> Thank you.
> That is a bit different since RNC isn’t needed to implement the RFC, and a web search for “relaxng” finds thousands of references.  The SM2, etc., situation is different because you cannot implement the cipher without the definition of it.
> _______________________________________________
> TLS mailing list