Re: [lamps] Request for review of revised RFC 5759

Stephen Farrell <> Tue, 06 March 2018 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A20581204DA for <>; Tue, 6 Mar 2018 13:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FG9eyGY1Yogt for <>; Tue, 6 Mar 2018 13:42:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDC78124B18 for <>; Tue, 6 Mar 2018 13:42:00 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB3FEBE4C; Tue, 6 Mar 2018 21:41:58 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RE5P49RL7mv7; Tue, 6 Mar 2018 21:41:57 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 9460ABDF9; Tue, 6 Mar 2018 21:41:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1520372516; bh=RtIzJ8aAN5vNyrVxclzBCmR5rgPK4ZS9oeYKHYajyJs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=o2G52aVPCSUDoAkHiBgxBlk6vMhbgyOCAbnGvW+CiewzYqMpqOM7t5puYx/1uUk4k TB/8CobjfkfeRA6g21Y7cobxM7ARfDxSWMNiNMHhzp7l/fvf+V+qHhK28kExioirWC yA0JLw57Ui6Gi8cDPR9aI8Rgvm7H3Yb+sWIRf0cI=
To: Michael Jenkins <>,
Cc: "Zieglar, Lydia Q" <>,
References: <>
From: Stephen Farrell <>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <>
Date: Tue, 06 Mar 2018 21:41:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="4k0CBGFjRkPU75251vWYdflBYTvWNfqpI"
Archived-At: <>
Subject: Re: [lamps] Request for review of revised RFC 5759
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Mar 2018 21:42:04 -0000


I commented on making the suite-b profiles historic on the IETF
discuss list. (Probably better to keep that discussion on that
list and not here - thread is at [1], but briefly I suggested we
not do another suite-b-like exercise within the IETF.)

Russ asked me to take a peek at this draft as part of some
offlist discussion about that.

Generally the content of the draft seems reasonable. If it is the
case that the choices in this profile are widely implemented (and
I'm guessing they are), then I would support a profile with such
content being processed as a BCP (and hence coming under IETF change

If there is a real need to retain change control and keep this as
a national profile, then see my opinion on [1], I'm not supportive
of that. (But in this case, as the content seems to not involve
any "innovative" or odd choices, and if done via the ISE, I'm only
very very mildly opposed - almost neutral:-)

I'd encourage the authors to consider if they need an RFC that is
not under IETF change control for this content. I can't see how
that'd be beneficial tbh but maybe I'm missing something. And if
the content had IETF consensus, then I'd guess that'd help in terms
of getting implementations that match the profile more quickly.

If there are other documents to come, that do make "innovative"
choices (e.g. algs or params that are not widely implemented),
then I think even a national profile for that published via the
ISE is a bad idea, (but again, discussion of that via [1] is



On 31/01/18 20:59, Michael Jenkins wrote:
> The US National Security Agency (NSA) has begun the process of updating
> the "Suite B for..." RFCs to define requirements for implementing and
> configuring IETF protocols in compliance with the 2016 revision of
> CNSSP-15 (the Commercial National Security Algorithm, or CNSA, suite).
> These RFCs are intended for use by commercial product vendors who wish
> their products to be used in US National Security Systems, over which
> NSA has oversight.
> As part of this process, the older RFCs will be moved to Historical
> status, and we plan to publish new RFCs via the ISE. We are seeking
> review and comment of the drafts prior to publication, and so will be
> announcing the drafts on appropriate mail-lists as we produce them.
> The first draft updates RFC 5759, and addresses requirements for RFC
> 5280 compliant public-key certificates and CRLs that contain or
> reference algorithms in the CNSA suite. It is available at
> <>.
> We would appreciate any comments you might have regarding the draft,
> either via the mail-list or via direct reply.
> Mike Jenkins <>
> Lydia Zieglar <>
> _______________________________________________
> Spasm mailing list