From nobody Sun Aug 2 20:53:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C463A07C3 for ; Sun, 2 Aug 2020 20:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b6DVagHMcDtj for ; Sun, 2 Aug 2020 20:53:31 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 8881A3A07BE for ; Sun, 2 Aug 2020 20:53:31 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id j8so24841127ioe.9 for ; Sun, 02 Aug 2020 20:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Uey4K1kDspBLzbYVJuCGdNAnmnDMTap1gszRAQc7Eko=; b=Q24cmsHFrqVcIHETrH0ZrDQdvyyY+74xTd4jL6e/yFMRycQK04SIGuj2yIbJLNuUQ+ wPLRIFPVvcnp4mY6UGMD9BDfKeyKNO/BAYPUgC36uVg9Uc1j4GVjWpMjsUEptdMFFTig pPjP46aAOgp9Alc+qrJHfcE7p1krf9xV3GtDgRAimTgA9dFD+pdjqI4yDbtkh5AlVCof J1T4mogeigAtGVe2c4xj1drh89wWfIpX0GMuO1CnfpMIBJ5WO6iDr0PIOr7DTEWd/+Hg 33jgxHHndVTWg7j2gCjV1t19o/vEqf/Qr1yLuZOFjYAU8hbRvPGJvCwz2R3R+PDVitNL JnXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Uey4K1kDspBLzbYVJuCGdNAnmnDMTap1gszRAQc7Eko=; b=jSyB25c9ydijJKunNe6kUj2vsVYsY5cdgoqkxCBnaU6X5NIdSGMnkVLKZO5n95we3h 5v2+dUeY0zvC2w4Q/Ld7qE7cFdSvSu1tHrK2ExE1dRAac+Djz9YJtg15GBZJgELYW7aX hleDs+yCjn7FZbITSc+rNoxUP8NbAfHq7TwFMnBo9Tu/cPbsEB7nLQOC927o0+afx3BV FeOAL1yM+z/heT0iJ4mK73WeXdNeurVS410nJ1u0cpimijjJ1mELOqw1r5QXWlUE9bbZ DzhaS76kdVfqgW5mZrSjpLNH9AyRmY+2RQJT3ItTBW8uAr8zu3bTjBRBDBqRknXic+gp IqBg== X-Gm-Message-State: AOAM53247oGhVFkqSg2wfofKoktnHh0BqeA5jn4BNwy8wRikBNhReFWb eSLdkAmqsylXO/JDS/NFWWfeFu+pPXOeGgAjIow= X-Google-Smtp-Source: ABdhPJxbD7JIW4gyZ2UiWx9QbPsfCR/H7jYJZCDN5beqbaQ7F9ETFO2k+eyTpb1sxjxu8yWy5npBDRabVufC8FSWE7A= X-Received: by 2002:a02:1d04:: with SMTP id 4mr18537107jaj.16.1596426810511; Sun, 02 Aug 2020 20:53:30 -0700 (PDT) MIME-Version: 1.0 References: <79447b68da0d4cd09757e531caee14d9@cert.org> In-Reply-To: <79447b68da0d4cd09757e531caee14d9@cert.org> From: Mohit Sahni Date: Sun, 2 Aug 2020 20:53:18 -0700 Message-ID: To: Roman Danyliw , LAMPS WG Content-Type: multipart/alternative; boundary="000000000000f3558505abf11410" Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-ocsp-nonce-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 03 Aug 2020 03:53:33 -0000 --000000000000f3558505abf11410 Content-Type: text/plain; charset="UTF-8" Hi Roman Can you please review the snippets of the changes below to see if they resolve your comments? If they look ok, then I will publish the new version of the draft. Thanks, Mohit On Sun, Jul 26, 2020 at 7:00 PM Roman Danyliw wrote: > Hi! > > I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02. Thanks for > the work on this document to harden the nonce extension of RFC 6960. Below > is my feedback: > > ** Section 2. Editorial. s/Following is the list/The following is a list/ > certificates (see [RFC5280]). The following is a list of standard extensions that can be used in the OCSP messages by the OCSP responder and OCSP client. ** Section 2.1. This section appears to be a complete rewrite of the text > in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-ocsp > and id-pkix-ocsp-nonce. To eliminate confusion, I would recommend you add > these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and state that > this new text replaces the entirety of Section 4.4.1. > This section replaces the entirety of the Section 4.4.1 of [RFC6960] which describes the OCSP Nonce extension. . . id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } Nonce ::= OCTET STRING(SIZE(1..32)) > ** Section 2.1. Per "The minimum nonce length of 1 octet is defined to > provide the backward compatibility with clients following [RFC6960]. > However the newer OCSP clients MUST use length of at least 16 octets for > Nonce ...", how would this guidance work in practice from the perspective > of the server? > -- Is this saying that servers shouldn't reject 1 octet nonces for > backward compatibility? > > -- How do I judge if I have a "newer OCSP client" if I have a server? > The minimum nonce length of 1 octet is defined to provide the backward compatibility with older clients following [RFC6960] however, the newer OCSP clients MUST use a length of at least 16 octets for Nonce extension. The OCSP responder MAY choose to ignore Nonce extension for the requests where length of the Nonce extension is less than 16 octets. > > ** Section 3.1. s/a man in the middle (MiTM) entity/an on-path attacker/ > request [RFC5019], an on-path attacker can intercept the OCSP request > ** Section 3.1. Per "This can be mitigated by the server using a closer > nextUpdate value ...", as the units of nextUpdate are time what does > "closer" mean? > This can be mitigated by configuring the server to use a short time interval between thisUpdate and nextUpdate fields in the OCSP response...... > ** When is cryptographically strong PRNG needed? > > -- Section 2.1 seems to be restricting the "cryptographically strong > pseudorandom number generator" to only new clients ("However the newer OCSP > clients MUST use length of at least 16 octets for Nonce extension and the > value of the nonce MUST be generated using a cryptographically strong > pseudorandom number generator") > > -- Section 3.2 seems to be saying something stronger that all client need > strong randomness ("Therefore the client MUST use a nonce value that > contains cryptographically strong randomness"). > Updated section 2.1 and 3.2 to have the same intent. Please see the text below: > > ** Section 3.2. Per "A client SHOULD use 32 octets for nonce length", it > was odd to me to specify a minimum length in Section 2.1, but the > recommended length here. Why not put the guidance in one place? > Section 2.1: The value of the nonce MUST be generated using a cryptographically strong pseudorandom number generator. The OCSP clients SHOULD use a length of 32 octets for the Nonce extension. The minimum nonce length of 1 octet is defined to provide the backward compatibility Section 3.2: If the value of the nonce used by a client in OCSP request is not random enough, then an attacker may prefetch responses with the predicted nonce and can replay them, thus defeating the purpose of using nonce. Therefore the value of Nonce extension in the OCSP request MUST contain cryptographically strong randomness and MUST be freshly generated at the time of creating the OCSP request. Also if the length of the nonce extension is too small e.g. 1 octet then an on-path attacker can prefetch responses with all the possible values of the nonce and replay a matching nonce. > Regards, > Roman > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000f3558505abf11410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman
Can you please=C2=A0review=C2=A0th= e snippets of the changes below to see if they resolve your comments? If th= ey look ok, then I will publish the new version of the draft.
Thanks,
Mohit=C2=A0

On Sun, Jul 26, 2020 at 7:00 PM Ro= man Danyliw <rdd@cert.org> wrote:=
Hi!

I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02.=C2=A0 Thanks fo= r the work on this document to harden the nonce extension of RFC 6960.=C2= =A0 Below is my feedback:

** Section 2.=C2=A0 Editorial.=C2=A0 s/Following is the list/The following = is a list/

=C2=A0 =C2= =A0certificates (see [RFC5280]). The following is a list of standard
=C2= =A0 =C2=A0extensions that can be used in the OCSP messages by the OCSP
<= div>=C2=A0 =C2=A0responder and OCSP client.=C2=A0

** Section 2.1.=C2=A0 This section appears to be a complete rewrite of the = text in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-o= csp and id-pkix-ocsp-nonce.=C2=A0 To eliminate confusion, I would recommend= you add these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and s= tate that this new text replaces the entirety of Section 4.4.1.

=C2=A0 =C2=A0This section replace= s the entirety of the Section 4.4.1 of [RFC6960]
=C2=A0 =C2=A0which= describes the OCSP Nonce extension.
.
.
=C2= =A0 =C2=A0 =C2=A0 id-pkix-ocsp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OBJECT ID= ENTIFIER ::=3D { id-ad-ocsp }
=C2=A0 =C2=A0 =C2=A0 id-pkix-ocsp-nonce = =C2=A0 =C2=A0 OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }

=C2=A0 =C2= =A0 =C2=A0 Nonce ::=3D OCTET STRING(SIZE(1..32))
=C2=A0
=
** Section 2.1.=C2=A0 Per "The minimum nonce length of 1 octet is defi= ned to provide the backward compatibility with clients following [RFC6960].= =C2=A0 However the newer OCSP clients MUST use length of at least 16 octets= for Nonce ...", how would this guidance work in practice from the per= spective of the server?=C2=A0
-- Is this saying that servers shouldn't reject 1 octet nonces for back= ward compatibility?

-- How do I judge if I have a "newer OCSP client" if I have a ser= ver?

The minimum nonce=C2=A0length of 1 octe= t is defined to provide the backward compatibility
=C2=A0 =C2=A0with old= er clients following [RFC6960] however, the newer OCSP
=C2=A0 =C2=A0clie= nts MUST use a length of at least 16 octets for Nonce extension.
=C2=A0 = =C2=A0The OCSP responder MAY choose to ignore Nonce extension for the
=C2=A0 =C2=A0requests where length of the Nonce extension is less than 1= 6 octets.
=C2=A0

** Section 3.1.=C2=A0 s/a man in the middle (MiTM) entity/an on-path attack= er/
=C2=A0
=C2=A0 =C2=A0request [RFC5019], a= n on-path attacker can intercept the OCSP request=C2=A0
=C2=A0
** Section 3.1.=C2=A0 Per "This can be mitigated by the server using a= closer nextUpdate value ...", as the units of nextUpdate are time wha= t does "closer" mean?
=C2=A0 =C2=A0
=C2=A0 =C2=A0This can be mitigated by configuring the server to
=C2=A0= =C2=A0use a short time interval between thisUpdate and nextUpdate fields i= n
=C2=A0 =C2=A0the OCSP response......
=C2=A0
** When is cryptographically strong PRNG needed?

-- Section 2.1 seems to be restricting the "cryptographically strong p= seudorandom number generator" to only new clients ("However the n= ewer OCSP clients MUST use length of at least 16 octets for Nonce extension= and the value of the nonce MUST be generated using a=C2=A0 cryptographical= ly strong pseudorandom number generator")

-- Section 3.2 seems to be saying something stronger that all client need s= trong randomness ("Therefore the client MUST use a nonce value that co= ntains cryptographically strong randomness").=C2=A0
<= div>Updated section 2.1 and 3.2 to have the same intent. Please see the tex= t below:=C2=A0

** Section 3.2.=C2=A0 Per "A client SHOULD use 32 octets for nonce len= gth", it was odd to me to specify a minimum length in Section 2.1, but= the recommended length here.=C2=A0 Why not put the guidance in one place?<= br>

Section 2.1:
=C2=A0 =C2=A0The valu= e of the nonce MUST be generated using a cryptographically
=C2=A0 =C2=A0= strong pseudorandom number generator. The OCSP clients SHOULD use a
=C2= =A0 =C2=A0length of 32 octets for the Nonce extension. The minimum nonce
=C2=A0 =C2=A0length of 1 octet is defined to provide the backward com= patibility

Section 3.2:
=C2=A0 =C2=A0If the val= ue of the nonce used by a client in OCSP request is not
=C2=A0 =C2=A0ran= dom enough, then an attacker may prefetch responses with the
=C2=A0 =C2= =A0predicted nonce and can replay them, thus defeating the purpose of
= =C2=A0 =C2=A0using nonce. Therefore the value of Nonce extension in the OCS= P
=C2=A0 =C2=A0request MUST contain cryptographically strong randomness = and MUST be
=C2=A0 =C2=A0freshly generated at the time of creating the O= CSP request. Also
=C2=A0 =C2=A0if the length of the nonce extension is t= oo small e.g. 1 octet then
=C2=A0 =C2=A0an on-path attacker can prefetch= responses with all the possible
=C2=A0 =C2=A0values of the nonce and re= play a matching nonce.
=C2=A0
Regards,
Roman

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000f3558505abf11410-- From nobody Tue Aug 4 16:35:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9793A115D; Tue, 4 Aug 2020 16:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TIP7AIR7SOWA; Tue, 4 Aug 2020 16:35:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AD73A11E0; Tue, 4 Aug 2020 16:34:51 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074NYck1001425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 19:34:40 -0400 Date: Tue, 4 Aug 2020 16:34:37 -0700 From: Benjamin Kaduk To: RFC Errata System Cc: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, daniel.migault@ericsson.com, rsalz@akamai.com, David.von.Oheimb@siemens.com, curdle@ietf.org, spasm@ietf.org Message-ID: <20200804233437.GX92412@kduck.mit.edu> References: <20200712154032.8DD22F40745@rfc-editor.org> <20200804231921.GW92412@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200804231921.GW92412@kduck.mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC8410 (6229) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 04 Aug 2020 23:35:36 -0000 On Tue, Aug 04, 2020 at 04:19:26PM -0700, Benjamin Kaduk wrote: > Adding LAMPS. This time for sure. -Ben > My confidence level here is not terribly high, since there is no > certificate presented with the public key whose private key signed the > X25519 certificate in question and there is some possibility of a different > edge case that allows this behavior. > > That said, it seems like the smallest possible change would be to just > remove the word "PKIX" from the description of the certificate in question. > > -Ben > > On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC8410, > > "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6229 > > > > -------------------------------------- > > Type: Technical > > Reported by: David von Oheimb > > > > Section: 10.2 > > > > Original Text > > > An example of a self-issued PKIX certificate using Ed25519 to sign an > > X25519 public key would be > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing). > > It includes a subjectKeyIdentifier but not an authorityKeyIdentifier. > > > > For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present. > > > > Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate. > > Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition). > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8410 (draft-ietf-curdle-pkix-10) > > -------------------------------------- > > Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure > > Publication Date : August 2018 > > Author(s) : S. Josefsson, J. Schaad > > Category : PROPOSED STANDARD > > Source : CURves, Deprecating and a Little more Encryption > > Area : Security > > Stream : IETF > > Verifying Party : IESG From nobody Wed Aug 5 10:07:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D65B3A0DC6 for ; Wed, 5 Aug 2020 10:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 q9ogYcu-ARSV for ; Wed, 5 Aug 2020 10:07:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DCE3A0DFB for ; Wed, 5 Aug 2020 10:06:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8ADC4300B6E for ; Wed, 5 Aug 2020 12:58:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9X-PsGfqRvmE for ; Wed, 5 Aug 2020 12:58:26 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5EAA2300B5B for ; Wed, 5 Aug 2020 12:58:26 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_4AC6C028-09A8-48BC-9750-11D79D86A712" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <022285FC-2E1A-4353-BD42-EC1A3EA3F232@vigilsec.com> References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> To: LAMPS WG Date: Wed, 5 Aug 2020 12:58:27 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] IETF 108 meeting survey X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 05 Aug 2020 17:07:02 -0000 --Apple-Mail=_4AC6C028-09A8-48BC-9750-11D79D86A712 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please fill out the survey if you participated in IETF 108. > From: IETF Executive Director > > Subject: [108all] Final reminder: IETF 108 meeting survey > Date: August 5, 2020 at 6:30:16 AM EDT > To: 108all@ietf.org >=20 > Thank you very much to the ~230 people who have filled in the IETF 108 = meeting survey as this data is crucial to helping us plan future = meetings. We could still use another 70 or so responses and so this is = a final reminder to please help us by taking a few minutes to complete = the survey: >=20 > https://www.surveymonkey.com/r/T3SL7JF = >=20 > Thanks in advance >=20 > --=20 > Jay Daley > IETF Executive Director > exec-director@ietf.org --Apple-Mail=_4AC6C028-09A8-48BC-9750-11D79D86A712 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Please fill out the = survey if you participated in IETF 108.


From: IETF Executive Director <exec-director@ietf.org>
Subject: = [108all] Final = reminder: IETF 108 meeting survey
Date: = August 5, 2020 at 6:30:16 AM = EDT
To: = 108all@ietf.org

Thank you very much to the ~230 people who have filled in the = IETF 108 meeting survey as this data is crucial to helping us plan = future meetings.  We could still use another 70 or so responses and = so this is a final reminder to please help us by taking a few minutes to = complete the survey:

https://www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--
Jay Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_4AC6C028-09A8-48BC-9750-11D79D86A712-- From nobody Thu Aug 6 04:39:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9D3A1135 for ; Thu, 6 Aug 2020 04:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 CFiSRom6oUic for ; Thu, 6 Aug 2020 04:39:32 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00059.outbound.protection.outlook.com [40.107.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82823A1134 for ; Thu, 6 Aug 2020 04:39:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DI+CNowdehgoOMtkVDV4erMrFfvxwMJ+PrMWRZS6Zv+Ml0RwPMiFo90T5M4KpIswC+VykSQKfb9+d6YFI8AWadOOpXclkuHQv69vQVaRxc1GgxuUwwwQmWbQxvsvz9j5C5X9v0fO2hyJ35iGDR7boZfxk/LPpk1JFGFcqSoZPf3A7BeC72VlBDSRKzXRGXzpPqCGPQFIq3F+d/Nq6o8lhqKxgQkOjMFLNwrPdBMN3PorW+ixYLgFH5Xwd+VJORGLPEGKCG37RDWsEO6GaEKC+sfQv9khftTxBJr6nvwaIxdFpMe4/AYPUB2bgPxq9tWk1B634cYjiHl3TZ377uVHdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WpKZPMmIf8bieaS1omtFb2MICDpgUYrncMLO+ITzwzU=; b=RlRpouUnT6gyL0hM+JGi3QPWd4HCv2cjmGB34zJ2rqoO12D/tWdzjVr7RwzCb4v3yawvGBV6LeAo4QcZt6NjAkQClSerfTB8EO8ghdkrD/lB48FPNJB1ySyiyuqpAWoUBuEk93hwASooy5ggT1801L5joe2qaDjTwZjcASJawqGWY1AYONQny/mz+BQgK24a6Q/w9rpyq9X7AIPaF7EBgXEMApuS7lelC6ix1zD+asB1zAPifBXWVbp54MH7v2fcdn+31T0BcNmQOyXv+dgKeSf84SnDSZvJ2V89VfxN0CDwQrfF7Djf3o51kUmLuasqFx++FZ/EoJ9O/PGPbsgDww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WpKZPMmIf8bieaS1omtFb2MICDpgUYrncMLO+ITzwzU=; b=gM4mfW5PmFuE089u2te9Dy6dWxi4oRVhPZOqzhdSmSoFXD8oWi3XAJBShYZVRcUTIWwvhLsxyXJRhDZ4uN0sUKyS20dg9CElpmipVoyJvpGidfJ1CYFFoPY+3l+yxSOZyNmebChmtbFnWNmLngUp302e9Sr+sitOPsCoOD04jmg= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4088.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1cc::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Thu, 6 Aug 2020 11:39:29 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6%5]) with mapi id 15.20.3261.019; Thu, 6 Aug 2020 11:39:29 +0000 From: "Brockhaus, Hendrik" To: LAMPS WG , Russ Housley , Jim Schaad Thread-Topic: draft-ietf-lamps-cmp-updates, Appendix A Thread-Index: AdZr5iEevKc/wYq4S4Cd2P2GaVFUCQ== Content-Class: Date: Thu, 6 Aug 2020 11:39:29 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-06T11:39:28Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=17da1dfa-842f-4a54-ad14-efaa3093e6df; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.150] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d2e6c226-5127-4cc7-a332-08d839fd6155 x-ms-traffictypediagnostic: AM9PR10MB4088: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SSEYsN873D/1Gw6Kia88fCjw3g95/ycr+MpCURRRpibwtj0AiE36q5DK2kJinBH5BzFGqAPf91+sFxtWa9VgVseVXngkMyuqlkGmvLEd65HMdSJb4NuLnirJOpHIc1PGKXOFOC0zOreAQJwZUp0lQo9RdFAvX6TOubj+BOrM8WbNMxWz2dh4V3SbXzbQHnNVROWe3U1WIasDMdZZxkddJpZ5vekKpMWOg/HxBjHJ7nEq6Rg6d+g/X7ktne7O77dlhHqDJLbrBTwzvpnFp1SslxR9E4K3HD2ULvi3/L2a4wUMEVIPj03YOxoi84oSssjpy9rOBtcHgDPWtDsMmJcFyQa/5xy/Kya2CCg3tljel5x2ftndVWgOptGenAXbZW5omnlDJVUoE07f8l1Q0haxAA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(396003)(346002)(136003)(52536014)(26005)(186003)(2906002)(15650500001)(33656002)(55016002)(83380400001)(66556008)(64756008)(66446008)(6506007)(86362001)(66946007)(9686003)(66476007)(5660300002)(76116006)(7696005)(15974865002)(8936002)(478600001)(71200400001)(110136005)(8676002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0iRg39pqYco3ZXYkWGK/48fbTRtC4TM2IrrOCc/1M3lPydQRAQ9H3gAiF5m5iiYQBKc7voGcmFuvWlvjEQoKV5iHmOulPwhEpK0SzrDc5KkDa845FwdgKz8o3sfPGu9cGqoSwRa9IVf64QqyEeFL+unYnSxffPWhgcpb9JRL4HBYkYccMHffkQfU8oadC7RRCE7D96CT02JXrKMUSV12lchNr75hJ2Sgof/sDz2DptCCVuo72vn7puFq1gW1SU1tivco53vVG8fJ6lS0YI8KiFTO7O9AZUXg6lgnht/I3bdDzVbfJ8x5b7kcTdpCbFZqmwz83mQtrxHm/co/auK5pRd9pHLoD4SsSm0KdaERyGvYubhPFXftt8FUyvqpUTFInRb48a+Q+AgqQHko56uW4JU/fQfRIAeB64fr47eBAP+9dSEPHoSg3x5WFYFll/0scH+NMmvQa9Sj8iDlk7qepvSOm6uN8OcwKCLZAnYJFXSQ5UeN4uFaovz98LCfF2nRXl7/z7JDzP0dhsw/wim23Fak5Itcpil8N6wOyiVGreua/NIre+TakK0RU2XrH1OSSC7gx3unxwqUTLah/yYAmyu0ifxiWNw59DrQfyu/wV8Xr5Y4kaIihl+bgmfPEPGohFJVFxH/U4RBa9JKfW4vcA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d2e6c226-5127-4cc7-a332-08d839fd6155 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 11:39:29.4557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: idEuQnC/23V25aHNVbHOzZyDE5dpk9XXsz2WY3SS12akeCf29ppghVsXIRYcsc1K7Wegyx9siV6PV0CC1dahL3yuJV81Nfr3S1TJj/OzpfQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4088 Archived-At: Subject: [lamps] draft-ietf-lamps-cmp-updates, Appendix A X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 06 Aug 2020 11:39:33 -0000 I am preparing an update of the CMP Updates draft and have a question regar= ding the ASN.1 module to put into the appendix. RFC 4210 has the normative CMP ASN.1 module in 1988 syntax. RFC 5912 Section 9 provides an update of the CMP ASN.1 module in 2002 synta= x. In RFC 6402 CMC Updates Jim added the updated normative CMC ASN.1 module in= 1988 syntax and added another ASN.1 module in 2008 syntax. 2015 another update of ASN.1 was published by ITU-T. For CMP Updates I plan to add an updated normative CMP ASN.1 module in 1988= syntax as Appendix A.1. Like in RFC 4602, I would also add another ASN.1 module in a more current A= SN.1 syntax as Appendix A.2. Which ASN.1 syntax version should I use for this additional Appendix A.2? 1) 2002 like the CMP module in RFC 5912? 2) 2008 like Jim updated the CMC module to in RFC 6402? 3) 2015 which is the most recent ASN.1 syntax version? Any guidance is welcome! Hendrik With best regards, Hendrik Brockhaus Siemens AG Corporate Technology Research in Digitalization and Automation Security Architecture CT RDA CST SEA-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany=20 Tel.: +49 89 780522411 Mobile: +49 174 1517765 mailto:hendrik.brockhaus@siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann= Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive= Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Regis= tered offices: Berlin and Munich, Germany; Commercial registries: Berlin Ch= arlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 From nobody Thu Aug 6 07:18:49 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8DE3A0826 for ; Thu, 6 Aug 2020 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com 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 bgfK7eq0COFA for ; Thu, 6 Aug 2020 07:18:41 -0700 (PDT) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6593A07F6 for ; Thu, 6 Aug 2020 07:18:41 -0700 (PDT) IronPort-SDR: AZZzvfwxyJ5tBD8zeUlYxizLIn2LHhx0trnicJCvy2v5L43PIw1hhIurJhORREdgHXlQbcUHOg uQQJZwBuKLYw== X-IronPort-AV: E=Sophos;i="5.75,441,1589259600"; d="scan'208";a="18140022" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 06 Aug 2020 09:18:40 -0500 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Aug 2020 09:18:37 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 6 Aug 2020 09:18:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mpEZa4ukcT5BbSBeHbBaFRlcZZF/CZncsJ1/JnkrX5cb7QC7fWYLK+/cJd2iZUBWS2q8tlGYHi9akVGdWamWhphJIBBZp2mDp8MwlyCo0F1lw0ZNCEZV1oXGRtiBCqxFTiISjwf/U2e76kmS/13zH7PDnBMnGyAgFy9VH3jR53ne3StL/j45O0Tn32/A+Jj7WuKlg1BPcwh9FAZhcE8fMmIm1RWvxvzdlyyeZ3aLnH/DJKLcER3vRmDIHhruFCyt85Pj/2E8L5n8P0d7jxHcvQ4ckF2HwvzMycl0lTVjddoiwkOSfkoiAPxt1ll3+Xk86HAE7lBo6kvCW/p/v887dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pb5UkZ/YdloxnWFFcdIs5yyVzhvSopclu1+hLds2G/c=; b=cs8uw0y3KrhtDutTknatA2EcKYrAELmTAtBMCOlA033zYm3kf4YeqfO5dTuHtYVdH2baQywRmONBajolTZ7LHb1Kxy5f/ESw6WaGtPefzZrNvtPpMKh2DUq5OoQAP8xgyJhtYZE2glUdQSgGRWCqSUF9rTEkiov2fmmW88gbYVL+eH6ppMNnfYSr1nwFTYWRS43rQITNbOsIo8c+oh2wA5GOyXZgMEeRDKRj50hGDuTLarJDSyRceyk+KUOx+g4ShGO/Hejb9FGnvSaqrm28F9QnUDLaSVMaSuhy4CtWaptJVg+o+lZ54rmdoz0eJfV5YaDbXfKdL9nlQ9/1OeVsLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pb5UkZ/YdloxnWFFcdIs5yyVzhvSopclu1+hLds2G/c=; b=xxkvFcEgyJBuXRKZxkRt9zck28f7PT/OSsFruCVn9tDRGMnUcCRpFu7OBUesm9FgqGVrUPu+M00IYUzDFcyYMc7O7svoED3qBEY9nAtLgU7pOZ/ig6EGIqpeFXP+j9Dw5m6T2YevDnxNJQHMx5BZx49Fyxxc7Gb6JNs4bpHIVR8= Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB2666.namprd11.prod.outlook.com (2603:10b6:5:c9::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Thu, 6 Aug 2020 14:18:34 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::9590:3f7f:d793:5b49]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::9590:3f7f:d793:5b49%5]) with mapi id 15.20.3261.017; Thu, 6 Aug 2020 14:18:34 +0000 From: Mike Ounsworth To: "Brockhaus, Hendrik" , LAMPS WG , Russ Housley , Jim Schaad Thread-Topic: draft-ietf-lamps-cmp-updates, Appendix A Thread-Index: AdZr5iEevKc/wYq4S4Cd2P2GaVFUCQAEsNuw Date: Thu, 6 Aug 2020 14:18:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-06T11:39:28Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=17da1dfa-842f-4a54-ad14-efaa3093e6df; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=entrustdatacard.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78a7e378-4d35-4c3c-b4c0-08d83a139ab7 x-ms-traffictypediagnostic: DM6PR11MB2666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PEVURvoTD1YzfDFrICX9v0JSk4IH9DpF9JdoHYz7t0+DFtsNhcLfFsnSrrJpinPKTmkpgiFlKayBanyflT4HVGq16lkWfG3JX0LFh84pxOff73CfF3fYILZysmd6Cx2VUxyLH8jcmZGIeZUG/EXNNIu2buanK+KG0wOq0AejtCpNPbrJ48eIFurpqjyI6XU1BDYmUrgFlrDyjwG13CyYDUd3ycaO+8Pm/5q3W4XNitbWGuCEVlZbxDYtkywswORkHDHs3t5Xra9JTdRHtUh0JgooqztwX/6cE4vrjJbJajS3YnoXVeGhj4RvWtlgvkgbbWedYwRY6+/GoVJWQMdsjgFPhK67I7e6hftZ2cqSmhCjt6QfFhFcQHxJqBa4llYSHMztrnVGITYrCaCZsROV2w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(346002)(396003)(39850400004)(136003)(376002)(9686003)(186003)(6506007)(53546011)(76116006)(478600001)(26005)(8936002)(15650500001)(5660300002)(66946007)(66476007)(52536014)(66556008)(66446008)(64756008)(2906002)(55016002)(86362001)(71200400001)(966005)(83380400001)(316002)(15974865002)(33656002)(7696005)(110136005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: wZ9oYX5WdUAPUm/nMxS/lSghbwtTTrhLPtmYavHvOWwFfvrZmW3dpz6nAMAqmFdU8sf0TXq8lWu4GCTS2tMrZ+e/rectb7ccbDD0wAlePvhCML6nzd7nZFVx3hVwRYjpft2QFTRf/P+kMiL2dUWdQ5XYolCOQfqHqwrpK/n+Fqd+SoeoYTnhPBuRN5cvJAPDlnJ5Dm15c4e5+uoW1semlOxSep/nZTm/DmBS6+bmhivitaj071vX2gy43H06tDaRke1py7eClfjyLru50DcPijxgbkl0r5t/E/pVjnscsjMt9steWL2aUMgpWkeRTWb4RZth+Qtdx7oX4c0DnNav60XXO9r6RijNAmyvIb3AbwbvH0kcL77vISBjsppX+0jY5w/ol3eFXNaf1hjKNaZCDqKG2OisQQlSYgb3rcm4nucNQdyx8/sWsPwDimztrD4Mf7034Jl5IsxTkVQjtl+nVbyTF7DXHXTgDO04rBXL2wdWgG3yBrFF4S1Aftc10BcI5MIeUlaN+ME1wO1aGcyRYakbo/DPlD0/TvhkIv30KflUyXRB27HgHkBvqky0JUHWJTN9LbwPf0fCWF/XniJtesPceveyt2WLwVV2Z4342a4L9bbAN26bZp1RIgO/56fg5EH0tCLq4A9TTdxcp4cF9A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78a7e378-4d35-4c3c-b4c0-08d83a139ab7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 14:18:34.6186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dcFbA3EOR/cjy976h+iQUboPfow+T+72eD8UirMvSbQZAB1ChLM6mdRgnLC+WD2A1ybHyyXWoBLr90UHEkI1Mf38sj6u9sq1sJHg/Ggtm6Bnz2iyfLeOsIqaGE3qXn17 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2666 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates, Appendix A X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 06 Aug 2020 14:18:45 -0000 Not sure if it's helpful, but RFC 6025 (2010) provides guidance ASN.1 on co= nverting from the 1988 syntax to the 2002 syntax. =20 --- Mike Ounsworth | Office: +1 (613) 270-2873 -----Original Message----- From: Spasm On Behalf Of Brockhaus, Hendrik Sent: August 6, 2020 6:39 AM To: LAMPS WG ; Russ Housley ; Jim Sch= aad Subject: [EXTERNAL][lamps] draft-ietf-lamps-cmp-updates, Appendix A WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. I am preparing an update of the CMP Updates draft and have a question regar= ding the ASN.1 module to put into the appendix. RFC 4210 has the normative CMP ASN.1 module in 1988 syntax. RFC 5912 Section 9 provides an update of the CMP ASN.1 module in 2002 synta= x. In RFC 6402 CMC Updates Jim added the updated normative CMC ASN.1 module in= 1988 syntax and added another ASN.1 module in 2008 syntax. 2015 another update of ASN.1 was published by ITU-T. For CMP Updates I plan to add an updated normative CMP ASN.1 module in 1988= syntax as Appendix A.1. Like in RFC 4602, I would also add another ASN.1 module in a more current A= SN.1 syntax as Appendix A.2. Which ASN.1 syntax version should I use for this additional Appendix A.2? 1) 2002 like the CMP module in RFC 5912? 2) 2008 like Jim updated the CMC module to in RFC 6402? 3) 2015 which is the most recent ASN.1 syntax version? Any guidance is welcome! Hendrik With best regards, Hendrik Brockhaus Siemens AG Corporate Technology Research in Digitalization and Automation Security Architecture CT RDA CST = SEA-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 780522411 Mobile: +49 174 1517765 mailto:hendrik.brockhaus@siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann= Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive= Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Regis= tered offices: Berlin and Munich, Germany; Commercial registries: Berlin Ch= arlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 6 07:35:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1B43A07CE for ; Thu, 6 Aug 2020 07:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2pfFBdVBj4KX for ; Thu, 6 Aug 2020 07:35:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93003A07CC for ; Thu, 6 Aug 2020 07:35:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 32665300B86 for ; Thu, 6 Aug 2020 10:35:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rm7IszJQ6_XA for ; Thu, 6 Aug 2020 10:35:31 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 55FD5300ABD; Thu, 6 Aug 2020 10:35:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Thu, 6 Aug 2020 10:35:31 -0400 Cc: LAMPS WG , Jim Schaad Content-Transfer-Encoding: quoted-printable Message-Id: <8AEBD494-1D3D-45CB-88C1-C251741EE3B3@vigilsec.com> References: To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates, Appendix A X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 06 Aug 2020 14:35:37 -0000 Jim already converted to the new ASN.1 syntax in RFC 5912/RFC 6402. I = suggest you use that module, and make the minor additions that are = needed. Russ > On Aug 6, 2020, at 7:39 AM, Brockhaus, Hendrik = wrote: >=20 > I am preparing an update of the CMP Updates draft and have a question = regarding the ASN.1 module to put into the appendix. >=20 > RFC 4210 has the normative CMP ASN.1 module in 1988 syntax. > RFC 5912 Section 9 provides an update of the CMP ASN.1 module in 2002 = syntax. > In RFC 6402 CMC Updates Jim added the updated normative CMC ASN.1 = module in 1988 syntax and added another ASN.1 module in 2008 syntax. > 2015 another update of ASN.1 was published by ITU-T. >=20 > For CMP Updates I plan to add an updated normative CMP ASN.1 module in = 1988 syntax as Appendix A.1. > Like in RFC 4602, I would also add another ASN.1 module in a more = current ASN.1 syntax as Appendix A.2. > Which ASN.1 syntax version should I use for this additional Appendix = A.2? > 1) 2002 like the CMP module in RFC 5912? > 2) 2008 like Jim updated the CMC module to in RFC 6402? > 3) 2015 which is the most recent ASN.1 syntax version? >=20 > Any guidance is welcome! >=20 > Hendrik >=20 > With best regards, > Hendrik Brockhaus >=20 > Siemens AG > Corporate Technology > Research in Digitalization and Automation > Security Architecture > CT RDA CST SEA-DE > Otto-Hahn-Ring 6 > 81739 Muenchen, Germany=20 > Tel.: +49 89 780522411 > Mobile: +49 174 1517765 > mailto:hendrik.brockhaus@siemens.com > www.siemens.com/ingenuityforlife >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim = Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and = Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, = Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; = Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB = 6684; WEEE-Reg.-No. DE 23691322 >=20 From nobody Thu Aug 6 07:56:44 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C373A080E for ; Thu, 6 Aug 2020 07:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 HQMO8ZPW7pwe for ; Thu, 6 Aug 2020 07:56:41 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5685B3A0805 for ; Thu, 6 Aug 2020 07:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TYMTiC1DFI+s1uFw3ZnkBfR/zdiQs8MZXXEbmkC+t88JjgS+NaTFWzvzUS/MAEmawIG76xcRgPG486GLGD7M6IHgM/7VR5wOvXniR/ZcncQJmQ5Uwpksf+XtzVoGKjhGgZ2XkhwR+SC49buhag3Y+YCrrJDB9tnUnPls2blFo6FlNIAN3PIF9aeik7+o3Pr/YwUyHPm2cEVQK6nUDxaKH6Orx9j+vzN3bgbOIVTquEzPeUW5qR3FJyzPf6X4V4K1SVL63LlyUJPynl81qwoAlR87a1g88F2gACS3Y5FVN22SRcDy9sTC02OT+K5D8t9bkxydaqbj88A6AT64Hg3vxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xK+jbqUySUqUhDC3r9bTlg0vRphfHQq5xnT4TLq8G3c=; b=OeXO7LLegUJKh8D36QWw1NZ7+MejAHEg0gjVyJDT/Sf9a1X7lK0vIBV8JnYeFT4x3cIEEewLaBtCTWz11t7PMbgS5QOOCCQVe7cR102vjf9ESpX8qWFJeanahV5/5BMTVnCmMmQHoEoPdNebN4Rab2Jifc01Tg9YtnaEN7JcuDcTUFzCCxK3wMQK7Rzpo3/fME8Cpm65trgvLK+oyJtpHECAapnpg5urVEccqG1L8w8gQu/TtU31AwwRmzV2xzQzoDk61ymfdI2SIl7CxR3K+0F9PTqdjPllpuEyq2w5T7/C4lIYdzN5zvgm736aFo2JOhmfI3NbzedYZC6/JS/wvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xK+jbqUySUqUhDC3r9bTlg0vRphfHQq5xnT4TLq8G3c=; b=PWNnwGiynK9cAwUa+YvO6M2NUlj8XRvmupBV1QQe+UORVWF8w5vVKXuDOlrcqRaQB93c4c5NOi8S4pbs+4aIcKOk3U48zNiL9LDjtswwPBqDzHgnA0VEEUiC9jAfdtr4RY017SFwdE+Dveo7r9I93zUt9GpTbkx9reG7bV7hlAM= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4277.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fb::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Thu, 6 Aug 2020 14:56:38 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6%5]) with mapi id 15.20.3261.019; Thu, 6 Aug 2020 14:56:38 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG , Jim Schaad Thread-Topic: draft-ietf-lamps-cmp-updates, Appendix A Thread-Index: AdZr5iEevKc/wYq4S4Cd2P2GaVFUCQAGLTeAAABjN8A= Content-Class: Date: Thu, 6 Aug 2020 14:56:38 +0000 Message-ID: References: <8AEBD494-1D3D-45CB-88C1-C251741EE3B3@vigilsec.com> In-Reply-To: <8AEBD494-1D3D-45CB-88C1-C251741EE3B3@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-06T14:56:37Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=6c424871-2711-4032-8fd7-f1c202c387d3; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.150] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2ab86acc-d87d-4682-df02-08d83a18ebfd x-ms-traffictypediagnostic: AM9PR10MB4277: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KpoGW1CbXdvIsYm6gH43AnpYc0NAREjV6OT0HGxNsom8dfGGctguGR7dioVADxKtZO93vTXmHI42zsixsYNgBROH+aWkuOYT7lkiIsHQBYqLQHmmaikOb/FtA50NSqkRCgySnJNQLR8/YbqZYVQ3uQNLRlDbjtKjvRxIHwr7UYo9xR+qQsGlmnh/2FTjRlSi2sD14+XlaUbX/JW50sF7irwRFVJuoOvqTYxoAE2YmJyVLwa/azRRXxV6I6kbWUC31zS6+RUDmNbWFxDRTorVg1/BPa9BfPmD/1rhORu5DOo4PFdbwJGIBtFXe00f7Osrcuo8jD3HEIip5tWaYKGhSHlaY+ac+/oBwkCCfh1abK7GjQix3UT6MKRLbjfjwbkBIT7G4Y7tgrwpyMJ68kj1ZA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(39860400002)(376002)(346002)(136003)(66556008)(33656002)(55016002)(76116006)(6916009)(4326008)(9686003)(66446008)(66946007)(52536014)(5660300002)(64756008)(66476007)(8676002)(6506007)(83380400001)(71200400001)(86362001)(7696005)(8936002)(2906002)(186003)(478600001)(316002)(26005)(966005)(54906003)(15650500001)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qnQWmS/qqxQvuNjOIs1lzILWiJTqoaZ8rvswn6tk4O5Og3PyS8GvWE1Tr56KxGl93sa+GFycgVDMJLgCvblY7eJQe/qLJz+rexjRQgjannf/YlyBjDgeOYkb/4us14wfHvKd4ulZpNulWohDZhtk+eO77NtR+I2Y7Ts9J1aY75ui+YipnvBWdg1Ec9Oo1xgEluLRnsZJPbiDmRv2luiUpplE/Gjda9wRipMKKeVJkClqlDOesLVkQfikj0LBQ30kpdPzNYHXpTLOGpKzPf1xnslLyVetXKmvn7hiqKqRGjiOueCwEwSk0t7OrR/Nj1cSwofZU5LkGERh8YzQbfx4NweB3Wh/aWX0L9jYdMkauCCiibwot480wjhniZ+jEJlemv9/PBFHO1idyLncGBVUlZ9WtwW6x1+Pbu7Tl7il/daC4VemHDJe/+kV46ovDFt6sqnlZehXQugWmfemUymYfFXHMQNyVi9q3+ELs/jKGE+lKIivT0b77GPnOnDYPyeVamt/fBYPLHmsw4CZDOz5HF5t2tzPIiFlpa4otAvF52EM8EFJLmcCfN4Muz1WwjQhuR3owT4Q36Qr298hvJPzXqClsqxddWNI+6vcceVY/I2nFSsK5O1c+wQqVS8kLmH6RsYSa3qobtZx3U0pfUECxQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab86acc-d87d-4682-df02-08d83a18ebfd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 14:56:38.4965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JNP7MBwkpHg7tXVdANR1zPncPuNa+uE0MWXNjpCYYJRqcNnG3KFrQVnxQm/+qrO5I4Nlh52ac/CdMh39fUA5+Qc1Rdx0AzA4edKicW+KkN0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4277 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates, Appendix A X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 06 Aug 2020 14:56:43 -0000 > Von: Russ Housley >=20 > Jim already converted to the new ASN.1 syntax in RFC 5912/RFC 6402. I > suggest you use that module, and make the minor additions that are needed= . RFC 5912 contains the 2002 CMP ASN.1 Module. I will put that into Appendix = A.2 and update it. RFC 6402 contains only a 2008 CMC ASN.1 module, NOT a CMP module. I case the group changes its mind, I can update Appendix A.2 to a more rece= nt ASN.1 syntax. Hendrik >=20 > Russ >=20 >=20 > > On Aug 6, 2020, at 7:39 AM, Brockhaus, Hendrik > wrote: > > > > I am preparing an update of the CMP Updates draft and have a question > regarding the ASN.1 module to put into the appendix. > > > > RFC 4210 has the normative CMP ASN.1 module in 1988 syntax. > > RFC 5912 Section 9 provides an update of the CMP ASN.1 module in 2002 > syntax. > > In RFC 6402 CMC Updates Jim added the updated normative CMC ASN.1 > module in 1988 syntax and added another ASN.1 module in 2008 syntax. > > 2015 another update of ASN.1 was published by ITU-T. > > > > For CMP Updates I plan to add an updated normative CMP ASN.1 module in > 1988 syntax as Appendix A.1. > > Like in RFC 4602, I would also add another ASN.1 module in a more curre= nt > ASN.1 syntax as Appendix A.2. > > Which ASN.1 syntax version should I use for this additional Appendix A.= 2? > > 1) 2002 like the CMP module in RFC 5912? > > 2) 2008 like Jim updated the CMC module to in RFC 6402? > > 3) 2015 which is the most recent ASN.1 syntax version? > > > > Any guidance is welcome! > > > > Hendrik > > > > With best regards, > > Hendrik Brockhaus > > > > Siemens AG > > Corporate Technology > > Research in Digitalization and Automation Security Architecture CT RDA > > CST SEA-DE Otto-Hahn-Ring 6 > > 81739 Muenchen, Germany > > Tel.: +49 89 780522411 > > Mobile: +49 174 1517765 > > mailto:hendrik.brockhaus@siemens.com > > http://www.siemens.com/ingenuityforlife > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > > Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, > > Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; > > Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB > > 6684; WEEE-Reg.-No. DE 23691322 > > From nobody Thu Aug 6 08:25:18 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A563A0B1C for ; Thu, 6 Aug 2020 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wWVTc-OmzIE4 for ; Thu, 6 Aug 2020 08:25:14 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28303A0B02 for ; Thu, 6 Aug 2020 08:25:13 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Aug 2020 08:24:47 -0700 From: Jim Schaad To: "'Brockhaus, Hendrik'" , 'Russ Housley' CC: 'LAMPS WG' References: <8AEBD494-1D3D-45CB-88C1-C251741EE3B3@vigilsec.com> In-Reply-To: Date: Thu, 6 Aug 2020 08:24:46 -0700 Message-ID: <065401d66c05$b967c430$2c374c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJn6QRcbm/ijYE1k9ilv1T29eBLbwJehoweAiizgkOn4/9bYA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates, Appendix A X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 06 Aug 2020 15:25:16 -0000 The set of changes between 2002 and 2015 are relatively small and I doubt would cause any changes in the modules. The versions are "normally" backwards compatible as well. -----Original Message----- From: Brockhaus, Hendrik Sent: Thursday, August 6, 2020 7:57 AM To: Russ Housley Cc: LAMPS WG ; Jim Schaad Subject: AW: draft-ietf-lamps-cmp-updates, Appendix A > Von: Russ Housley > > Jim already converted to the new ASN.1 syntax in RFC 5912/RFC 6402. I > suggest you use that module, and make the minor additions that are needed. RFC 5912 contains the 2002 CMP ASN.1 Module. I will put that into Appendix A.2 and update it. RFC 6402 contains only a 2008 CMC ASN.1 module, NOT a CMP module. I case the group changes its mind, I can update Appendix A.2 to a more recent ASN.1 syntax. Hendrik > > Russ > > > > On Aug 6, 2020, at 7:39 AM, Brockhaus, Hendrik > wrote: > > > > I am preparing an update of the CMP Updates draft and have a > > question > regarding the ASN.1 module to put into the appendix. > > > > RFC 4210 has the normative CMP ASN.1 module in 1988 syntax. > > RFC 5912 Section 9 provides an update of the CMP ASN.1 module in > > 2002 > syntax. > > In RFC 6402 CMC Updates Jim added the updated normative CMC ASN.1 > module in 1988 syntax and added another ASN.1 module in 2008 syntax. > > 2015 another update of ASN.1 was published by ITU-T. > > > > For CMP Updates I plan to add an updated normative CMP ASN.1 module > > in > 1988 syntax as Appendix A.1. > > Like in RFC 4602, I would also add another ASN.1 module in a more > > current > ASN.1 syntax as Appendix A.2. > > Which ASN.1 syntax version should I use for this additional Appendix A.2? > > 1) 2002 like the CMP module in RFC 5912? > > 2) 2008 like Jim updated the CMC module to in RFC 6402? > > 3) 2015 which is the most recent ASN.1 syntax version? > > > > Any guidance is welcome! > > > > Hendrik > > > > With best regards, > > Hendrik Brockhaus > > > > Siemens AG > > Corporate Technology > > Research in Digitalization and Automation Security Architecture CT > > RDA CST SEA-DE Otto-Hahn-Ring 6 > > 81739 Muenchen, Germany > > Tel.: +49 89 780522411 > > Mobile: +49 174 1517765 > > mailto:hendrik.brockhaus@siemens.com > > http://www.siemens.com/ingenuityforlife > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > > Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, > > Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; > > Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB > > 6684; WEEE-Reg.-No. DE 23691322 > > From nobody Thu Aug 6 19:25:41 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1793A0CFE; Thu, 6 Aug 2020 19:25:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc7030est-clarify@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159676713899.29487.17107197903809737059@ietfa.amsl.com> Date: Thu, 06 Aug 2020 19:25:39 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc7030est-clarify-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 02:25:39 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc7030est-clarify-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The reference to RFC 5212 (Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)) in the ASN.1 module needs to be replaced by 5912 (New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)). Note that the last-call announcement claimed (properly, according to the state of the document) that there is a downref to 5212, but 5912 is already in the registry so we should not need to re-run the IETF LC. It seems like we might want to move EIDs 4384, 5904, 5107, and 5108 out of status "Reported" (i.e., to "Hold for Document Update") before publishing this document. Abstract This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that were reported, and which has proven to cause interoperability issues when RFC7030 was extended. nit: singular/plural mismatch "has proven"/"errata that were reported". Section 4 Responses to attribute request messages MUST be encoded as the content-type of "application/csrattrs", and are to be "base64" [RFC2045] encoded. The syntax for application/csrattrs body is as Should this be 4648 (not 2045)? Section 5.2 Replace: If the content-type is not set, the response data MUST be a plaintext human-readable error message. with: If the content-type is not set, the response data must be a plaintext human-readable error message. Why do we lose the 2119 "MUST" here? We kept it in Section 5.1. Section 10.1 RFC 8179 is listed but does not seem to be cited anywhere. Section 10.2 One could perhaps argue that RFC 2985 should be normative, but it doesn't seem very important. Appendix A id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 } Pedantically, RFC 7030 spells it as "{id-aa 54}" but I'm not actually complaining about doing it this way. From nobody Fri Aug 7 05:14:43 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D633A0ADE for ; Fri, 7 Aug 2020 05:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1ZAUEHHcJAUm for ; Fri, 7 Aug 2020 05:14:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EDD3A0AB5 for ; Fri, 7 Aug 2020 05:14:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CB690300AA6 for ; Fri, 7 Aug 2020 08:14:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0ZpeqCmvsOc6 for ; Fri, 7 Aug 2020 08:14:34 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BD368300B50 for ; Fri, 7 Aug 2020 08:14:34 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_5661D35A-5849-4768-9705-949B88450903" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: References: <20200807050034.F1740F4074E@rfc-editor.org> To: LAMPS WG Date: Fri, 7 Aug 2020 08:14:35 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] Fwd: [Errata Verified] RFC5652 (6250) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 12:14:42 -0000 --Apple-Mail=_5661D35A-5849-4768-9705-949B88450903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > From: RFC Errata System > Subject: [Errata Verified] RFC5652 (6250) > Date: August 7, 2020 at 1:00:34 AM EDT > To: housley@vigilsec.com, housley@vigilsec.com > Cc: kaduk@mit.edu, iesg@ietf.org, smime@ietf.org, = rfc-editor@rfc-editor.org >=20 > The following errata report has been verified for RFC5652, > "Cryptographic Message Syntax (CMS)".=20 >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6250 >=20 > -------------------------------------- > Status: Verified > Type: Technical >=20 > Reported by: Russ Housley > Date Reported: 2020-08-06 > Verified by: Benjamin Kaduk (IESG) >=20 > Section: 9.2 >=20 > Original Text > ------------- > If the authAttrs field is present, the content-type attribute (as > described in Section 11.1) and the message-digest attribute (as > described in Section 11.2) MUST be included, and the input to the = MAC > calculation process is the DER encoding of authAttrs. A separate > encoding of the authAttrs field is performed for message digest > calculation. The IMPLICIT [2] tag in the authAttrs field is not = used > for the DER encoding, rather an EXPLICIT SET OF tag is used. That > is, the DER encoding of the SET OF tag, rather than of the IMPLICIT > [2] tag, is to be included in the message digest calculation along > with the length and content octets of the authAttrs value. >=20 > Corrected Text > -------------- > If the authAttrs field is present, the content-type attribute (as > described in Section 11.1) and the message-digest attribute (as > described in Section 11.2) MUST be included, and the input to the = MAC > calculation process is the DER encoding of authAttrs. A separate > encoding of the authAttrs field is performed for message digest > calculation. The IMPLICIT [2] tag in the authAttrs field is not = used > for the DER encoding, rather an EXPLICIT SET OF tag is used. That > is, the DER encoding of the SET OF tag, rather than of the IMPLICIT > [2] tag, is to be included in the MAC calculation along > with the length and content octets of the authAttrs value. >=20 > Notes > ----- > The paragraph is talking about the input to a MAC calculation, not the = input to message digest calculation. >=20 > -------------------------------------- > RFC5652 (draft-ietf-smime-rfc3852bis-00) > -------------------------------------- > Title : Cryptographic Message Syntax (CMS) > Publication Date : September 2009 > Author(s) : R. Housley > Category : DRAFT STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG --Apple-Mail=_5661D35A-5849-4768-9705-949B88450903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

From: = RFC Errata System <rfc-editor@rfc-editor.org>
Subject: = [Errata Verified] = RFC5652 (6250)
Date: August 7, 2020 at 1:00:34 AM EDT
To: = housley@vigilsec.com, = housley@vigilsec.com
Cc: kaduk@mit.edu, iesg@ietf.org, smime@ietf.org, rfc-editor@rfc-editor.org

The following errata report = has been verified for RFC5652,
"Cryptographic Message = Syntax (CMS)".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6250
--------------------------------------
Status: = Verified
Type: Technical

Reported by: Russ Housley <housley@vigilsec.com>
Date Reported: 2020-08-06
Verified by: Benjamin = Kaduk (IESG)

Section: 9.2

Original Text
-------------
=   If the authAttrs field is present, the content-type = attribute (as
  described in Section 11.1) and = the message-digest attribute (as
  described in = Section 11.2) MUST be included, and the input to the MAC
=   calculation process is the DER encoding of authAttrs. =  A separate
  encoding of the authAttrs = field is performed for message digest
=   calculation.  The IMPLICIT [2] tag in the authAttrs = field is not used
  for the DER encoding, = rather an EXPLICIT SET OF tag is used.  That
=   is, the DER encoding of the SET OF tag, rather than of the = IMPLICIT
  [2] tag, is to be included in the = message digest calculation along
  with the = length and content octets of the authAttrs value.

Corrected Text
--------------
=   If the authAttrs field is present, the content-type = attribute (as
  described in Section 11.1) and = the message-digest attribute (as
  described in = Section 11.2) MUST be included, and the input to the MAC
=   calculation process is the DER encoding of authAttrs. =  A separate
  encoding of the authAttrs = field is performed for message digest
=   calculation.  The IMPLICIT [2] tag in the authAttrs = field is not used
  for the DER encoding, = rather an EXPLICIT SET OF tag is used.  That
=   is, the DER encoding of the SET OF tag, rather than of the = IMPLICIT
  [2] tag, is to be included in the = MAC calculation along
  with the length and = content octets of the authAttrs value.

Notes
-----
The paragraph is = talking about the input to a MAC calculation, not the input to message = digest calculation.

--------------------------------------
RFC5652 = (draft-ietf-smime-rfc3852bis-00)
--------------------------------------
Title =             &n= bsp; : Cryptographic Message Syntax (CMS)
Publication = Date    : September 2009
Author(s) =           : R. = Housley
Category =            : = DRAFT STANDARD
Source =             &n= bsp;: S/MIME Mail Security
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_5661D35A-5849-4768-9705-949B88450903-- From nobody Fri Aug 7 08:07:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038EF3A03EE for ; Fri, 7 Aug 2020 04:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 vfpzyJkvd-aZ for ; Fri, 7 Aug 2020 04:01:58 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A883A02BE for ; Fri, 7 Aug 2020 04:01:57 -0700 (PDT) Received: from macsilver.fritz.box ([62.54.177.99]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MFbFW-1jwo3x3IGk-00H7xk for ; Fri, 07 Aug 2020 13:01:55 +0200 From: Metin Savignano Content-Type: multipart/signed; boundary="Apple-Mail=_80DC2D24-83E0-48C8-B32F-340DDF087CD1"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <5F4E87EE-4CD1-4A9F-BDE2-82AD8FD6EFB1@savignano.net> Date: Fri, 7 Aug 2020 13:01:53 +0200 To: spasm@ietf.org X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:7TxAPbinrV5pGE0zTzi94vGE/iWLSeYsR/DB8rs1I+g3ghYakfX XoEhlZG6G2JSSGpJljLHcQ9si0IX/i0w9fwYY0z9AiFBJ5SM3EBqAFfw4w1JR9VuVnpfsR1 rR+v6cD868SItvvJmLmbmFfNeLQdm/WbLJ9Z/UhQO1/S3CCj4S5XUIXYIUAyk2QDG3HN/dF Zxz/tK6KmpqKDJGcJB+pA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ez77q1d5xYA=:oD/gO/s1xTZuYZLj/tVzLM oOgPXUh/GMuHrR321y7Dqm3MJlriFdlrB+Ezj1YEzTg/nOnGYsQO7PY3G13Fse5ncn+L6Duyf //OxxutIYIWUOIP/U6uEbKDCqqKYE4DAxR7T3rH0JWvHsJK1FUuGYEYEJgQ+lgXg3NKPBpi/V jWC6pmeWPBK/IqU5sfqqdAWziYnjRa0fY2+9RYTn63+8Pdn4yFMi3JGxCfp5UBxNtsPMvJPOw WYHD8ZvO1EjABww1c2b67V4bXBmGehcNzyKzXb9jnpoUGCEnVr0KOQ/3Ht7o+7R3l2WlR5h/S XS9hk4g9q0wKoTZgEJF0loH7e8jEI/rZniHZI+aqtuoku75zazg6Eb/RcF3UdOfYT2SGgnfM4 TqOYe8gFPtSepe3b3zF36UCuRLCgvPQHREdz9xBGntNQqkVfxR0VhEoLDZ7aFF2nCuZ31CRpA s1yi0QBxWBQKTK2rOdKU+gPoQYiu9uZ6kDU4+0CaRJkmCIIjfG+B3Cqb7m8Y1zqZApf2p18HR dC8NnIIbFXvQKidk2Wj1ggeXqRCKaK3sQrPG+bm/C0xBlJfOsxvwNXj7s32Dht+P4ksvCoa59 3eoz9SYD1E2bIN9Pa0jgp/Sq/0nk12n2ksjeUC0m6jYhB1u2jHrD9iAAFJeTPKGc3BUotu+2n 7yjx3fEI9IOncC980iYC9UfB7vgb1HV+P3lNlqnMWBK58jFyxrseozfW/cPn7QiPxI621z5VH D4o5W9ixLTbARGUzbDjChj9izfubm1qb+BBwZyeQxE4rEvHX3+QH0Gqilf2As0bSw21R+XuuG P9FYYDzElYQYjwtt8Ahnh+6khHSdA4xoaMssCq0ikWhQkOT63I4onpUxGfYwOIPPFBiUFfT Archived-At: X-Mailman-Approved-At: Fri, 07 Aug 2020 08:07:05 -0700 Subject: [lamps] Possible inconsistencies or ambiguities in RFC 8551 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 11:02:00 -0000 --Apple-Mail=_80DC2D24-83E0-48C8-B32F-340DDF087CD1 Content-Type: multipart/alternative; boundary="Apple-Mail=_D3C3810D-080C-4FF6-B099-DE2CE5ED68E1" --Apple-Mail=_D3C3810D-080C-4FF6-B099-DE2CE5ED68E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors, First of all, thank you very much for your work to create a new and = better version of S/MIME!=20 As an author of an S/MIME app, we are working through RFC 8551 to = determine the changes we have to implement in order to fully comply to = the S/MIME 4.0 specs. However, I=E2=80=99ve come to a point where I seem unable to understand = what the RFC actually recommends with regard to the backward = compatibility. I=E2=80=99ve also discussed this with another software = developer, but we both weren=E2=80=99t sure how to read it. It would be = awesome if you could help me with a clarification. In the relevant scenario, the sending agent wants to send encrypted = email to a recipient with unknown capabilities. With regard to backward compatibility, RFC 8551 states in section 1.4: S/MIME version 4.0 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. Although this is a very general statement, I believe it is contradictory = to the description about how to decide which content encryption cipher = to use in section 2.7.1.2: If the following two conditions are met, the sending agent SHOULD use AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required by S/MIME v4.0: - The sending agent has no knowledge of the encryption capabilities of the recipient. - The sending agent has no knowledge of the version of S/MIME used or supported by the recipient. I don=E2=80=99t understand why we should choose AES-256-GCM if we = don=E2=80=99t know about the recipients capabilities and S/MIME version.=20= For example, if the recipient uses an S/MIME 3.2 compliant software, as = I understand RFC 5751, that software need not know about AES-256-GCM. = The GCM block mode is not even mentioned in earlier S/MIME versions.=20 As a consequence, doesn=E2=80=99t the selection of AES-256-GCM = contradict the "attempt to have the greatest interoperability possible = with agents for prior versions of S/MIME=E2=80=9C?=20 The common capability in both S/MIME versions would be AES-128-CBC, = wouldn=E2=80=99t it? Also, I do not really understand the following sentence: If the sending agent chooses not to use AES-256 GCM in this step, given the presumption is that a client implementing AES-GCM would do both AES-256 and AES-128, it SHOULD use AES-128 CBC. It appears to me as if this sentence was grammatically either wrong or = uses a construct that I don=E2=80=99t understand (I=E2=80=99m not a = native speaker). I don=E2=80=99t understand what "given the presumption = is that a client implementing AES-GCM would do both AES-256 and = AES-128=E2=80=9C is meant to tell me in that context. Also, I=E2=80=99m = not sure if the word =E2=80=9Eclient=E2=80=9C is meant to refer to the = sending or receiving client. At first, I thought it=E2=80=99s the = receiving client, but after re-reading a few times, I=E2=80=99m unsure = if it=E2=80=99s the sending agent, because I don=E2=80=99t understand = why I should make presumptions about the receiving client implementing = AES-GCM when I don=E2=80=99t know anything about it. I would recommend that this sentence maybe rephrase to make it more = understandable for non-native speakers. What I would have expected in section 2.7.1.2: To maintain "greatest interoperability possible with agents for prior = versions of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if the = recipient=E2=80=99s capabilities and S/MIME version aren=E2=80=99t = known. Where am I off the track? Thanks a lot! Metin Savignano --Apple-Mail=_D3C3810D-080C-4FF6-B099-DE2CE5ED68E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = authors,

First of = all, thank you very much for your work to create a new and better = version of S/MIME! 

As an author of an S/MIME app, we are = working through RFC 8551 to determine the changes we have to implement = in order to fully comply to the S/MIME 4.0 specs.
However, I=E2=80=99ve come to a point = where I seem unable to understand what the RFC actually recommends with = regard to the backward compatibility. I=E2=80=99ve also discussed this = with another software developer, but we both weren=E2=80=99t sure how to = read it. It would be awesome if you could help me with a = clarification.

In the relevant scenario, the sending agent wants to send = encrypted email to a recipient with unknown capabilities.

With regard to backward = compatibility, RFC 8551 states in section 1.4:

   S/MIME version 4.0 agents =
ought to attempt to have the greatest
   interoperability possible with agents for prior versions of =
S/MIME.

Although this is a very general statement, I believe it is = contradictory to the description about how to decide which content = encryption cipher to use in section 2.7.1.2:

   If the following two =
conditions are met, the sending agent SHOULD use
   AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
   by S/MIME v4.0:
   -  The sending agent has no knowledge of the encryption capabilities
      of the recipient.

   -  The sending agent has no knowledge of the version of S/MIME used
      or supported by the recipient.

I don=E2=80=99t=
 understand why we should choose AES-256-GCM if we don=E2=80=99t know =
about the recipients capabilities and S/MIME version. 

For example, if the recipient uses an S/MIME =
3.2 compliant software, as I understand RFC 5751, that software need not =
know about AES-256-GCM. The GCM block mode is not even mentioned in =
earlier S/MIME versions. 

As a =
consequence, doesn=E2=80=99t the selection of AES-256-GCM contradict =
the "attempt to have the greatest interoperability possible =
with agents for prior versions of =
S/MIME=E2=80=9C? 

The =
common capability in both S/MIME versions would be AES-128-CBC, =
wouldn=E2=80=99t it?


Also, I do = not really understand the following = sentence:

   If the sending agent chooses =
not to use AES-256 GCM in this step,
   given the presumption is that a client implementing AES-GCM would do
   both AES-256 and AES-128, it SHOULD use AES-128 CBC.

It = appears to me as if this sentence was grammatically either wrong or uses = a construct that I don=E2=80=99t understand (I=E2=80=99m not a native = speaker). I don=E2=80=99t understand what "given the presumption is that = a client implementing AES-GCM would do both AES-256 and AES-128=E2=80=9C =  is meant to tell me in that context. Also, I=E2=80=99m not sure if = the word =E2=80=9Eclient=E2=80=9C is meant to refer to the sending or = receiving client. At first, I thought it=E2=80=99s the receiving client, = but after re-reading a few times, I=E2=80=99m unsure if it=E2=80=99s the = sending agent, because I don=E2=80=99t understand why I should make = presumptions about the receiving client implementing AES-GCM when I = don=E2=80=99t know anything about it.

I would recommend that this sentence = maybe rephrase to make it more understandable for non-native = speakers.

What = I would have expected in section 2.7.1.2:

To maintain = "greatest interoperability possible with agents for prior versions = of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if the = recipient=E2=80=99s capabilities and S/MIME version = aren=E2=80=99t known.

Where am I off the track?


Thanks a lot!

Metin Savignano







= --Apple-Mail=_D3C3810D-080C-4FF6-B099-DE2CE5ED68E1-- --Apple-Mail=_80DC2D24-83E0-48C8-B32F-340DDF087CD1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBDQw ggQwMIIDGKADAgECAgEgMA0GCSqGSIb3DQEBCwUAMIG1MRowGAYDVQQDDBFzYXZpZ25hbm8gQ0VS VC1pMzElMCMGA1UECgwcc2F2aWduYW5vIHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwUQ2Vy dGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwLTHVk d2lnc2J1cmcxITAfBgkqhkiG9w0BCQEWEmNlcnRAc2F2aWduYW5vLm5ldDAeFw0xOTExMDUyMDI2 MjJaFw0yMjAxMzEyMDI2MjJaMIGSMRgwFgYDVQQDDA9NZXRpbiBTYXZpZ25hbm8xJTAjBgNVBAoM HHNhdmlnbmFubyBzb2Z0d2FyZSBzb2x1dGlvbnMxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEU MBIGA1UEBwwLTHVkd2lnc2J1cmcxHzAdBgkqhkiG9w0BCQEWEG1zQHNhdmlnbmFuby5uZXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxnKn6b7wTrY7G4ov3Hdt6Z9Q4p3obZ8WFzXyg ++Vlf7FnPQL9wIYNfpMRexAZK1/y6kiaPhVFArm6/RZicRDv8/89IB8SlITGqXx0/Y+S4jSxre8E FUXi/BFhbI/F/jMv+YUUgUf/cMpu62F726u0PSUgX+4UQgmV9ksex3UV2KF7juHjuibUqYmHldWt 6lfDaAf5fBBlhL/x8cF6KjPjTC3DUrL1GMga8ZQfNfyPRpwVudgrK40yaTda+eHU8dLjOtrc6K/p PM/cx90RfL9IrLiyx1dZMPvjNHcxVwPdsTIrqom4DSNX9s4wRf70f/MpHL6aZ7IxuhdQO1bqd3Ah AgMBAAGjbDBqMA4GA1UdDwEB/wQEAwIFoDAmBgNVHSUEHzAdBggrBgEFBQcDBAYIKwYBBQUHAwIG BysGAQUCAwQwMAYDVR0RBCkwJ4EQbXNAc2F2aWduYW5vLm5ldIETbWV0aW5Ac2F2aWduYW5vLm5l dDANBgkqhkiG9w0BAQsFAAOCAQEAnvw8CEHRy3xCSHrcmCh1/b6PlxCURYynWgABvJgd3+0Acw4V DRgtA7vnozkSu/FHZy2pNv1wOf2F3AWIU9qUxqssZogvIgI1LwKQZ2YO+ymkous4qBWc44Twmhi2 2juBjuxEUPC3+x/ZEmkCz4z95qtHeL+B3EqpcGgDemkTgtT7mv0053mN+vyFOxpxQiSKfMAVwvJe lTLax2g3MXbT7ycZpHXJ2nnA/ZprqJg5+bFMg9J/Q9Vvc5q3d6qFU+Od7JzKg79gWe8p7S8Dul0b Bcl0phLIgPHk++lxlGDtizzOt5DZWcVyKKGeMDNPPKtopb9ZQulRKJj20szhznopKzGCA/QwggPw AgEBMIG7MIG1MRowGAYDVQQDDBFzYXZpZ25hbm8gQ0VSVC1pMzElMCMGA1UECgwcc2F2aWduYW5v IHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwUQ2VydGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNV BAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwLTHVkd2lnc2J1cmcxITAfBgkqhkiG9w0BCQEW EmNlcnRAc2F2aWduYW5vLm5ldAIBIDANBglghkgBZQMEAgEFAKCCAgkwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODA3MTEwMTUzWjAvBgkqhkiG9w0BCQQxIgQg qZMcwI4JjCZyyfqwtkiavqEbxHphNUe/opLUQHWu31QwgcwGCSsGAQQBgjcQBDGBvjCBuzCBtTEa MBgGA1UEAwwRc2F2aWduYW5vIENFUlQtaTMxJTAjBgNVBAoMHHNhdmlnbmFubyBzb2Z0d2FyZSBz b2x1dGlvbnMxHTAbBgNVBAsMFENlcnRpZmNhdGlvbiBTZXJ2aWNlMQswCQYDVQQIDAJCVzELMAkG A1UEBhMCREUxFDASBgNVBAcMC0x1ZHdpZ3NidXJnMSEwHwYJKoZIhvcNAQkBFhJjZXJ0QHNhdmln bmFuby5uZXQCASAwgc4GCyqGSIb3DQEJEAILMYG+oIG7MIG1MRowGAYDVQQDDBFzYXZpZ25hbm8g Q0VSVC1pMzElMCMGA1UECgwcc2F2aWduYW5vIHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwU Q2VydGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwL THVkd2lnc2J1cmcxITAfBgkqhkiG9w0BCQEWEmNlcnRAc2F2aWduYW5vLm5ldAIBIDANBgkqhkiG 9w0BAQEFAASCAQCoeff5cF6U1/hL1kSNtVbNcCdSriyNo/AU0SQ/03HpoWQbJBZb02HBZrQlorxY FK+hFt+W3MTCUYH/zptSUgmMvHLZbAJfQ8qf84K+8Q765o9y5CHzsaC3BZ/uRIVoIWICGDebHKnM IF4xzMugkStCJPliblDM4KNTfD2JdJyaafg3eBZsDMagHeb568wxvyX86VfRDcL5PDsTZpJoM08y WHBNNdyo/zSRzMu/VoBdGxycwPbTIRd40UxFmzFgWEwGfYN1quDcF5/89kKBm2xC7BIxYEdw0+dw Pbug8yGaJciofgl3IsdwVbNLw2jOfBg86T+Yx9kvmVy1x4TWGBT6AAAAAAAA --Apple-Mail=_80DC2D24-83E0-48C8-B32F-340DDF087CD1-- From nobody Fri Aug 7 10:28:06 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3757F3A0F46; Fri, 7 Aug 2020 10:28:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159682128416.6526.8624018981738492965@ietfa.amsl.com> Date: Fri, 07 Aug 2020 10:28:04 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 17:28:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : CMP Updates Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-updates-03.txt Pages : 41 Date : 2020-08-07 Abstract: This document contains a set of updates to the base syntax and transport of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210 and RFC 6712. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue, the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities, and adds an HTTP URI discovery mechanism and extend the URI structure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-updates-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 7 10:38:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1133A0FAA for ; Fri, 7 Aug 2020 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 XAPiriyPzKx6 for ; Fri, 7 Aug 2020 10:38:18 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2069.outbound.protection.outlook.com [40.107.21.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE503A0ED6 for ; Fri, 7 Aug 2020 10:38:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XxMnyw8s2f5cGuqcM2sDSctBR5qxJ2VF8dfkr+Wy4TYazye0j34T5rGNg02fbyUJbVsj/mu3AsT9yuu97kFAMIXi1JbgpiUbS4TNoOpsxuWuYgDl8QFPFd7blcv3wZaeIymbgShu+JTdENysS/MdD+Dqoc4Mb+Y6SQ7EJfGJCP5RizqAfUek89SMp+XZz9sgE56UrvNwLzjg8H9pwsCnC0RN5H6mRJtDBnNvUug94Di9vo5A6RzHY34MOSad5datmrtbikD6PZlBFsyQImCmFesRggV/tx+eeRMyLOO2Mlq9Vx9KWxR7I5yJRbQ3EZWz2Vc8lbZW7Bhf+nHC86J2YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P0+GfmTWZGmsRVGiNeq04F2mYIA1cGmovNELizajolI=; b=lrO6XcyrJjHLAW/cXbX1A+GG8oWiJhyj/ipbHKbVQFcp/xqbkwwxA6d567k9HMxzQ6G+jQ7fASTj5CxdIxGL0/3jrxyH/hHMSmJpsLrnsAJS1Qix763Z/9Jy+XUSyp0QIHBjK0Ha2N5naP8ZMYduUvUbRsBlXEvY7hipxUGoPBALpOXwHV1NPsBlRX8AfsPBBhFYJcYg+2OvpYFoL1aHErtKC2nsqA3vV+VwhL2vdPiEZtSjPlNrFU7fSJnfezZagleN3ZkLSNLhDH8eBuUVVhpE29OqkptdAdZoehniRqTgz8JzuRWv0PH3fKVX4ghHUjv9RhSSqXcigF9hRc641w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P0+GfmTWZGmsRVGiNeq04F2mYIA1cGmovNELizajolI=; b=oL0Q0Wo3mLpRowNqjwEMHTpYZvJz+yaej3iESBeyZyFdb1YVLuNICwEL5F9YSWvvxqnQ4FiUo2XwwwVsJNZWGVNzIM5p2LrNxUykfhBYFabfum6PHP470w0TahD4Qu88li60heRdv8n7d3raN/8RS1ChLATdkkh8wqB/pIstgjs= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM4PR1001MB1234.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:200:8f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.17; Fri, 7 Aug 2020 17:38:08 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6%5]) with mapi id 15.20.3261.019; Fri, 7 Aug 2020 17:38:08 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" CC: "Peylo, Martin (Nokia - FI/Espoo)" , Tomas Gustavsson , "david.von.oheimb@siemens.com" , "steffen.fries@siemens.com" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-03.txt Thread-Index: AQHWbOA0Vfg4BcHJFE+FWvjelEsjKKks5tBg Content-Class: Date: Fri, 7 Aug 2020 17:38:07 +0000 Message-ID: References: <159682128416.6526.8624018981738492965@ietfa.amsl.com> In-Reply-To: <159682128416.6526.8624018981738492965@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-07T17:38:06Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=bb2ad7ce-0d0d-47f5-9727-a9b0bffd45c9; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 540f3239-1810-47f2-8430-08d83af8a5cb x-ms-traffictypediagnostic: AM4PR1001MB1234: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 56Z7g3RTE6EG+AFnpm2iDCTrFAJ8He35Lx1bM7Xac4S4h58J3jJOld1w6Zh5Q/soaLVUV1LqihUKj9v4ydHCUFs7AL6kquMC77XPdMrX6Di2dOH7sAlycdR4mBm+P0stXXQvSSbKGUSOq9itlmyTE+Whpgum/ZVa+aKFsGTAOnVh4CcI3EBRAxNEVWVx1B1LEktdPKjuv8VFyFRqQmpQAJXBUz4QiSnsWWaknBqUZbjEeUJ0n/4IDYJWXUjsY1foDMDJTVc4TDIgFjBx2DucZuJbGVahKsDd1cj4w2sb3JR6ZPdcq+KVeZkHuS6kRSyJq1TOPuwYDBRWSwAVCTwPQ1ahvSiOK1G5vJOG9OPsBQZMrTyVmtR+9tVK0Ex6SPstMFsHJQhBpoZebjqNczkiXQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(366004)(136003)(376002)(54906003)(6506007)(6916009)(83380400001)(478600001)(83080400001)(66946007)(71200400001)(8676002)(5660300002)(7696005)(66476007)(66556008)(64756008)(66446008)(76116006)(966005)(55016002)(107886003)(52536014)(66574015)(316002)(26005)(86362001)(2906002)(8936002)(9686003)(33656002)(4326008)(15650500001)(186003)(45080400002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xn/UuMPOngj9YRZHF+aV/2C2qQSRW3gvDJ8fXnbAp9cYMsE60avh4HzqZJ9CzNp9XWis81J0QGMLFKplOVXBjPriEajZKkyEPif4MHYLIjUwxF/TmY7YB7oFb/hUho3D7wdxYah7AeHnYTHWevio7tZnUNmPr54da9O6dOacckHeKwdMbWVs6FazAQICego/uEG4XwB1B4WBra75ezLD8aq8auGhvNUUPao9/biZhZjq+a25zajaqUb0VE+azwXwJWdEr4PhMz4+v8EyNNjeazj1WmJv9uJ/gAp9pWkWt3Ugghw2XpiQOWSORX5Mu2NhiTotRgJ3R0t5gWUUUsfOU8l0ymnYzj/jwAX3v+V1TRatcaGCRvT7xmtC6cx6ccxuK1VErEhqUxusTXZKVflG/RA+zFKNBJJJ8TDKqjIsjvovONVFKM8Ag07CzZkx1Ohau5g6RoDJON8WLM6pn0ZeDr8lyOPQJJInMl/l+75Q2FTIeCx8bVAf1wQah+RqhPY687ytnPjYff/VU3j5LqXEA/SniP3SsezH2P43MaTNDtDoF9c3lJtHf6Ja8MpTbjSchpncwoxDbz/rpj8xQ4bdqquUnT/S53908hixgwCI54K5k81M+GVMpRuAzTediIQdprItKnHX9Lc4+fsfMAiHeg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 540f3239-1810-47f2-8430-08d83af8a5cb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 17:38:07.9314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: voqAQ65ckmiIimQH5OwnJmlMDfJmPLpjy1JNHo3fYW+qWh2aSU3cn1tiM+Vwr1Y6DdIezqkGY3o+hI28B7v4V/P0bRZyol2TxmquLxjkfQs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR1001MB1234 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 17:38:25 -0000 This update of the CMP Updates draft contains the following changes: o Added a ToDo on aligning with the CMP Algorithms draft that will be set up as decided in IETF 108 o Updated section on Encrypted Values in Section 2.4 to add the AsymmetricKey Package structure to transport a newly generated private key as decided in IETF 108 o Updated the IANA Considerations of [RFC4210] in Section 2.9 o Added the pre-registered OID in Section 2.9 and the ASN.1 module o Added Section 3 to document the changes to RFC 6712 [RFC6712] regarding URI discovery and using the path-prefix of '/.well-known/' as discussed in IETF 108 o Updated the IANA Considerations section o Added a complete updated ASN.1 module in 1988 syntax to update Appendix F of [RFC4210] and a complete updated ASN.1 module in 2002 syntax to update Section 9 of [RFC5912] There are still some open issues: In Section 3.2 It needs to be discussed if the discovery should be performed using GET on = "/.well-known/cmp" or GET on "/.well-known" only.=20 There is a similar discussion going on in ANIMA regarding BRSKI-AE. In Appendix A.2 Dose this document then also updates [RFC5912] with the updated 2002 ASN.1 = module? In case the working group sees a need to provide this ASN.1 module in 2015 = syntax, please let me know.=20 Any feedback is welcome. Hendrik > Von: Spasm Im Auftrag von internet-drafts@ietf.o= rg >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : CMP Updates > Author : Hendrik Brockhaus > Filename : draft-ietf-lamps-cmp-updates-03.txt > Pages : 41 > Date : 2020-08-07 >=20 > Abstract: > This document contains a set of updates to the base syntax and > transport of Certificate Management Protocol (CMP) version 2. This > document updates RFC 4210 and RFC 6712. >=20 > Specifically, the CMP services updated in this document comprise the > enabling of using EnvelopedData instead of EncryptedValue, the > definition of extended key usages to identify certificates of CMP > endpoints on certification and registration authorities, and adds an > HTTP URI discovery mechanism and extend the URI structure. >=20 >=20 > The IETF datatracker status page for this draft is: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp- > updates%2F&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc > ba797fa4c7943aaddbe08d83af755ef%7C38ae3bcd95794fd4addab42e1495d55a > %7C1%7C0%7C637324181254353548&sdata=3DY%2FxBiQ%2FBgE%2B90U% > 2FNTC7inNxj5XZz0CHJidqgW5DfYfI%3D&reserved=3D0 >=20 > There are also htmlized versions available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-cmp-updates- > 03&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Ccba797fa4c > 7943aaddbe08d83af755ef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637324181254353548&sdata=3D27Sdw9mDrHc8XSkTUxe2lpa8om9iLdu > 1p7tYM%2F7RNjw%3D&reserved=3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-updates- > 03&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Ccba797fa4c > 7943aaddbe08d83af755ef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637324181254353548&sdata=3Dw0%2B8bL6n4TcuOK9NMh%2FPwhQe > hGfCmGdfixYeT0dgC3g%3D&reserved=3D0 >=20 > A diff from the previous version is available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-updates- > 03&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Ccba797fa4c > 7943aaddbe08d83af755ef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637324181254353548&sdata=3DW5BS1yuuT7cFZBjJrNmimczhpR5e%2F > ctqiKvmd5RhWz0%3D&reserved=3D0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://eur01.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org% > 2Finternet- > drafts%2F&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Ccba > 797fa4c7943aaddbe08d83af755ef%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1%7C0%7C637324181254353548&sdata=3DWoEafGNQNoWdlyJQbEKSILE1 > S3Vcr15AZvQu0RRSgts%3D&reserved=3D0 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.brockha > us%40siemens.com%7Ccba797fa4c7943aaddbe08d83af755ef%7C38ae3bcd957 > 94fd4addab42e1495d55a%7C1%7C0%7C637324181254353548&sdata=3DTgc > iBXZoURLhsTDq%2BSvRnBmaH%2FScYxLnVV1zFAlwLcU%3D&reserved=3D0 From nobody Fri Aug 7 14:09:37 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 809393A0AB6; Fri, 7 Aug 2020 14:09:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159683457548.2696.9826581248208515526@ietfa.amsl.com> Date: Fri, 07 Aug 2020 14:09:35 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 21:09:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection Author : Russ Housley Filename : draft-ietf-lamps-cms-update-alg-id-protect-03.txt Pages : 8 Date : 2020-08-07 Abstract: This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-protect-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-update-alg-id-protect-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 7 14:14:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91323A0AEF for ; Fri, 7 Aug 2020 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7tpwFvMOlvbA for ; Fri, 7 Aug 2020 14:14:02 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEA13A0A65 for ; Fri, 7 Aug 2020 14:14:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9F416300B40 for ; Fri, 7 Aug 2020 17:13:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 25cKgAWDYJuK for ; Fri, 7 Aug 2020 17:13:58 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 53064300AAF for ; Fri, 7 Aug 2020 17:13:58 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Fri, 7 Aug 2020 17:13:59 -0400 References: <159683457548.2696.9826581248208515526@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <159683457548.2696.9826581248208515526@ietfa.amsl.com> Message-Id: <8C63F45E-0F2D-409C-A202-76AE0CE205EE@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 07 Aug 2020 21:14:04 -0000 The editorial comments from the Security AD review were addressed. In = addition, based on a review that I received off list, I have updated the = security considerations. The new text shows that RSA PKCS#1 v1.5 = provided additional protection for the digest algorithm identifier, and = it helped mitigate hash substitution attacks. Finally, the references = were update to the most recent versions of [DSS] and [SHS]. Russ > On Aug 7, 2020, at 5:09 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection > Author : Russ Housley > Filename : = draft-ietf-lamps-cms-update-alg-id-protect-03.txt > Pages : 8 > Date : 2020-08-07 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers in = signed- > data and authenticated-data content types are adequately protected. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From nobody Fri Aug 7 22:12:38 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0473A0D47; Fri, 7 Aug 2020 22:12:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc7030est-clarify@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159686355596.26142.7096202724793488066@ietfa.amsl.com> Date: Fri, 07 Aug 2020 22:12:36 -0700 Archived-At: Subject: [lamps] Martin Duke's No Objection on draft-ietf-lamps-rfc7030est-clarify-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 08 Aug 2020 05:12:36 -0000 Martin Duke has entered the following ballot position for draft-ietf-lamps-rfc7030est-clarify-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- RFC 2616 is obsolete and should probably be replaced by one of its successors. From nobody Sat Aug 8 06:10:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8046F3A09D6 for ; Sat, 8 Aug 2020 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iUI5EQib1jf3 for ; Sat, 8 Aug 2020 06:10:00 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F388E3A099C for ; Sat, 8 Aug 2020 06:09:59 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 078D9vJf031286 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 8 Aug 2020 15:09:58 +0200 Received: from [139.22.34.45] ([139.22.34.45]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 078D9viY016039 for ; Sat, 8 Aug 2020 15:09:57 +0200 References: <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com> To: spasm@ietf.org From: David von Oheimb X-Forwarded-Message-Id: <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com> Message-ID: <49ea220b-1bcb-ec5a-c9af-cd3aba308731@siemens.com> Date: Sat, 8 Aug 2020 15:09:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com> Content-Type: multipart/alternative; boundary="------------89B6A1855210741988972B08" Content-Language: en-US Archived-At: Subject: [lamps] Fwd: [Technical Errata Reported] RFC8410 (6229) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 08 Aug 2020 13:10:03 -0000 This is a multi-part message in MIME format. --------------89B6A1855210741988972B08 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -------- Forwarded Message -------- Subject: Re: [Technical Errata Reported] RFC8410 (6229) Date: Sat, 8 Aug 2020 15:05:31 +0200 From: David von Oheimb To: Benjamin Kaduk , RFC Errata System CC: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, daniel.migault@ericsson.com, rsalz@akamai.com, curdle@ietf.org, lamps@ietf.org Thanks Ben for your comment. Unfortunately I cannot find online the whole tread of this discussion, and I can neither find how to join the LAMPS mailing list, where there might already be further responses. Hope that nevertheless I can contribute to the discussion this way by email and will receive any further responses. The cert in question is part of the OpenSSL repository at https://github.com/openssl/openssl/blob/master/test/certs/ee-ed25519.pem To answer first your indirect question which private key signed this cert: As I found during the discussion on a somewhat related OpenSSL issue: https://github.com/openssl/openssl/issues/1418#issuecomment-448204709 this cert has been signed by the private key belonging to https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pem so that cert is the issuer cert of the cert in question, ee-ed25519.pem. BTW, it would be less confusing if the cert file had been named ee-x25519.pem instead. This issuing relation can be verified using the following OpenSSL command: apps/openssl verify -trusted test/certs/root-ed25519.pem test/certs/ee-ed25519.pem RFC 8410 sections 10.1 and 10.2 (https://tools.ietf.org/html/rfc8410#section-10.1) do not clearly state this issuing relation with the public key given in section 10.1, which in my view is a further thing to be improved. The OpenSSL repository contains this public key at https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pubkey.pem The private key corresponding to the public key given in 10.1 is given in section 10.3 but also here the relation with the public key is implicit and should better be made explicit. The OpenSSL repository contains this private key at https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.privkey.pem Normally, the issuance of ee-ed25519 would be easy to detect by the issuer/authority key ID of the cert, but due to the malformedness that is the very issue being discussed in this errata entry, the AKID is missing. I object the suggested trivial 'solution' to remove the word "PKIX" from the description because this does not really cure the form of the certificate. Moreover I see not much sense to have bad examples of certs in RFCs and other standards unless they serve the purpose of explicitly giving as negative example for some good reason. Here, instead, the purpose of the example clearly is to illustrate good use of an X25519 public key, and this should be done in a positive, standards-compliant way, which in this case means RFC 5280 / PKIX conformance. - David On 05.08.20 01:19, Benjamin Kaduk wrote: > Adding LAMPS. > > My confidence level here is not terribly high, since there is no > certificate presented with the public key whose private key signed the > X25519 certificate in question and there is some possibility of a different > edge case that allows this behavior. > > That said, it seems like the smallest possible change would be to just > remove the word "PKIX" from the description of the certificate in question. > > -Ben > > On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote: >> The following errata report has been submitted for RFC8410, >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6229 >> >> -------------------------------------- >> Type: Technical >> Reported by: David von Oheimb >> >> Section: 10.2 >> >> Original Text >> An example of a self-issued PKIX certificate using Ed25519 to sign an >> X25519 public key would be >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing). >> It includes a subjectKeyIdentifier but not an authorityKeyIdentifier. >> >> For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present. >> >> Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate. >> Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8410 (draft-ietf-curdle-pkix-10) >> -------------------------------------- >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure >> Publication Date : August 2018 >> Author(s) : S. Josefsson, J. Schaad >> Category : PROPOSED STANDARD >> Source : CURves, Deprecating and a Little more Encryption >> Area : Security >> Stream : IETF >> Verifying Party : IESG --------------89B6A1855210741988972B08 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
-------- Forwarded Message --------
Subject: Re: [Technical Errata Reported] RFC8410 (6229)
Date: Sat, 8 Aug 2020 15:05:31 +0200
From: David von Oheimb <David.von.Oheimb@siemens.com>
To: Benjamin Kaduk <kaduk@mit.edu>, RFC Errata System <rfc-editor@rfc-editor.org>
CC: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, daniel.migault@ericsson.com, rsalz@akamai.com, curdle@ietf.org, lamps@ietf.org


Thanks Ben for your comment.

Unfortunately I cannot find online the whole tread of this discussion,
and I can neither find how to join the LAMPS mailing list, where there might already be further responses.
Hope that nevertheless I can contribute to the discussion this way by email and will receive any further responses.

The cert in question is part of the OpenSSL repository at
https://github.com/openssl/openssl/blob/master/test/certs/ee-ed25519.pem

To answer first your indirect question which private key signed this cert:

As I found during the discussion on a somewhat related OpenSSL issue:
https://github.com/openssl/openssl/issues/1418#issuecomment-448204709

this cert has been signed by the private key belonging to
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pem
so that cert is the issuer cert of the cert in question, ee-ed25519.pem.
BTW, it would be less confusing if the cert file had been named ee-x25519.pem instead.

This issuing relation can be verified using the following OpenSSL command:

apps/openssl verify -trusted test/certs/root-ed25519.pem test/certs/ee-ed25519.pem

RFC 8410 sections 10.1 and 10.2 (https://tools.ietf.org/html/rfc8410#section-10.1)
do not clearly state this issuing relation with the public key given in section 10.1,
which in my view is a further thing to be improved.
The OpenSSL repository contains this public key at
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pubkey.pem

The private key corresponding to the public key given in 10.1 is given in section 10.3
but also here the relation with the public key is implicit and should better be made explicit.
The OpenSSL repository contains this private key at
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.privkey.pem

Normally, the issuance of ee-ed25519 would be easy to detect by the issuer/authority key ID of the cert,
but due to the malformedness that is the very issue being discussed in this errata entry, the AKID is missing.

I object the suggested trivial 'solution' to remove the word "PKIX" from the description
because this does not really cure the form of the certificate.
Moreover I see not much sense to have bad examples of certs in RFCs and other standards
unless they serve the purpose of explicitly giving as negative example for some good reason.
Here, instead, the purpose of the example clearly is to illustrate good use of an X25519 public key,
and this should be done in a positive, standards-compliant way, which in this case means RFC 5280 / PKIX conformance.

- David


On 05.08.20 01:19, Benjamin Kaduk wrote:
Adding LAMPS.

My confidence level here is not terribly high, since there is no
certificate presented with the public key whose private key signed the
X25519 certificate in question and there is some possibility of a different
edge case that allows this behavior.

That said, it seems like the smallest possible change would be to just
remove the word "PKIX" from the description of the certificate in question.

-Ben

On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote:

The following errata report has been submitted for RFC8410,
"Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6229

--------------------------------------
Type: Technical
Reported by: David von Oheimb <David.von.Oheimb@siemens.com>

Section: 10.2

Original Text

An example of a self-issued PKIX certificate using Ed25519 to sign an
X25519 public key would be

Corrected Text
--------------


Notes
-----
The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing).
It includes a subjectKeyIdentifier but not an authorityKeyIdentifier.

For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present.

Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate.
Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8410 (draft-ietf-curdle-pkix-10)
--------------------------------------
Title               : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
Publication Date    : August 2018
Author(s)           : S. Josefsson, J. Schaad
Category            : PROPOSED STANDARD
Source              : CURves, Deprecating and a Little more Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG
--------------89B6A1855210741988972B08-- From nobody Sat Aug 8 07:22:55 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7663A0915; Sat, 8 Aug 2020 07:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ptwAvd74NeRx; Sat, 8 Aug 2020 07:22:44 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64BF3A0912; Sat, 8 Aug 2020 07:22:43 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 078EMPUg018201 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Aug 2020 16:22:25 +0200 Received: from [139.22.34.45] ([139.22.34.45]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 078EMO0O025955; Sat, 8 Aug 2020 16:22:24 +0200 From: David von Oheimb To: Benjamin Kaduk , RFC Errata System Cc: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, daniel.migault@ericsson.com, rsalz@akamai.com, curdle@ietf.org, spasm@ietf.org References: <20200712154032.8DD22F40745@rfc-editor.org> <20200804231921.GW92412@kduck.mit.edu> <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com> Message-ID: <99da805d-0724-f745-629c-316c9d7a153e@siemens.com> Date: Sat, 8 Aug 2020 16:22:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com> Content-Type: multipart/alternative; boundary="------------5608F70DD90621469CC91297" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC8410 (6229) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 08 Aug 2020 14:22:49 -0000 This is a multi-part message in MIME format. --------------5608F70DD90621469CC91297 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit To make things more constructive, I suggest here a replacement for the non-conforming cert. It has basically the same contents as the original one, but in addition a suitable AKID extension. Certificate:     Data:         Version: 3 (0x2)         Serial Number:             0d:b3:b2:03:05:cd:67:9a:c3:db:8f:09:0e:42:7e:ec:09:e5:3d:44         Signature Algorithm: ED25519         Issuer: CN = IETF Test Demo         Validity             Not Before: Aug  8 14:18:35 2020 GMT             Not After : Dec 31 14:18:35 2040 GMT         Subject: CN = IETF Test Demo         Subject Public Key Info:             Public Key Algorithm: X25519                 X25519 Public-Key:                 pub:                     85:20:f0:09:89:30:a7:54:74:8b:7d:dc:b4:3e:f7:                     5a:0d:bf:3a:0d:26:38:1a:f4:eb:a4:a9:8e:aa:9b:                     4e:6a         X509v3 extensions:             X509v3 Basic Constraints:                 CA:FALSE             X509v3 Key Usage:                 Key Agreement             X509v3 Subject Key Identifier:                 CA:9A:B8:EB:0C:9B:BD:CC:73:2C:15:F8:7B:0A:0C:F0:78:B9:CC:04             X509v3 Authority Key Identifier:                 A2:8C:C1:F8:6E:59:60:D3:E0:3A:E7:5C:96:2C:97:A8:D4:48:29:3C     Signature Algorithm: ED25519     Signature Value:         4b:6a:01:60:ec:9b:c1:d4:b1:82:3c:7b:7e:7d:ca:87:51:52:         db:0b:8c:a6:6d:53:89:d8:86:e9:67:39:a0:8b:c4:0d:fa:8c:         c5:91:c6:9b:e1:6f:a1:51:ad:59:87:fb:c1:21:69:d4:10:9f:         c4:ee:de:25:57:bb:6b:af:35:06 -----BEGIN CERTIFICATE----- MIIBTjCCAQCgAwIBAgIUDbOyAwXNZ5rD248JDkJ+7AnlPUQwBQYDK2VwMBkxFzAV BgNVBAMMDklFVEYgVGVzdCBEZW1vMB4XDTIwMDgwODE0MTgzNVoXDTQwMTIzMTE0 MTgzNVowGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wKjAFBgMrZW4DIQCFIPAJ iTCnVHSLfdy0PvdaDb86DSY4GvTrpKmOqptOaqNaMFgwCQYDVR0TBAIwADALBgNV HQ8EBAMCAwgwHQYDVR0OBBYEFMqauOsMm73McywV+HsKDPB4ucwEMB8GA1UdIwQY MBaAFKKMwfhuWWDT4DrnXJYsl6jUSCk8MAUGAytlcANBAEtqAWDsm8HUsYI8e359 yodRUtsLjKZtU4nYhulnOaCLxA36jMWRxpvhb6FRrVmH+8EhadQQn8Tu3iVXu2uv NQY= -----END CERTIFICATE----- On 08.08.20 15:05, David von Oheimb wrote: > > Thanks Ben for your comment. > > Unfortunately I cannot find online the whole tread of this discussion, > and I can neither find how to join the LAMPS mailing list, where there > might already be further responses. > Hope that nevertheless I can contribute to the discussion this way by > email and will receive any further responses. > > The cert in question is part of the OpenSSL repository at > https://github.com/openssl/openssl/blob/master/test/certs/ee-ed25519.pem > > To answer first your indirect question which private key signed this cert: > > As I found during the discussion on a somewhat related OpenSSL issue: > https://github.com/openssl/openssl/issues/1418#issuecomment-448204709 > > this cert has been signed by the private key belonging to > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pem > so that cert is the issuer cert of the cert in question, ee-ed25519.pem. > BTW, it would be less confusing if the cert file had been named > ee-x25519.pem instead. > > This issuing relation can be verified using the following OpenSSL command: > > apps/openssl verify -trusted test/certs/root-ed25519.pem > test/certs/ee-ed25519.pem > > RFC 8410 sections 10.1 and 10.2 > (https://tools.ietf.org/html/rfc8410#section-10.1) > do not clearly state this issuing relation with the public key given > in section 10.1, > which in my view is a further thing to be improved. > The OpenSSL repository contains this public key at > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pubkey.pem > > The private key corresponding to the public key given in 10.1 is given > in section 10.3 > but also here the relation with the public key is implicit and should > better be made explicit. > The OpenSSL repository contains this private key at > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.privkey.pem > > Normally, the issuance of ee-ed25519 would be easy to detect by the > issuer/authority key ID of the cert, > but due to the malformedness that is the very issue being discussed in > this errata entry, the AKID is missing. > > I object the suggested trivial 'solution' to remove the word "PKIX" > from the description > because this does not really cure the form of the certificate. > Moreover I see not much sense to have bad examples of certs in RFCs > and other standards > unless they serve the purpose of explicitly giving as negative example > for some good reason. > Here, instead, the purpose of the example clearly is to illustrate > good use of an X25519 public key, > and this should be done in a positive, standards-compliant way, which > in this case means RFC 5280 / PKIX conformance. > > - David > > > On 05.08.20 01:19, Benjamin Kaduk wrote: >> Adding LAMPS. >> >> My confidence level here is not terribly high, since there is no >> certificate presented with the public key whose private key signed the >> X25519 certificate in question and there is some possibility of a different >> edge case that allows this behavior. >> >> That said, it seems like the smallest possible change would be to just >> remove the word "PKIX" from the description of the certificate in question. >> >> -Ben >> >> On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote: >>> The following errata report has been submitted for RFC8410, >>> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6229 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: David von Oheimb >>> >>> Section: 10.2 >>> >>> Original Text >>> An example of a self-issued PKIX certificate using Ed25519 to sign an >>> X25519 public key would be >>> >>> Corrected Text >>> -------------- >>> >>> >>> Notes >>> ----- >>> The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing). >>> It includes a subjectKeyIdentifier but not an authorityKeyIdentifier. >>> >>> For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present. >>> >>> Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate. >>> Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition). >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC8410 (draft-ietf-curdle-pkix-10) >>> -------------------------------------- >>> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure >>> Publication Date : August 2018 >>> Author(s) : S. Josefsson, J. Schaad >>> Category : PROPOSED STANDARD >>> Source : CURves, Deprecating and a Little more Encryption >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG --------------5608F70DD90621469CC91297 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To make things more constructive, I suggest here a replacement for the non-conforming cert.
It has basically the same contents as the original one, but in addition a suitable AKID extension.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0d:b3:b2:03:05:cd:67:9a:c3:db:8f:09:0e:42:7e:ec:09:e5:3d:44
        Signature Algorithm: ED25519
        Issuer: CN = IETF Test Demo
        Validity
            Not Before: Aug  8 14:18:35 2020 GMT
            Not After : Dec 31 14:18:35 2040 GMT
        Subject: CN = IETF Test Demo
        Subject Public Key Info:
            Public Key Algorithm: X25519
                X25519 Public-Key:
                pub:
                    85:20:f0:09:89:30:a7:54:74:8b:7d:dc:b4:3e:f7:
                    5a:0d:bf:3a:0d:26:38:1a:f4:eb:a4:a9:8e:aa:9b:
                    4e:6a
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Key Agreement
            X509v3 Subject Key Identifier:
                CA:9A:B8:EB:0C:9B:BD:CC:73:2C:15:F8:7B:0A:0C:F0:78:B9:CC:04
            X509v3 Authority Key Identifier:
                A2:8C:C1:F8:6E:59:60:D3:E0:3A:E7:5C:96:2C:97:A8:D4:48:29:3C
    Signature Algorithm: ED25519
    Signature Value:
        4b:6a:01:60:ec:9b:c1:d4:b1:82:3c:7b:7e:7d:ca:87:51:52:
        db:0b:8c:a6:6d:53:89:d8:86:e9:67:39:a0:8b:c4:0d:fa:8c:
        c5:91:c6:9b:e1:6f:a1:51:ad:59:87:fb:c1:21:69:d4:10:9f:
        c4:ee:de:25:57:bb:6b:af:35:06


-----BEGIN CERTIFICATE-----
MIIBTjCCAQCgAwIBAgIUDbOyAwXNZ5rD248JDkJ+7AnlPUQwBQYDK2VwMBkxFzAV
BgNVBAMMDklFVEYgVGVzdCBEZW1vMB4XDTIwMDgwODE0MTgzNVoXDTQwMTIzMTE0
MTgzNVowGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wKjAFBgMrZW4DIQCFIPAJ
iTCnVHSLfdy0PvdaDb86DSY4GvTrpKmOqptOaqNaMFgwCQYDVR0TBAIwADALBgNV
HQ8EBAMCAwgwHQYDVR0OBBYEFMqauOsMm73McywV+HsKDPB4ucwEMB8GA1UdIwQY
MBaAFKKMwfhuWWDT4DrnXJYsl6jUSCk8MAUGAytlcANBAEtqAWDsm8HUsYI8e359
yodRUtsLjKZtU4nYhulnOaCLxA36jMWRxpvhb6FRrVmH+8EhadQQn8Tu3iVXu2uv
NQY=
-----END CERTIFICATE-----


On 08.08.20 15:05, David von Oheimb wrote:

Thanks Ben for your comment.

Unfortunately I cannot find online the whole tread of this discussion,
and I can neither find how to join the LAMPS mailing list, where there might already be further responses.
Hope that nevertheless I can contribute to the discussion this way by email and will receive any further responses.

The cert in question is part of the OpenSSL repository at
https://github.com/openssl/openssl/blob/master/test/certs/ee-ed25519.pem

To answer first your indirect question which private key signed this cert:

As I found during the discussion on a somewhat related OpenSSL issue:
https://github.com/openssl/openssl/issues/1418#issuecomment-448204709

this cert has been signed by the private key belonging to
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pem
so that cert is the issuer cert of the cert in question, ee-ed25519.pem.
BTW, it would be less confusing if the cert file had been named ee-x25519.pem instead.

This issuing relation can be verified using the following OpenSSL command:

apps/openssl verify -trusted test/certs/root-ed25519.pem test/certs/ee-ed25519.pem

RFC 8410 sections 10.1 and 10.2 (https://tools.ietf.org/html/rfc8410#section-10.1)
do not clearly state this issuing relation with the public key given in section 10.1,
which in my view is a further thing to be improved.
The OpenSSL repository contains this public key at
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pubkey.pem

The private key corresponding to the public key given in 10.1 is given in section 10.3
but also here the relation with the public key is implicit and should better be made explicit.
The OpenSSL repository contains this private key at
https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.privkey.pem

Normally, the issuance of ee-ed25519 would be easy to detect by the issuer/authority key ID of the cert,
but due to the malformedness that is the very issue being discussed in this errata entry, the AKID is missing.

I object the suggested trivial 'solution' to remove the word "PKIX" from the description
because this does not really cure the form of the certificate.
Moreover I see not much sense to have bad examples of certs in RFCs and other standards
unless they serve the purpose of explicitly giving as negative example for some good reason.
Here, instead, the purpose of the example clearly is to illustrate good use of an X25519 public key,
and this should be done in a positive, standards-compliant way, which in this case means RFC 5280 / PKIX conformance.

- David


On 05.08.20 01:19, Benjamin Kaduk wrote:
Adding LAMPS.

My confidence level here is not terribly high, since there is no
certificate presented with the public key whose private key signed the
X25519 certificate in question and there is some possibility of a different
edge case that allows this behavior.

That said, it seems like the smallest possible change would be to just
remove the word "PKIX" from the description of the certificate in question.

-Ben

On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote:

The following errata report has been submitted for RFC8410,
"Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6229

--------------------------------------
Type: Technical
Reported by: David von Oheimb <David.von.Oheimb@siemens.com>

Section: 10.2

Original Text

An example of a self-issued PKIX certificate using Ed25519 to sign an
X25519 public key would be

Corrected Text
--------------


Notes
-----
The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing).
It includes a subjectKeyIdentifier but not an authorityKeyIdentifier.

For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present.

Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate.
Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8410 (draft-ietf-curdle-pkix-10)
--------------------------------------
Title               : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
Publication Date    : August 2018
Author(s)           : S. Josefsson, J. Schaad
Category            : PROPOSED STANDARD
Source              : CURves, Deprecating and a Little more Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG
--------------5608F70DD90621469CC91297-- From nobody Sun Aug 9 23:40:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C13A141A for ; Sun, 9 Aug 2020 23:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 VhpUmhZFOqnp for ; Sun, 9 Aug 2020 23:40:35 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150043.outbound.protection.outlook.com [40.107.15.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294BD3A0E8B for ; Sun, 9 Aug 2020 23:40:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bJhymRhZLlMU+Kqo3Khm4MO6h4MmswvcrXT+AM4YK/JM2zlmV0GUP5xfb64BxwgusGwD6AdI23ggqq7JmX8EyuIutpWRDYf4EU7YeXl52gIPNdUyuth83FxEuJit8LVztfP5xUizXMamyh+lMhEht7eGA9B6P82CsX4k5vjFNlhwCU+fNuYP7r37fPgsQqRkf6rkqb7QWGnxLCk/ZbnCFu/SiroozdKTMW6um+o88+VR1LGMCqFgdPw/V5pqB0tISTRoC0q7Z2kB1jDpRv9iezxDgoK0PmrqPo61l9iQlyAWUJa1sw6OL+m2J2ffsuvxs4F97SZOvla3fdof4B/DZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=at0GafVe6URTGXpFtK8DrAqGYmiN4wlDUBsEJtN68cE=; b=WXFVNfuP+1cW/y0LyZvRhtJoARgnWmeWuUknQzluOtYXyt4d6+0ahjPE035wwD2dsevkozHRVFNCl6whK/3+QHXiC8UvY+C4ULGC/DIlmK/2/7T16V6rx9v5vr1whC2RifHFuk29m1tSxt8IQYE8jES18DFYM5rt52DmBWSH+r0Dm8QptBTE+LAIZNeDr2Tl0W+mw11pUtL8Bimhs+eC4e/5aa3ZsDciSsp44lkeaTL/Zn4tDFS1hWxdCI7yCEDXeheiy7rhDmVxhz1PBNAmDbKezILp98qoA0SiEnHeu6OSxWynJn2x4JLwE4l76apfgpWN+IVypfLrNv5hkezbLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=at0GafVe6URTGXpFtK8DrAqGYmiN4wlDUBsEJtN68cE=; b=CSeU+lZa4EH82nCGPZzzYPVBv0dR5+LVPixwXprqgtW6RD+hHwpl+OBaNevP76bSdppMABo0/raYooaZlo5tw/lWHM2eFm3BE/9YONQtws1vrEZt6G2w2xYRQt+b6QyALT7VSXAmirYsoCG6gn+Y5rykXqlYDzk/2goirKz9sA4= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4277.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fb::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Mon, 10 Aug 2020 06:40:32 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a163:6576:dbad:8cb6%5]) with mapi id 15.20.3261.024; Mon, 10 Aug 2020 06:40:32 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" Thread-Topic: dtaft-ietf-lamps-cmp-updates add section to introduce id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate Thread-Index: AdZu37UrzuTLe9cMQ0eLmTYUQSgPxQ== Content-Class: Date: Mon, 10 Aug 2020 06:40:32 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-10T06:40:30Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=214113ab-a5ef-46cb-ae19-1ce5d4eb75f0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.147] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4c6b253a-904d-4ab8-3972-08d83cf847cd x-ms-traffictypediagnostic: AM9PR10MB4277: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yPkLbQE8gYbmzQDRqB/ix6HQUan8ByvQO0NLD1IzIaVb5pWJNu98Q0J+esi1OXd4yttUn7lRJLjiq0Mz+QswAp5P7nfeCW2fjkvyGxu5r0/tZcXUbPV9oUCih38L6rdLID5ach127RP3qFdMo13M/mrPKulFoxG88CHcbJlKmqW05ylmn/df/iAL0ps2bFzHiAqDb3JrmyzsC0+yMeY2pLeZj2HmrQx0kjLedZM0qyFUWJjCgf+//reUs4oBHH2rz9505eDW+YjC5Qxat1BdOUiesQglBrrwlzKl9PQQ9Pg1q+zPB8nV9MvmfqEFIJ4C0ZAKuL1cd/GMoSVSqQtWPg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(4636009)(346002)(396003)(136003)(366004)(376002)(39860400002)(76116006)(66946007)(66446008)(66476007)(66556008)(64756008)(15650500001)(52536014)(83380400001)(86362001)(6916009)(5660300002)(9686003)(71200400001)(2906002)(55016002)(33656002)(8676002)(8936002)(186003)(55236004)(316002)(6506007)(26005)(7696005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: u0E+6g9DbigatMrzzbuT9dtssJQynzuyY4GdgRDo96w5vpw8LH6o7iUf1A6xGkU+1dhTLK4zR2k/sSo0rPvLGAZcN1DX/jJ2gb4wVKFwQ8W2usYP3lqSdAdmDaM5rsizWxfZCmwrGiZCPVHLhhqS+1KD/wmVp61Pwo4gyTWDHORfqCyuEvsqa24E5koI8bqeZ3jEetlliasCYa9YlDv/zI66IGZGAoqgb42/+JeRPwx2CQHvuB8ui2cyAiHriRM5DVt68GjCtTck3+SL6teMYFNXpqDb+9HpX6P/wXOzqqoTTnT1ztQqW/324WFfCAmYt2me9YgTFyU99rEYLdBrwwR7Td0b5Q3kD6N9yOkmWK5exb4peUVdKzLsfdovbVZKsK98SZy2favG8+26qTy4rZy5LBLvLizbT9vBynXXePyg7oux0uBdD7kNCMYNlbnmUUGZ6t9Acv+GSEWv4JIVUE3jYdu+oIV/Q130BaJz3/Snt9b21nVpvgzzyuLxcgzVgrKAVd5Elnz4jVCiz1rAvzk8wLAOBfcM0/ZCtJzAXvjdjNL5v9raSSTCsBqi6yzfsxEuZQWgLW857Zf+8hsUL9eZ1y3cGV7X+pK5h4+UB760iSqk5DGCNTI2jWjkfjZeR8kCOGcMuBauXh0Ii/SoUA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4c6b253a-904d-4ab8-3972-08d83cf847cd X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 06:40:32.5374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KRfwBOgJ+e5ygGkcK2iYngohfNsgjmPIwRCmJelmh8f3bHnbGyZLHcqdJAYnWaml7tWUvxztuyeS1k+A43jSlRWBhf7odO9mWNAuyO5/bJ4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4277 Archived-At: Subject: [lamps] dtaft-ietf-lamps-cmp-updates add section to introduce id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 10 Aug 2020 06:40:37 -0000 When working on the next update of the Lightweight CMP Profile, I was discu= ssing the advantages of introducing the new OIDs for the support messages (= id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate) together w= ith their ASN.1 syntax already in CMP Updates. I see two advantages: 1) The IDs can also be used outside of the use of the Lightweight CMP Profi= le 2) All changes and additions to the CMP ASN.1 module would be performed in = one document only. The Lightweight CMP Profile would not need an additional= ASN.1 module. What is the opinion of the group? This would be the additional section for CMP Updates and the respective ASN= .1 Syntax of the new types. 2.7. Update Section 5.3.19. - PKI General Message Content Section 5.3.19 of RFC 4210 [RFC4210] describes examples InfoTypeAndValue to= be used in general messages content. This document adds three additional s= ub-section to introduce new IDs id-it-caCerts, id-it-rootCaKeyUpdate, and i= d-it-certReqTemplate to the support messages as defined in [I-D.ietf-lamps-= lightweight-cmp-profile] Section 4.4. Add these new sub-sections at the end of this section with the following te= xt. 2.3.19.14 CA Certificates This MAY be used by the client to get the latest CA intermediate and issuin= g CA certificates. GenMsg: {id-it 17}, < absent > GenRep: {id-it 17}, CaCerts | < absent > 5.3.19.15. Root CA Certificates Update This MAY be used by the client to get an update of an existing root CA Cert= ificate. GenMsg: {id-it 18}, < absent > GenRep: {id-it 18}, RootCaKeyUpdate | < absent > Note: In contrast to CAKeyUpdAnnContent, this type offers omitting newWithO= ld and oldWithNew in the GenRep message, depending on the needs of the EE. 5.3.19.16. Certificate Request Template This MAY be used by the client to get a template with parameters for a futu= re certificate request operation. GenMsg: {id-it 19}, < absent > GenRep: {id-it 19}, CertReqTemplateValue | < absent > Addition to ASN.1 module in Appendix A: id-it-caCerts OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 17} CaCerts ::=3D SEQUENCE OF CMPCertificate id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 18} RootCaKeyUpdate ::=3D SEQUENCE { newWithNew CMPCertificate newWithOld [0] CMPCertificate OPTIONAL, oldWithNew [1] CMPCertificate OPTIONAL } id-it-certReqTemplate OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 19} CertReqTemplateValue ::=3D SEQUENCE { certTemplate CertTemplate, rsaKeyLen INTEGER OPTIONAL } Hendrik From nobody Mon Aug 10 12:20:37 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA483A0B8A; Mon, 10 Aug 2020 12:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc7030est-clarify@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159708723193.29885.12352713174529389821@ietfa.amsl.com> Date: Mon, 10 Aug 2020 12:20:31 -0700 Archived-At: Subject: [lamps] Robert Wilton's No Objection on draft-ietf-lamps-rfc7030est-clarify-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 10 Aug 2020 19:20:32 -0000 Robert Wilton has entered the following ballot position for draft-ietf-lamps-rfc7030est-clarify-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document, I found it easy to read. No concerns, just some minor nits: 1. Introduction This document deals with errata numbers [errata4384], [errata5107], [errata5108], and [errata5904]. This document deals explicitely with [errata5107] and [errata5904] in Section 3. [errata5108] is dealt with in section Section 5. [errata4384] is closed by correcting the ASN.1 Module in Section 4. Typo on explicitly, but I would propose merge these three paragraphs into one: E.g. This document deals with [errata5107] and [errata5904] in Section 3. [errata5108] is dealt with in Section 5. [errata4384] is closed by correcting the ASN.1 Module in Section 4. There are also some paragraph indentation issues that could be tweaked in sections 3.2.3 & 3.2.4, or if the tooling is tricky to fix this then you could leave a note to flag it for the RFC editor. 7. Security Considerations applies also => also apply From nobody Mon Aug 10 12:26:10 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E09F3A0C36; Mon, 10 Aug 2020 12:26:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect.all@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708756719.15053.15537532147789441272@ietfa.amsl.com> Reply-To: Robert Sparks Date: Mon, 10 Aug 2020 12:26:07 -0700 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-cms-update-alg-id-protect-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 10 Aug 2020 19:26:07 -0000 Reviewer: Robert Sparks Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication as Proposed Standard RFC. >From the abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers in signed- > data and authenticated-data content types are adequately protected. I sent minor nits directly to the editor. From nobody Tue Aug 11 10:53:11 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224343A0799; Tue, 11 Aug 2020 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kWJcDDThMffh; Tue, 11 Aug 2020 10:53:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D213A0788; Tue, 11 Aug 2020 10:53:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A36D3389AF; Tue, 11 Aug 2020 13:32:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KF1lxaQCzwP5; Tue, 11 Aug 2020 13:32:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C62EF389AC; Tue, 11 Aug 2020 13:32:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56A97B3; Tue, 11 Aug 2020 13:52:57 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, draft-ietf-lamps-rfc7030est-clarify@ietf.org In-Reply-To: <159676713899.29487.17107197903809737059@ietfa.amsl.com> References: <159676713899.29487.17107197903809737059@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2020 13:52:57 -0400 Message-ID: <27148.1597168377@localhost> Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc7030est-clarify-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Aug 2020 17:53:06 -0000 Martin Duke asks that we replace RFC2616 with something newer. The document actually references 2616, 7230 and 7231. RFC2616 would have been current at the time RFC7030 was published, and some thing are more clearly articulated in 2616, but never-the-less ignored by RFC7030. RFC7231 is less clear. I also took the edits from Robert Wilton. In the replace/with replacements, I had not made [RFCXXXX] an actual reference as I had used code blocks (artwork), where references are not ex= panded. I am uncertain, XML-stylistically what to do here. I don't think that the "Replace:" should result in actual references, but the with: block should probably results in a new reference to the relevant documents. I have made sure, I think that I have all the references. Two were missing= . Benjamin Kaduk via Datatracker wrote: > The reference to RFC 5212 (Requirements for GMPLS-Based Multi-Region= and > Multi-Layer Networks (MRN/MLN)) in the ASN.1 module needs to be repl= aced > by 5912 (New ASN.1 Modules for the Public Key Infrastructure Using X= .509 > (PKIX)). Note that the last-call announcement claimed (properly, > according to the state of the document) that there is a downref to 5= 212, > but 5912 is already in the registry so we should not need to re-run = the > IETF LC. Oops. That's definitely a typo, I think. > It seems like we might want to move EIDs 4384, 5904, 5107, and 5108 = out > of status "Reported" (i.e., to "Hold for Document Update") before > publishing this document. okay, I leave this to a responsible AD to do (Roman, I think). > Abstract > This document updates RFC7030: Enrollment over Secure Transport (EST= ) > to resolve some errata that were reported, and which has proven to > cause interoperability issues when RFC7030 was extended. > nit: singular/plural mismatch "has proven"/"errata that were reporte= d". fixed. > Section 4 > Responses to attribute request messages MUST be encoded as the > content-type of "application/csrattrs", and are to be "base64" > [RFC2045] encoded. The syntax for application/csrattrs body is as > Should this be 4648 (not 2045)? The original document that said to base64 encode them was RFC2045 (MIME) The current base64 spec is RFC4648. I take your point that here, it makes sense to reference the base64 spec. > Section 5.2 > Replace: > If the content-type is not set, the response data MUST be a > plaintext human-readable error message. > with: > If the content-type is not set, the response data must be a > plaintext human-readable error message. > Why do we lose the 2119 "MUST" here? We kept it in Section 5.1. fixed. Also noted by Erik Kline. > Section 10.1 > RFC 8179 is listed but does not seem to be cited anywhere. typo for RFC8174, I think. Removed. > Section 10.2 > One could perhaps argue that RFC 2985 should be normative, but it > doesn't seem very important. The text and reference repeat what RFC7030 had. > Appendix A > id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::=3D { iso(1) member-body= (2) > us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 } > Pedantically, RFC 7030 spells it as "{id-aa 54}" but I'm not actuall= y > complaining about doing it this way. okay. https://github.com/mcr/ietf-lamps-rfc7030est-clarifications/commit/eee1df9= 25b6d8d34673a6f891ee8111b7e1f2356 -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Tue Aug 11 10:54:27 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF043A0544; Tue, 11 Aug 2020 10:54:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159716846436.758.8898617996140653038@ietfa.amsl.com> Date: Tue, 11 Aug 2020 10:54:24 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Aug 2020 17:54:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-10.txt Pages : 14 Date : 2020-08-11 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that were reported, and which have proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that were present. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-10 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 11 13:06:20 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D873A0C67 for ; Tue, 11 Aug 2020 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lksWbBPj-p1l for ; Tue, 11 Aug 2020 13:06:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448B63A0C7C for ; Tue, 11 Aug 2020 13:06:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 969FF389AF for ; Tue, 11 Aug 2020 15:45:29 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iOtC8UCCpFeA for ; Tue, 11 Aug 2020 15:45:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3DA0C389A0 for ; Tue, 11 Aug 2020 15:45:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D77CF430 for ; Tue, 11 Aug 2020 16:06:12 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org In-Reply-To: <159716846436.758.8898617996140653038@ietfa.amsl.com> References: <159716846436.758.8898617996140653038@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Aug 2020 20:06:19 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. > Title : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 ... > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-10 These are edits from IESG reviews. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8y+jQACgkQgItw+93Q 3WVIJAf/QodO19b7azmfZc5t/dVqj4ps5WdZ9m1LnALAFupR8dMjGMz7d8kNVe0F mXSRGhk49nYlhgML8RuTsrhZJsn++8693fSwmgDIyks2pquuK4KqUIXlNI/PZ4Vi 9P7CDmYI4UDBR5N9RSJt6W2zJBFxug9S1TPItWSgWNVHUkxiwZ5QD/F/xPtFvvBd j7xHCBhJWnnQG/6DKTkWI1k+ENZDgavbmwYihcMu4UjR/hVTDklT/S2/wLX7g2rN 0QZzLvyfeNiz4yeil7c/OsFm5ejVA4k1f892ZxrOJZxicGf4HFmysWXSOEgvUWS0 Ckic9iKb6glnYu18OmTFKMjs5VcgGA== =qd3y -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 23:13:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9993A1068 for ; Tue, 11 Aug 2020 23:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kzdZIn8BrG1b for ; Tue, 11 Aug 2020 23:13:43 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979D13A1066 for ; Tue, 11 Aug 2020 23:13:43 -0700 (PDT) Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id DBE124F000A for ; Wed, 12 Aug 2020 08:13:41 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (demchdc89xa.ad011.siemens.net [139.25.226.103]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id D8026153425C3 for ; Wed, 12 Aug 2020 08:13:41 +0200 (CEST) Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by DEMCHDC89XA.ad011.siemens.net (139.25.226.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 12 Aug 2020 08:13:41 +0200 Received: from DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) by DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) with mapi id 15.01.2044.004; Wed, 12 Aug 2020 08:13:41 +0200 From: "Fries, Steffen" To: "Brockhaus, Hendrik" , "spasm@ietf.org" Thread-Topic: dtaft-ietf-lamps-cmp-updates add section to introduce id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate Thread-Index: AdZu37UrzuTLe9cMQ0eLmTYUQSgPxQBjvhng Date: Wed, 12 Aug 2020 06:13:41 +0000 Message-ID: <746e879ba7d948c58f20f1c40a546025@siemens.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-10T06:40:30Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=214113ab-a5ef-46cb-ae19-1ce5d4eb75f0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.67] x-tm-snts-smtp: 69DA231EA1B3ECD86585D16E1113FE1384EFC8AEAC8E10636700B9F8593EADCE2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] dtaft-ietf-lamps-cmp-updates add section to introduce id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 12 Aug 2020 06:13:46 -0000 Hi Hendrik, > From: Spasm On Behalf Of Brockhaus, Hendrik > Sent: Montag, 10. August 2020 08:41 > Subject: [lamps] dtaft-ietf-lamps-cmp-updates add section to introduce id= -it- > caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate >=20 > When working on the next update of the Lightweight CMP Profile, I was > discussing the advantages of introducing the new OIDs for the support > messages (id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate= ) > together with their ASN.1 syntax already in CMP Updates. > I see two advantages: > 1) The IDs can also be used outside of the use of the Lightweight CMP Pro= file > 2) All changes and additions to the CMP ASN.1 module would be performed > in one document only. The Lightweight CMP Profile would not need an > additional ASN.1 module. >=20 > What is the opinion of the group? >From a Lightweight CMP perspective I would support the takeover into the CM= P updates document. From my understanding the change is independent of the = Lightweight CMP profile and could be usable for other documents, that would= like to refer to CMP directly. Also as the Lightweight Profile is intended= to reduce the options in CMP. Introducing new OIDs and respective ASN.1 Mo= dules actually goes beyond the profiling from my point of view. Therefore, = I (also as co-author of Lightweight CMP) would be in favor of moving it to = the CMP updates document .=20 Best regards Steffen >=20 > This would be the additional section for CMP Updates and the respective > ASN.1 Syntax of the new types. >=20 > 2.7. Update Section 5.3.19. - PKI General Message Content >=20 > Section 5.3.19 of RFC 4210 [RFC4210] describes examples InfoTypeAndValue > to be used in general messages content. This document adds three > additional sub-section to introduce new IDs id-it-caCerts, id-it- > rootCaKeyUpdate, and id-it-certReqTemplate to the support messages as > defined in [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. > Add these new sub-sections at the end of this section with the following > text. >=20 > 2.3.19.14 CA Certificates >=20 > This MAY be used by the client to get the latest CA intermediate and issu= ing > CA certificates. >=20 > GenMsg: {id-it 17}, < absent > > GenRep: {id-it 17}, CaCerts | < absent > >=20 > 5.3.19.15. Root CA Certificates Update >=20 > This MAY be used by the client to get an update of an existing root CA > Certificate. >=20 > GenMsg: {id-it 18}, < absent > > GenRep: {id-it 18}, RootCaKeyUpdate | < absent > >=20 > Note: In contrast to CAKeyUpdAnnContent, this type offers omitting > newWithOld and oldWithNew in the GenRep message, depending on the > needs of the EE. >=20 > 5.3.19.16. Certificate Request Template >=20 > This MAY be used by the client to get a template with parameters for a > future certificate request operation. >=20 > GenMsg: {id-it 19}, < absent > > GenRep: {id-it 19}, CertReqTemplateValue | < absent > >=20 >=20 >=20 > Addition to ASN.1 module in Appendix A: >=20 > id-it-caCerts OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 17} > CaCerts ::=3D SEQUENCE OF CMPCertificate >=20 > id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 18} > RootCaKeyUpdate ::=3D SEQUENCE { > newWithNew CMPCertificate > newWithOld [0] CMPCertificate OPTIONAL, > oldWithNew [1] CMPCertificate OPTIONAL > } >=20 > id-it-certReqTemplate OBJECT IDENTIFIER ::=3D {1 3 6 1 5 5 7 4 19} > CertReqTemplateValue ::=3D SEQUENCE { > certTemplate CertTemplate, > rsaKeyLen INTEGER OPTIONAL > } >=20 > Hendrik >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Aug 12 16:10:21 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E93A0CB0; Wed, 12 Aug 2020 16:10:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc7030est-clarify@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <159727381618.2979.15559732192457180389@ietfa.amsl.com> Date: Wed, 12 Aug 2020 16:10:16 -0700 Archived-At: Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc7030est-clarify-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 12 Aug 2020 23:10:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-rfc7030est-clarify-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I, too, wonder why there’s a need to still cite RFC 2616 here. From nobody Wed Aug 12 17:39:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536033A1515; Wed, 12 Aug 2020 17:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=B5oSwsXI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RgqgIDDF 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 wjHFH1aMKJLu; Wed, 12 Aug 2020 17:39:23 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B8C3A1514; Wed, 12 Aug 2020 17:39:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 880731298; Wed, 12 Aug 2020 20:39:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 12 Aug 2020 20:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=/zKeoYbaFns0kmVSckCEgmW nguqcRLGMHICJTePTX0c=; b=B5oSwsXI3fPU3LhJk4xMeMlFMwHSDSh6UdT2Ovp cL1iBTTVbymxZuGmE1mrttTijcYGfV2mcdFkyGmHtqi2vTLTwUZgm5wOaBrt1OaT 4QbbDkUia6wHrQJZoNfGELE88ZSVXPnAlPDT/mMI4He1DmqH93vq3woaB6lDjEAl 5hazKisurBVwn2bTxny4P8NrJQAozctpf9RelI+8pzT4MvWcU1jaYSYiEejRj6jh Mz1UWo8eY0U9nykCBlD6AeCqf0mUrRIbvZMwwFxHydPI6DA92FDGXhiT4zhVO0hM 5/oMjHUU/JPdoyY1Xdhm6qYl8tYEgLPEIqLPqXoPidQy2tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=/zKeoY baFns0kmVSckCEgmWnguqcRLGMHICJTePTX0c=; b=RgqgIDDF2bhhcRpYpope0n farUZlVJa03X3MQofh5BLzdV1BfRUu20u5sKSIoqZ/eDNsGNN/vXXmoyBnxqFToL m+NvvaTnhIizWlKj1Kv1Ds99he9wZRaX7G5XGSxahtVM2fUeG+ZWozxEcPMrgezz q5SAYDToiLzEDza9c4cTwq8rNsIkOjMTE1UpN2WKEcp/YaH4Jbs7djE2zwMTiNe2 /jaIRHuQxMLJAzf7hGJnmFPoJmHGrlqTFrkA+tEUphYsfnIQKZD1P5SIV5ml0Pkp 6rcqh0BlKmfYhtvgNj3eTHHlorREDDDrIVXFchBBZpzxYdi3LrnnS8SiqxJgdm7g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleefgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpeelteekheffkeeuuedutedviedutedvtdffheeigeetjeelhfdtteeiffdvudeu teenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrie eknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl ihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.68]) by mail.messagingengine.com (Postfix) with ESMTPA id 756C430600A6; Wed, 12 Aug 2020 20:39:18 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35B6947E-8C15-46CE-ABB4-7B62C7BC0717" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 20:39:17 -0400 In-Reply-To: Cc: Michael Richardson , LAMPS , last-call@ietf.org, IETF Gen-ART , draft-ietf-lamps-rfc7030est-clarify.all@ietf.org To: Ines Robles References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> <17412.1594601797@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [lamps] [Gen-art] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 13 Aug 2020 00:39:26 -0000 --Apple-Mail=_35B6947E-8C15-46CE-ABB4-7B62C7BC0717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ines, thanks for your review. Michael, Russ, thanks for your responses. = I entered a No Objection ballot. Alissa > On Jul 13, 2020, at 2:52 AM, Ines Robles = wrote: >=20 > Hi Michael, >=20 > Yes, that would be great, if possible. >=20 > Thank you, >=20 > Ines >=20 > On Mon, Jul 13, 2020 at 3:56 AM Michael Richardson = > wrote: >=20 > Ines Robles via Datatracker > wrote: > > 2- Introduction: "reports from implementers suggest...." It = would be nice to add > > reference/s here >=20 > Well, I'm not sure how I can add a reference to private emails. > I can ask the implementers to write a public email if that is = intended. > Please advise. >=20 >=20 > -- > Michael Richardson >, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_35B6947E-8C15-46CE-ABB4-7B62C7BC0717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ines,= thanks for your review. Michael, Russ, thanks for your responses. I = entered a No Objection ballot.

Alissa


On Jul = 13, 2020, at 2:52 AM, Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> = wrote:

Hi Michael,

Yes, that would be great, if = possible.

Thank = you,

Ines

On Mon, Jul 13, 2020 at 3:56 AM Michael = Richardson <mcr+ietf@sandelman.ca> wrote:

Ines Robles via Datatracker <noreply@ietf.org> wrote:
    > 2- Introduction: "reports from implementers = suggest...." It would be nice to add
    > reference/s here

Well, I'm not sure how I can add a reference to private emails.
I can ask the implementers to write a public email if that is = intended.
Please advise.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman = Software Works
 -=3D IPv6 IoT consulting =3D-



_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_35B6947E-8C15-46CE-ABB4-7B62C7BC0717-- From nobody Wed Aug 12 21:47:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FDE3A1698; Wed, 12 Aug 2020 21:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Zqz9D3iixkRS; Wed, 12 Aug 2020 21:46:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EDB3A1695; Wed, 12 Aug 2020 21:46:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1F2A0F4071E; Wed, 12 Aug 2020 21:46:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200813044649.1F2A0F4071E@rfc-editor.org> Date: Wed, 12 Aug 2020 21:46:49 -0700 (PDT) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8813_on_Clarifications_for_Elliptic_Curve_?= =?utf-8?q?Cryptography_Subject_Public_Key_Information?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 13 Aug 2020 04:46:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8813 Title: Clarifications for Elliptic Curve Cryptography Subject Public Key Information Author: T. Ito, S. Turner Status: Standards Track Stream: IETF Date: August 2020 Mailbox: tadahiko.ito.public@gmail.com, sean@sn3rd.com Pages: 3 Updates: RFC 5480 I-D Tag: draft-ietf-lamps-5480-ku-clarifications-03.txt URL: https://www.rfc-editor.org/info/rfc8813 DOI: 10.17487/RFC8813 This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 13 11:22:16 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F313A102D; Thu, 13 Aug 2020 11:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PSq_1PYnwHeO; Thu, 13 Aug 2020 11:22:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D753A101C; Thu, 13 Aug 2020 11:22:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 209B9389A4; Thu, 13 Aug 2020 14:01:12 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dbi5sWI7a0lI; Thu, 13 Aug 2020 14:01:11 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D29A389A3; Thu, 13 Aug 2020 14:01:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C01A763E; Thu, 13 Aug 2020 14:21:57 -0400 (EDT) From: Michael Richardson To: Barry Leiba cc: "The IESG" , spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, draft-ietf-lamps-rfc7030est-clarify@ietf.org In-Reply-To: <159727381618.2979.15559732192457180389@ietfa.amsl.com> References: <159727381618.2979.15559732192457180389@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc7030est-clarify-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 13 Aug 2020 18:22:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Barry Leiba via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I, too, wonder why there=E2=80=99s a need to still cite RFC 2616 here. Yes, I agree it is weird. Section 3.1 is why. This is because the text in RFC7230/31 is much less clear about whether CR/LF/spaces are allowed in base64. My recollection was that the base64 text from 2616 is appropriately, just g= one. In order to avoid changes to bits on the wire, we need decoders to be tolerant of whitespace in base64 blocks. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl81hMUACgkQgItw+93Q 3WWABgf/ZqAXFYFtKIX11bkSRYkhPZyqMF8GlxgP25zsjBrJdpi4aaoldR++lVEG ORbQ0FoKoTWA7Jx+B0/cBgZdDt6yqlaaFJ3EP29t0pUSRU/p6SJPhNtUcPbkkieA mq9qbWe/j5vjLTTbsSU+HL1OveQrDM+ruCyE+gMeE7Edu0c79SoNFLRJvPT+Tc3g eljs/x2Cd+2vltMfvZfggxdVU+odzugDfAPh2XnO7IOCZBeEZluawn9cH5qEkcap aOKhK4cVx0MV0Ysd/T9k6csy/0y+KETKtSnM35aN1jnwhYKf8PDV1qPwg2WroNKx 7ULVf+UpKDN97CMyCJrCpRzFxyxBSw== =CaRi -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 14 17:11:32 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8553A0B2C; Fri, 14 Aug 2020 17:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159745027997.20272.7389745817053427225@ietfa.amsl.com> Date: Fri, 14 Aug 2020 17:11:20 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-ocsp-nonce-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 15 Aug 2020 00:11:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : OCSP Nonce Extension Author : Mohit Sahni Filename : draft-ietf-lamps-ocsp-nonce-03.txt Pages : 6 Date : 2020-08-14 Abstract: This document specifies the updated format of the Nonce extension in Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate and the Nonce extension is used in the OCSP request and response messages to avoid replay attacks. This document updates the RFC 6960 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-ocsp-nonce-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-ocsp-nonce-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-ocsp-nonce-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 14 17:18:39 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5B73A0AEB for ; Fri, 14 Aug 2020 17:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hY4R3OdcYDai for ; Fri, 14 Aug 2020 17:18:36 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 B04E93A0AE3 for ; Fri, 14 Aug 2020 17:18:36 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id q14so6467116ilm.2 for ; Fri, 14 Aug 2020 17:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N3uz84w94bLByuUeRTaiY5vvwFPXTp9CW2v0OA2Xfyw=; b=LFx6/A7uqtsG/VUhI5IhAAIahiTOGJDFsFgq+GIboSOU3lwGY+H5TAPfRHNOJya6Mu 8r8GFXp8FRixUi3At4o3f8NylqZAl5SAD8Q6082f7rfBTth+rh4lwoaKfPYwpwZkeoKJ fBGAqxOyBCW5EyXRYid/+SjhxvndENShK5589FykmGsFcIawLKJ6q5c3XXiPQtLpoefY /gERiC1CLFoFBhcPfVu9AsfOeJuv5CTPdwwgDEyR2W0xjFXJVTQ5Ev/RIqWNfWy1xcHq fMJ/y/+hRPxUcK+G0W0H2lg9D9Z3CozXy1geV4EHP+XUg3F8gjDaGF5PA5gEKCqbYFYV UnIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N3uz84w94bLByuUeRTaiY5vvwFPXTp9CW2v0OA2Xfyw=; b=oxWFChAgC0L63NtD6Ws6z/nAzE/+hz62TfoV+h+w9mvLn1O6GDwMFLHBE8qvuHCqYM V4gnmHNhP3m2N70bwWkBwlGzZthHmVikTTAZce3ixuPB7/DgVYQMSQCa8AGvs7pai3d8 jIY9hJRBoQ5PQoZj7P5jPLQ7KlMF2knA8uhtyHRPDb/TQXKplkIRwXae7W6PNeIM8bVX rOrxAfH4nzLvtmxmKf+QmVFjD/FrvvBQHjROk50c3gDNPkPPdwYtKWvl4sYVmzMMBLg3 HgsKz5tMgCfbyjKFjVJD+JLN5dr7zbbDDJpGsrzzdfy8g3S8xrIXKZKMpTqwfPPv1IRN oRew== X-Gm-Message-State: AOAM530EvBQNxLkZEMv644MDRGeruZm+CMMoJkQ7wRMl5TsOcU9Qv0Cl H4OVbre6AAWMqAxmpRXtRMxd1+/CrAnIi/1hJYlPfCuIqxEnQA== X-Google-Smtp-Source: ABdhPJyJdPUdN/Lsrts0S+sJlsZAfUw7ROv+bOCHn8UEhXBSrE4RJsg1ZKoXFjNQLgJwj+4m+LZiaeu6vlEiF3UrxMI= X-Received: by 2002:a92:2c10:: with SMTP id t16mr4439207ile.24.1597450715871; Fri, 14 Aug 2020 17:18:35 -0700 (PDT) MIME-Version: 1.0 References: <79447b68da0d4cd09757e531caee14d9@cert.org> In-Reply-To: <79447b68da0d4cd09757e531caee14d9@cert.org> From: Mohit Sahni Date: Fri, 14 Aug 2020 17:18:25 -0700 Message-ID: To: Roman Danyliw Cc: LAMPS WG Content-Type: multipart/alternative; boundary="00000000000077445805acdf7ac9" Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-ocsp-nonce-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 15 Aug 2020 00:18:38 -0000 --00000000000077445805acdf7ac9 Content-Type: text/plain; charset="UTF-8" Hi Roman, I have submitted new version (03) of the draft with the suggested changes, please review them and let me know if any further changes are needed. https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/ Thanks Mohit On Sun, Jul 26, 2020 at 7:00 PM Roman Danyliw wrote: > Hi! > > I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02. Thanks for > the work on this document to harden the nonce extension of RFC 6960. Below > is my feedback: > > ** Section 2. Editorial. s/Following is the list/The following is a list/ > > ** Section 2.1. This section appears to be a complete rewrite of the text > in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-ocsp > and id-pkix-ocsp-nonce. To eliminate confusion, I would recommend you add > these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and state that > this new text replaces the entirety of Section 4.4.1. > > ** Section 2.1. Per "The minimum nonce length of 1 octet is defined to > provide the backward compatibility with clients following [RFC6960]. > However the newer OCSP clients MUST use length of at least 16 octets for > Nonce ...", how would this guidance work in practice from the perspective > of the server? > > -- Is this saying that servers shouldn't reject 1 octet nonces for > backward compatibility? > > -- How do I judge if I have a "newer OCSP client" if I have a server? > > ** Section 3.1. s/a man in the middle (MiTM) entity/an on-path attacker/ > > ** Section 3.1. Per "This can be mitigated by the server using a closer > nextUpdate value ...", as the units of nextUpdate are time what does > "closer" mean? > > ** When is cryptographically strong PRNG needed? > > -- Section 2.1 seems to be restricting the "cryptographically strong > pseudorandom number generator" to only new clients ("However the newer OCSP > clients MUST use length of at least 16 octets for Nonce extension and the > value of the nonce MUST be generated using a cryptographically strong > pseudorandom number generator") > > -- Section 3.2 seems to be saying something stronger that all client need > strong randomness ("Therefore the client MUST use a nonce value that > contains cryptographically strong randomness"). > > ** Section 3.2. Per "A client SHOULD use 32 octets for nonce length", it > was odd to me to specify a minimum length in Section 2.1, but the > recommended length here. Why not put the guidance in one place? > > Regards, > Roman > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000077445805acdf7ac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,
I have submitted new version (03) of the dra= ft with the suggested changes, please review them and let me know if any fu= rther changes are needed.=C2=A0


Tha= nks
Mohit=C2=A0

On Sun, Jul 26, 2020 at 7:00 PM Roman Danyli= w <rdd@cert.org> wrote:
=
Hi!

I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02.=C2=A0 Thanks fo= r the work on this document to harden the nonce extension of RFC 6960.=C2= =A0 Below is my feedback:

** Section 2.=C2=A0 Editorial.=C2=A0 s/Following is the list/The following = is a list/

** Section 2.1.=C2=A0 This section appears to be a complete rewrite of the = text in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-o= csp and id-pkix-ocsp-nonce.=C2=A0 To eliminate confusion, I would recommend= you add these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and s= tate that this new text replaces the entirety of Section 4.4.1.

** Section 2.1.=C2=A0 Per "The minimum nonce length of 1 octet is defi= ned to provide the backward compatibility with clients following [RFC6960].= =C2=A0 However the newer OCSP clients MUST use length of at least 16 octets= for Nonce ...", how would this guidance work in practice from the per= spective of the server?=C2=A0

-- Is this saying that servers shouldn't reject 1 octet nonces for back= ward compatibility?

-- How do I judge if I have a "newer OCSP client" if I have a ser= ver?

** Section 3.1.=C2=A0 s/a man in the middle (MiTM) entity/an on-path attack= er/

** Section 3.1.=C2=A0 Per "This can be mitigated by the server using a= closer nextUpdate value ...", as the units of nextUpdate are time wha= t does "closer" mean?

** When is cryptographically strong PRNG needed?

-- Section 2.1 seems to be restricting the "cryptographically strong p= seudorandom number generator" to only new clients ("However the n= ewer OCSP clients MUST use length of at least 16 octets for Nonce extension= and the value of the nonce MUST be generated using a=C2=A0 cryptographical= ly strong pseudorandom number generator")

-- Section 3.2 seems to be saying something stronger that all client need s= trong randomness ("Therefore the client MUST use a nonce value that co= ntains cryptographically strong randomness").=C2=A0

** Section 3.2.=C2=A0 Per "A client SHOULD use 32 octets for nonce len= gth", it was odd to me to specify a minimum length in Section 2.1, but= the recommended length here.=C2=A0 Why not put the guidance in one place?<= br>
Regards,
Roman

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--00000000000077445805acdf7ac9-- From nobody Wed Aug 19 14:04:16 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 326123A0B8B; Wed, 19 Aug 2020 14:03:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk CC: housley@vigilsec.com, rdd@cert.org, Russ Housley , draft-ietf-lamps-ocsp-nonce@ietf.org, spasm@ietf.org, lamps-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159787102342.19799.5301974136261569380@ietfa.amsl.com> Date: Wed, 19 Aug 2020 14:03:43 -0700 Archived-At: Subject: [lamps] Last Call: (OCSP Nonce Extension) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 19 Aug 2020 21:03:44 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'OCSP Nonce Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the updated format of the Nonce extension in Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate and the Nonce extension is used in the OCSP request and response messages to avoid replay attacks. This document updates the RFC 6960 The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Aug 19 21:04:11 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA03A10DC; Wed, 19 Aug 2020 21:04:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Tim Hollebeek , tim.hollebeek@digicert.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159789624873.29898.12400352141110083315@ietfa.amsl.com> Date: Wed, 19 Aug 2020 21:04:09 -0700 Archived-At: Subject: [lamps] Erik Kline's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 20 Aug 2020 04:04:09 -0000 Erik Kline has entered the following ballot position for draft-ietf-lamps-cms-update-alg-id-protect-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ section 1 ] * "the associate parameters" -> "the associated parameters" perhaps [ section 3.5 ] * "the TSA MUST use same digest" -> "the TSA MUST use the same digest" I think From nobody Thu Aug 20 08:54:04 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E53893A02BC; Thu, 20 Aug 2020 08:54:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Cc: housley@vigilsec.com, spasm@ietf.org, lamps-chairs@ietf.org, rfc-editor@rfc-editor.org, rdd@cert.org, draft-ietf-lamps-rfc7030est-clarify@ietf.org, The IESG , Russ Housley MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159793884190.20041.105634856785617409@ietfa.amsl.com> Date: Thu, 20 Aug 2020 08:54:01 -0700 Archived-At: Subject: [lamps] Protocol Action: 'Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1' to Proposed Standard (draft-ietf-lamps-rfc7030est-clarify-10.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 20 Aug 2020 15:54:02 -0000 The IESG has approved the following document: - 'Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1' (draft-ietf-lamps-rfc7030est-clarify-10.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ Technical Summary This document updates RFC 7030 to resolve reported errata, add clarifications to improve interoperability, deprecate the use of "Content-Transfer-Encoding" headers for EST endpoints, and provides an ASN.1 module for RFC 7030. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality EST has wide support. Several people have expressed support of the clarifications in this document. Personnel Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. From nobody Thu Aug 20 11:07:48 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689DD3A108A for ; Thu, 20 Aug 2020 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XKqkIdUUGB6l for ; Thu, 20 Aug 2020 11:07:44 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AF53A1086 for ; Thu, 20 Aug 2020 11:07:43 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Aug 2020 11:07:38 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'LAMPS WG' Date: Thu, 20 Aug 2020 11:07:36 -0700 Message-ID: <00a501d6771c$ca3fb250$5ebf16f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZ3G0EgOrmPqbnyQaisWxDsDw9Ebw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] ASN.1 module for 7030est clarify - was [pkix] [Errata Held for Document Update] RFC7030 (4384) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 20 Aug 2020 18:07:46 -0000 So as suggested by Russ, I when and looked at it I think that the module needs to have some modifications. 1) If you really mean to have the oid option for AttrOrOid then you should have AttrOrOID ::= CHOICE { oid OBJECT IDENTIFIER (OidValueSet), attribute Attribute {{AttrSet}} } OidValueSet OBJECT IDENTIFER ::= { ...} AttrSet ATTRIBUTE ::= {...} 2) I would really suggest that if there are some known values, especially if there are not attributes defined already, that these attributes be defined and added to the value and object sets. This becomes interesting since challengePassword is defined with an attribute in PKSC#9 but appears to be used only as a bare OID in this specification. That is not how would have expected things to work, I would have thought it was a challengePassword with an empty type value. Jim -----Original Message----- From: pkix On Behalf Of Russ Housley Sent: Thursday, August 20, 2020 10:45 AM To: Dan Harkins Cc: Roman D. Danyliw ; pierce.leonberger@baesystems.com; IESG ; IETF PKIX ; RFC Editor Subject: Re: [pkix] [Errata Held for Document Update] RFC7030 (4384) > Making an ASN.1 module would shake out which are needed to be defined as attributes. I would use SHA256 in the oid choice myself. Having an value set there would be useful so that people know which values go in which choices. Please see the ASN.1 module in draft-ietf-lamps-rfc7030est-clarify. Russ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Fri Aug 21 10:22:00 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98763A0E51 for ; Fri, 21 Aug 2020 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5Zvr3Jog8bjk for ; Fri, 21 Aug 2020 10:21:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206C83A0E4C for ; Fri, 21 Aug 2020 10:21:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 03E2438A1F; Fri, 21 Aug 2020 13:01:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bnSqEbS7G1rp; Fri, 21 Aug 2020 13:00:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3E8038A1D; Fri, 21 Aug 2020 13:00:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9111A1AA; Fri, 21 Aug 2020 13:21:49 -0400 (EDT) From: Michael Richardson To: Jim Schaad , 'LAMPS WG' In-Reply-To: <00a501d6771c$ca3fb250$5ebf16f0$@augustcellars.com> References: <00a501d6771c$ca3fb250$5ebf16f0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] ASN.1 module for 7030est clarify - was [pkix] [Errata Held for Document Update] RFC7030 (4384) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 21 Aug 2020 17:22:00 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > So as suggested by Russ, I when and looked at it oops, it is in the RFC editor queue at this point. > I think that the module needs to have some modifications. > 1) If you really mean to have the oid option for AttrOrOid then you should > have > AttrOrOID ::= CHOICE { > oid OBJECT IDENTIFIER (OidValueSet), > attribute Attribute {{AttrSet}} } > OidValueSet OBJECT IDENTIFER ::= { ...} > AttrSet ATTRIBUTE ::= {...} Your change involves the (OidValueSet). We don't know what the ValueSet will be, so I'm not sure I understand what the difference would be. OidValueSet is whatever has been (or will be) defined for CSRs. > 2) I would really suggest that if there are some known values, especially if > there are not attributes defined already, that these attributes be defined > and added to the value and object sets. I can see how this would help implementors, telling them what to expect. Is that your idea? > This becomes interesting since > challengePassword is defined with an attribute in PKSC#9 but appears to be > used only as a bare OID in this specification. That is not how would have > expected things to work, I would have thought it was a challengePassword > with an empty type value. Yes, I think that's right. Does the WG need to reset on this document? Is this AUTH48'able? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9AAq0ACgkQgItw+93Q 3WVhxQgAmED6v1uKSNfl3GM2Qgk2TQQPhatHhBGCP8lu0QrGxwrKcleH/4SjNd5E HIrxb11VO/xJyS/7UW8b+mUK8JcMbmAbi9Tx/mia0TGRWa4iXhc152VjCealcZVf szvlX0Z2DCdxnLts5WfowtjRFCIQLFerAjRXxXEf7ExA0xNdvl1FcyWbp64gDql9 ZQvfEJga80cuhZ1GEk7GiDwP+82uvuQrWGSG55HC3F5xkzFHpZ1atfHYBiadvNMN oAfM5MtG9pJHqCjhgcCvsHiTbE0zc7cS6VsOMFZhB/BFUhZPYpVs2q0uAFcHwu8C Tf8Gb8qRLBPVFRhBZriEOaUq7ZoTrQ== =hSmu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 21 10:53:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B08A3A0F86 for ; Fri, 21 Aug 2020 10:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YMu3ELRYPTFt for ; Fri, 21 Aug 2020 10:53:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1C23A0F85 for ; Fri, 21 Aug 2020 10:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 84E75300B84 for ; Fri, 21 Aug 2020 13:53:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LrHXK6l5Tw5E for ; Fri, 21 Aug 2020 13:53:47 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E3054300A9E; Fri, 21 Aug 2020 13:53:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <23177.1598030509@localhost> Date: Fri, 21 Aug 2020 13:53:48 -0400 Cc: Jim Schaad , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <00a501d6771c$ca3fb250$5ebf16f0$@augustcellars.com> <23177.1598030509@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] ASN.1 module for 7030est clarify - was [pkix] [Errata Held for Document Update] RFC7030 (4384) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 21 Aug 2020 17:53:53 -0000 Michael: There is noting broken with the ASN.1 module in the current I-D. The = proposal just make it "tighter". Russ > On Aug 21, 2020, at 1:21 PM, Michael Richardson = wrote: >=20 > Jim Schaad wrote: >> So as suggested by Russ, I when and looked at it >=20 > oops, it is in the RFC editor queue at this point. >=20 >> I think that the module needs to have some modifications. >=20 >> 1) If you really mean to have the oid option for AttrOrOid then you = should >> have >=20 >> AttrOrOID ::=3D CHOICE { >> oid OBJECT IDENTIFIER (OidValueSet), >> attribute Attribute {{AttrSet}} } >=20 >> OidValueSet OBJECT IDENTIFER ::=3D { ...} >> AttrSet ATTRIBUTE ::=3D {...} >=20 > Your change involves the (OidValueSet). > We don't know what the ValueSet will be, so I'm not sure I understand = what > the difference would be. OidValueSet is whatever has been (or will = be) defined for CSRs. >=20 >> 2) I would really suggest that if there are some known values, = especially if >> there are not attributes defined already, that these attributes be = defined >> and added to the value and object sets. >=20 > I can see how this would help implementors, telling them what to = expect. > Is that your idea? >=20 >> This becomes interesting since >> challengePassword is defined with an attribute in PKSC#9 but appears = to be >> used only as a bare OID in this specification. That is not how would = have >> expected things to work, I would have thought it was a = challengePassword >> with an empty type value. >=20 > Yes, I think that's right. > Does the WG need to reset on this document? > Is this AUTH48'able? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Tue Aug 25 16:00:45 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E4C3A0819; Tue, 25 Aug 2020 16:00:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Tim Hollebeek , tim.hollebeek@digicert.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159839644343.26388.17212228211678584341@ietfa.amsl.com> Date: Tue, 25 Aug 2020 16:00:43 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Aug 2020 23:00:43 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-update-alg-id-protect-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this; it's perhaps a bit overdue. Section-by-section comments below. Section 1 In an algorithm substitution attack, the attacker looks for a different algorithm that produces the same result as the algorithm used by the originator. As an example, if the signer of a message used SHA-256 [SHS] as the digest algorithm to hash the message content, then the attacker looks for a weaker hash algorithm that produces a result that is of the same length. The attacker's goal is to find a different message that results in the same hash value, which is commonly called a collision. [...] The described scenario seems to be a cross-algorithm collision, which is not, in my experience, the most common usage of the unqualified term "collision". In some sense, it seems that the task for an attacker is to find (within the context of the "weak" algorithm) a first preimage for the digest value that is computed by the honest participant (and is likely to be using a "strong" algorithm). Further, when a digest algorithm produces a larger result than is needed by a digital signature algorithm, the digest value is reduced to the size needed by the signature algorithm. This can be done both by truncation and modulo operations, with the simplest being straightforward truncation. [...] (But which of truncation and modulo is to be used is fixed by the algorithm ID, right? Perhaps a slight rewording to avoid indicating that the attacker has a free choice is in order.) This document makes two updates to CMS to provide similar protection for the algorithm identifier. [...] nit: the discussion of how X.509 protects the algorithm identifier/parameters was four paragraphs ago, already; I'd suggest a bit more exposition about what we're providing "similar protection" as. Section 3.1 The preexisting text allows implementations to fail to validate signatures in some cases (when using a digest algorithm not included in the SignedData digestAlgorithms set); do we want to say anything about allowing (or requiring?) implementations to fail to validate signatures if the two digest algorithms are different? Section 3.2 When the signedAttrs field is present, the same digest algorithm MUST be used to compute the digest of the encapContentInfo eContent OCTET STRING, which is carried in the message-digest attribute, and the collection of attributes that are signed. nit: there may be a grammar nit here, relating to the parallelism of "compute the digest of" -- I think "the collection of attributes that are signed" should also have an "of" or "digest of" prefix. Section 3.5 When producing the TimeStampToken, the TSA MUST use same digest algorithm to compute the digest of the encapContentInfo eContent, which is an OCTET STRING that contains the TSTInfo, and the message- digest attribute within the SignerInfo. (There's an implicit "in order to comply with the requirement introduced above" in here, right?) To ensure that TimeStampToken values that were generated before this update remain valid, no requirement is placed on a TSA to ensure that the digest algorithm for the TimeStampToken matches the digest algorithm for the MessageImprint embedded within the TSTTokenInfo. I assume that "TSTTokenInfo" is a typo for "TSTInfo"? Section 4 I like this quote from RFC 6211: % There is a convention, undocumented as far as I % can tell, that the same hash algorithm should be used for both the % content digest and the signature digest. [...] It seems we are now documenting this as more than just convention :) This section updates [RFC5652] to recommend that the originator include the CMSAlgorithmProtection attribute [RFC6211] whenever signed attributes or authenticated attributes are present. Why is the recommendation scoped to only the case when protected attributes are already present? Is the recommendation not generically applicable even when this would be the only protected attribute? Section 6 The security properties of the CMS [RFC5652] signed-data and authenticated-data content types are updated to ensure that algorithm identifiers are adequately protected, which makes algorithm substitution attacks significantly more difficult. Is "ensure" the right word when we only recommend (not require) the use of the CMSAlgorithmProtection attribute? Therefore, it remains important that a signer have a way to signal to a recipient which digest algorithms are allowed to be used in conjunction with the verification of an overall signature. This signalling can be done as part of the specification of the signature algorithm in an X.509v3 certificate extension [RFC5280], or some I'm not entirely sure I'm picturing what is intended by "part of the specification of the signature algorithm in an X.509v3 certificate extension" -- how is the signature algorithm relying on an X.509v3 extension? The CMSAlgorithmProtection attribute [RFC6211] offers protection for the algorithm identifiers used in the signed-data and authenticated- data content types. However, no protection is provided for the algorithm identifiers in the enveloped-data, digested-data, or encrypted-data content types. Likewise, The CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. I feel like we should say something about why we do not provide protection for those content types (e.g., why it is believed to be safe to not have such protection). Section 8.2 The reference to RFC 3161 in Section 3.5 is facially adding a new MUST-level requirement for processing of the structures from RFC 3161, which would qualify as a normative reference in my interpretation of https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ . (However, I believe that the "MUST" in that section is just repeating the requirement from a previous section in the more-specific context, so could safely be rewritten to not have the appearance of a new normative requirement, in which case RFC 3161 could properly remain as an informative reference.) From nobody Tue Aug 25 21:31:12 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA953A0C73; Tue, 25 Aug 2020 21:30:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: draft-ietf-lamps-cms-update-alg-id-protect.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159841625970.23138.505710654934913808@ietfa.amsl.com> Reply-To: Peter Yee Date: Tue, 25 Aug 2020 21:30:59 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-cms-update-alg-id-protect-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 26 Aug 2020 04:31:00 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-cms-update-alg-id-protect-03 Reviewer: Peter Yee Review Date: 2020-08-25 IETF LC End Date: 2020-08-10 IESG Telechat date: 2020-08-27 Summary: This update to CMS (RFC 5262) attempts to prevent algorithm substitution attacks on the hash algorithms. The changes seems reasonable, with one of them already being specified in RFC 6211. There are a few nits that should be cleared up prior to publication. [Ready with Nits] Major issues: None Minor issues: None Nits/editorial comments: Page 2, section 1, 2nd paragraph, last sentence: change "associate" to "associated". Page 4, 1st NEW block, 4th sentence: insert "the" before "signedAttrs field". Page 5, section 3.5, 2nd paragraph, 1st sentence: insert "the" before "same digest". Page 5, section 4 title: change "Recommend" to "Recommended" for parallel construction with the section 3 title. Page 6, ADD block: delete the first "known". Page 6, section 6, 3rd paragraph, 5th sentence: change "signalling" to "signaling". From nobody Wed Aug 26 09:21:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04923A15EF for ; Wed, 26 Aug 2020 09:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 iCWMTRVo18EK for ; Wed, 26 Aug 2020 09:21:02 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A463A15EE for ; Wed, 26 Aug 2020 09:21:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0F157300B74 for ; Wed, 26 Aug 2020 12:21:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nDoaeDKrMWFF for ; Wed, 26 Aug 2020 12:20:58 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E587030009B; Wed, 26 Aug 2020 12:20:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <159841625970.23138.505710654934913808@ietfa.amsl.com> Date: Wed, 26 Aug 2020 12:20:59 -0400 Cc: IETF Gen-ART , LAMPS WG , last-call@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E909C54-1CE1-43B9-BDD3-CEBD7600450F@vigilsec.com> References: <159841625970.23138.505710654934913808@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] Genart telechat review of draft-ietf-lamps-cms-update-alg-id-protect-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 26 Aug 2020 16:21:04 -0000 Peter: > Nits/editorial comments: >=20 > Page 2, section 1, 2nd paragraph, last sentence: change "associate" to > "associated". Done. > Page 4, 1st NEW block, 4th sentence: insert "the" before "signedAttrs = field". Fixed. > Page 5, section 3.5, 2nd paragraph, 1st sentence: insert "the" before = "same > digest". Done. > Page 5, section 4 title: change "Recommend" to "Recommended" for = parallel > construction with the section 3 title. Okay, done. > Page 6, ADD block: delete the first "known". Based on another comment, I have reworded this to say: While there are no known algorithm substitution attacks today, the inclusion of the algorithm identifiers used by the originator as a signed attribute or an authenticated attribute makes such an attack significantly more difficult. > Page 6, section 6, 3rd paragraph, 5th sentence: change "signalling" to > "signaling". Done. Thanks for the careful review. Russ From nobody Wed Aug 26 10:32:06 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8CC3A193F for ; Wed, 26 Aug 2020 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 Zl-T_k_ZoYje for ; Wed, 26 Aug 2020 10:31:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37B13A18F0 for ; Wed, 26 Aug 2020 10:31:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 86BFE300B8F for ; Wed, 26 Aug 2020 13:23:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RiCjiVgnKQ2V for ; Wed, 26 Aug 2020 13:23:14 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8E2EA300B69; Wed, 26 Aug 2020 13:23:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <159839644343.26388.17212228211678584341@ietfa.amsl.com> Date: Wed, 26 Aug 2020 13:23:14 -0400 Cc: IESG , LAMPS WG , lamps-chairs@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, tim.hollebeek@digicert.com Content-Transfer-Encoding: quoted-printable Message-Id: <33A2A824-21C0-44C6-8D81-A1CBDD1D01CC@vigilsec.com> References: <159839644343.26388.17212228211678584341@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 26 Aug 2020 17:32:05 -0000 Hi Ben. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this; it's perhaps a bit overdue. Section-by-section = comments below. >=20 > Section 1 >=20 > In an algorithm substitution attack, the attacker looks for a > different algorithm that produces the same result as the algorithm > used by the originator. As an example, if the signer of a message > used SHA-256 [SHS] as the digest algorithm to hash the message > content, then the attacker looks for a weaker hash algorithm that > produces a result that is of the same length. The attacker's goal = is > to find a different message that results in the same hash value, > which is commonly called a collision. [...] >=20 > The described scenario seems to be a cross-algorithm collision, which = is > not, in my experience, the most common usage of the unqualified term > "collision". In some sense, it seems that the task for an attacker is > to find (within the context of the "weak" algorithm) a first preimage > for the digest value that is computed by the honest participant (and = is > likely to be using a "strong" algorithm). Would you be more happy with the following? ... which is called a cross-algorithm collision. > Further, when a digest algorithm produces a larger result than is > needed by a digital signature algorithm, the digest value is reduced > to the size needed by the signature algorithm. This can be done = both > by truncation and modulo operations, with the simplest being > straightforward truncation. [...] >=20 > (But which of truncation and modulo is to be used is fixed by the > algorithm ID, right? Perhaps a slight rewording to avoid indicating > that the attacker has a free choice is in order.) Yes, truncation or modular reduction is selected by the algorithm = identifier, but the point here is that the algorithm identifier is not = itself protected. By changing the algorithm identifier, the attacker = does get to pick what the verifier will do. > This document makes two updates to CMS to provide similar protection > for the algorithm identifier. [...] >=20 > nit: the discussion of how X.509 protects the algorithm > identifier/parameters was four paragraphs ago, already; I'd suggest a > bit more exposition about what we're providing "similar protection" = as. Maybe just drop "similar". > Section 3.1 >=20 > The preexisting text allows implementations to fail to validate > signatures in some cases (when using a digest algorithm not included = in > the SignedData digestAlgorithms set); do we want to say anything about > allowing (or requiring?) implementations to fail to validate = signatures > if the two digest algorithms are different? I do not understand your suggestion. The structure here is: SignedData ::=3D SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::=3D SET OF DigestAlgorithmIdentifier SignerInfos ::=3D SET OF SignerInfo SignerInfo ::=3D SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } The preexisting text is also included in the NEW text. It is saying = that the verifier can fail the signature validation if = SignerInfo.digestAlgorithm in not in the SET carried in = SignedData.digestAlgorithms. There can be many signatures over the same content. A SignerInfo is = included for each signature. Each signature can use a different digest = algorithm, so I am not sure what "two digest algorithms" you mean. > Section 3.2 >=20 > When the signedAttrs field is present, the same digest algorithm > MUST be used to compute the digest of the encapContentInfo > eContent OCTET STRING, which is carried in the message-digest > attribute, and the collection of attributes that are signed. >=20 > nit: there may be a grammar nit here, relating to the parallelism of > "compute the digest of" -- I think "the collection of attributes that > are signed" should also have an "of" or "digest of" prefix. I changed it to: When the signedAttrs field is present, the same digest algorithm MUST be used to compute the digest of the encapContentInfo eContent OCTET STRING, which is carried in the message-digest attribute, and the digest of the collection of attributes that are signed. > Section 3.5 >=20 > When producing the TimeStampToken, the TSA MUST use same digest > algorithm to compute the digest of the encapContentInfo eContent, > which is an OCTET STRING that contains the TSTInfo, and the message- > digest attribute within the SignerInfo. >=20 > (There's an implicit "in order to comply with the requirement = introduced > above" in here, right?) Yes, I think the previous paragraph makes that clear. > To ensure that TimeStampToken values that were generated before this > update remain valid, no requirement is placed on a TSA to ensure = that > the digest algorithm for the TimeStampToken matches the digest > algorithm for the MessageImprint embedded within the TSTTokenInfo. >=20 > I assume that "TSTTokenInfo" is a typo for "TSTInfo"? Thanks for catching that one. It has been there a long time... > Section 4 >=20 > I like this quote from RFC 6211: >=20 > % There is a convention, undocumented as far as I > % can tell, that the same hash algorithm should be used for both the > % content digest and the signature digest. [...] >=20 > It seems we are now documenting this as more than just convention :) Yes. > This section updates [RFC5652] to recommend that the originator > include the CMSAlgorithmProtection attribute [RFC6211] whenever > signed attributes or authenticated attributes are present. >=20 > Why is the recommendation scoped to only the case when protected > attributes are already present? Is the recommendation not generically > applicable even when this would be the only protected attribute? Signed-data content type computes the signature differently if there are = no protected attributes. In this case, there is only one digest = calculation. So, this is not adding any attributes if there would not = have been any in the first place. > Section 6 >=20 > The security properties of the CMS [RFC5652] signed-data and > authenticated-data content types are updated to ensure that = algorithm > identifiers are adequately protected, which makes algorithm > substitution attacks significantly more difficult. >=20 > Is "ensure" the right word when we only recommend (not require) the = use > of the CMSAlgorithmProtection attribute? I suggest: The security properties of the CMS [RFC5652] signed-data and authenticated-data content types are updated to offer protection for algorithm identifiers, which makes algorithm substitution attacks significantly more difficult. > Therefore, it remains important that a signer have a way to signal = to > a recipient which digest algorithms are allowed to be used in > conjunction with the verification of an overall signature. This > signalling can be done as part of the specification of the signature > algorithm in an X.509v3 certificate extension [RFC5280], or some >=20 > I'm not entirely sure I'm picturing what is intended by "part of the > specification of the signature algorithm in an X.509v3 certificate > extension" -- how is the signature algorithm relying on an X.509v3 > extension? A certificate extension could be specified to says, only used this = public key with a particular digest algorithm. > The CMSAlgorithmProtection attribute [RFC6211] offers protection for > the algorithm identifiers used in the signed-data and authenticated- > data content types. However, no protection is provided for the > algorithm identifiers in the enveloped-data, digested-data, or > encrypted-data content types. Likewise, The CMSAlgorithmProtection > attribute provides no protection for the algorithm identifiers used > in the authenticated-enveloped-data content type defined in > [RFC5083]. >=20 > I feel like we should say something about why we do not provide > protection for those content types (e.g., why it is believed to be = safe > to not have such protection). This attribute does not fit in that structure. It is work for the = future. I suggest: The CMSAlgorithmProtection attribute [RFC6211] offers protection for the algorithm identifiers used in the signed-data and authenticated- data content types. However, no protection is provided for the algorithm identifiers in the enveloped-data, digested-data, or encrypted-data content types. Likewise, The CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. A mechanism for algorithm identifier protection for these content types is work for the future. > Section 8.2 >=20 > The reference to RFC 3161 in Section 3.5 is facially adding a new > MUST-level requirement for processing of the structures from RFC 3161, > which would qualify as a normative reference in my interpretation of > = https://www.ietf.org/about/groups/iesg/statements/normative-informative-re= ferences/ > .. (However, I believe that the "MUST" in that section is just = repeating > the requirement from a previous section in the more-specific context, = so > could safely be rewritten to not have the appearance of a new = normative > requirement, in which case RFC 3161 could properly remain as an > informative reference.) I will make it a normative reference. My thinking was that RFC 3161 = already had a normative reference to CMS, and this document is updating = CMS... Russ From nobody Wed Aug 26 15:44:51 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6993A09DF; Wed, 26 Aug 2020 15:44:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-lamps-ocsp-nonce.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159848188521.31387.820703875829384806@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Wed, 26 Aug 2020 15:44:45 -0700 Archived-At: Subject: [lamps] Opsdir last call review of draft-ietf-lamps-ocsp-nonce-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 26 Aug 2020 22:44:45 -0000 Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document is pretty simple and light weighted, only to add a minimum 1 Octet and maximum 32 octets for the length of NONCE used for OCSP request and response. Best Regards, Linda Dunbar From nobody Thu Aug 27 07:31:49 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CCD3A0C18; Thu, 27 Aug 2020 07:31:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159853870769.14477.11497384614755041413@ietfa.amsl.com> Date: Thu, 27 Aug 2020 07:31:47 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 14:31:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection Author : Russ Housley Filename : draft-ietf-lamps-cms-update-alg-id-protect-04.txt Pages : 9 Date : 2020-08-27 Abstract: This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-protect-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-update-alg-id-protect-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 27 07:33:51 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD703A0CED for ; Thu, 27 Aug 2020 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 u9l9wQuVbza2 for ; Thu, 27 Aug 2020 07:33:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A813A0C4C for ; Thu, 27 Aug 2020 07:33:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A6CA5300B68 for ; Thu, 27 Aug 2020 10:33:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aBJiUrJAfTp4 for ; Thu, 27 Aug 2020 10:33:44 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D139300A9E for ; Thu, 27 Aug 2020 10:33:44 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Thu, 27 Aug 2020 10:33:45 -0400 References: <159853870769.14477.11497384614755041413@ietfa.amsl.com> To: spasm@ietf.org In-Reply-To: <159853870769.14477.11497384614755041413@ietfa.amsl.com> Message-Id: <92D92BD5-DDF6-46EE-8E57-E04FA7D82F37@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 14:33:50 -0000 The revision addresses the non-blocking comments from Ben Kaduk and the = Gen-ART Review comments from Peter Yee. All of the changes were = editorial. Russ > On Aug 27, 2020, at 10:31 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection > Author : Russ Housley > Filename : = draft-ietf-lamps-cms-update-alg-id-protect-04.txt > Pages : 9 > Date : 2020-08-27 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers in = signed- > data and authenticated-data content types are adequately protected. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 27 07:39:20 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE363A0C1A; Thu, 27 Aug 2020 07:39:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159853915474.8887.16137394155438505192@ietfa.amsl.com> Date: Thu, 27 Aug 2020 07:39:14 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 14:39:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection Author : Russ Housley Filename : draft-ietf-lamps-cms-update-alg-id-protect-05.txt Pages : 8 Date : 2020-08-27 Abstract: This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-protect-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-update-alg-id-protect-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 27 07:42:36 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9277E3A0C40 for ; Thu, 27 Aug 2020 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jkLUBTWaeZCz for ; Thu, 27 Aug 2020 07:42:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C5C3A0C58 for ; Thu, 27 Aug 2020 07:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 72A11300AAF for ; Thu, 27 Aug 2020 10:42:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1PXBq2xeTW6d for ; Thu, 27 Aug 2020 10:42:29 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B44F300A9E for ; Thu, 27 Aug 2020 10:42:29 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Thu, 27 Aug 2020 10:42:30 -0400 References: <159853915474.8887.16137394155438505192@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <159853915474.8887.16137394155438505192@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 14:42:35 -0000 I made a mistake in creating -04. I had copied one of the comments into = my edit buffer, and I forgot to remove it before posting the revision. = The -05 version corrects my mistake. Russ > On Aug 27, 2020, at 10:39 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection > Author : Russ Housley > Filename : = draft-ietf-lamps-cms-update-alg-id-protect-05.txt > Pages : 8 > Date : 2020-08-27 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers in = signed- > data and authenticated-data content types are adequately protected. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 27 09:42:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3853E3A0140; Thu, 27 Aug 2020 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 p7lZyTTYwkle; Thu, 27 Aug 2020 09:42:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703E03A046A; Thu, 27 Aug 2020 09:41:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07RGfmsp023837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 12:41:50 -0400 Date: Thu, 27 Aug 2020 09:41:47 -0700 From: Benjamin Kaduk To: Russ Housley Cc: IESG , LAMPS WG , lamps-chairs@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, tim.hollebeek@digicert.com Message-ID: <20200827164147.GP16914@kduck.mit.edu> References: <159839644343.26388.17212228211678584341@ietfa.amsl.com> <33A2A824-21C0-44C6-8D81-A1CBDD1D01CC@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33A2A824-21C0-44C6-8D81-A1CBDD1D01CC@vigilsec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 16:42:02 -0000 Hi Russ, On Wed, Aug 26, 2020 at 01:23:14PM -0400, Russ Housley wrote: > Hi Ben. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this; it's perhaps a bit overdue. Section-by-section comments below. > > > > Section 1 > > > > In an algorithm substitution attack, the attacker looks for a > > different algorithm that produces the same result as the algorithm > > used by the originator. As an example, if the signer of a message > > used SHA-256 [SHS] as the digest algorithm to hash the message > > content, then the attacker looks for a weaker hash algorithm that > > produces a result that is of the same length. The attacker's goal is > > to find a different message that results in the same hash value, > > which is commonly called a collision. [...] > > > > The described scenario seems to be a cross-algorithm collision, which is > > not, in my experience, the most common usage of the unqualified term > > "collision". In some sense, it seems that the task for an attacker is > > to find (within the context of the "weak" algorithm) a first preimage > > for the digest value that is computed by the honest participant (and is > > likely to be using a "strong" algorithm). > > Would you be more happy with the following? > > ... which is called a cross-algorithm collision. Yes > > Further, when a digest algorithm produces a larger result than is > > needed by a digital signature algorithm, the digest value is reduced > > to the size needed by the signature algorithm. This can be done both > > by truncation and modulo operations, with the simplest being > > straightforward truncation. [...] > > > > (But which of truncation and modulo is to be used is fixed by the > > algorithm ID, right? Perhaps a slight rewording to avoid indicating > > that the attacker has a free choice is in order.) > > Yes, truncation or modular reduction is selected by the algorithm identifier, but the point here is that the algorithm identifier is not itself protected. By changing the algorithm identifier, the attacker does get to pick what the verifier will do. True. I was thinking maybe something like "Depending on the particular algorithm, this is done by truncation or by modulo operation", but it's up to you. > > This document makes two updates to CMS to provide similar protection > > for the algorithm identifier. [...] > > > > nit: the discussion of how X.509 protects the algorithm > > identifier/parameters was four paragraphs ago, already; I'd suggest a > > bit more exposition about what we're providing "similar protection" as. > > Maybe just drop "similar". Sure. > > Section 3.1 > > > > The preexisting text allows implementations to fail to validate > > signatures in some cases (when using a digest algorithm not included in > > the SignedData digestAlgorithms set); do we want to say anything about > > allowing (or requiring?) implementations to fail to validate signatures > > if the two digest algorithms are different? > > I do not understand your suggestion. > > The structure here is: > > SignedData ::= SEQUENCE { > version CMSVersion, > digestAlgorithms DigestAlgorithmIdentifiers, > encapContentInfo EncapsulatedContentInfo, > certificates [0] IMPLICIT CertificateSet OPTIONAL, > crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, > signerInfos SignerInfos } > > DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier > > SignerInfos ::= SET OF SignerInfo > > SignerInfo ::= SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > > The preexisting text is also included in the NEW text. It is saying that the verifier can fail the signature validation if SignerInfo.digestAlgorithm in not in the SET carried in SignedData.digestAlgorithms. > > There can be many signatures over the same content. A SignerInfo is included for each signature. Each signature can use a different digest algorithm, so I am not sure what "two digest algorithms" you mean. Basically, I was noting that the preexisting (and retained) text says something about failing signature validation in some cases. The new text adds a MUST relating two digest algorithms (when signedAttrs is present), but it is perhaps ambiguous as to whether the requirement is only on those producing signatures or also applies to those verifying signatures. Having a specific mention about failing signature validation when the newly added MUST does not hold true (but worded appropriately) would be consistent with the preexisting text that discusses when signature validation could fail, and would clarify whether the newly added MUST applies to validation as well as generation of signatures. > > Section 3.2 > > > > When the signedAttrs field is present, the same digest algorithm > > MUST be used to compute the digest of the encapContentInfo > > eContent OCTET STRING, which is carried in the message-digest > > attribute, and the collection of attributes that are signed. > > > > nit: there may be a grammar nit here, relating to the parallelism of > > "compute the digest of" -- I think "the collection of attributes that > > are signed" should also have an "of" or "digest of" prefix. > > I changed it to: > > When the signedAttrs field is present, the same digest algorithm > MUST be used to compute the digest of the encapContentInfo > eContent OCTET STRING, which is carried in the message-digest > attribute, and the digest of the collection of attributes that > are signed. Thanks. > > Section 3.5 > > > > When producing the TimeStampToken, the TSA MUST use same digest > > algorithm to compute the digest of the encapContentInfo eContent, > > which is an OCTET STRING that contains the TSTInfo, and the message- > > digest attribute within the SignerInfo. > > > > (There's an implicit "in order to comply with the requirement introduced > > above" in here, right?) > > Yes, I think the previous paragraph makes that clear. > > > To ensure that TimeStampToken values that were generated before this > > update remain valid, no requirement is placed on a TSA to ensure that > > the digest algorithm for the TimeStampToken matches the digest > > algorithm for the MessageImprint embedded within the TSTTokenInfo. > > > > I assume that "TSTTokenInfo" is a typo for "TSTInfo"? > > Thanks for catching that one. It has been there a long time... > > > Section 4 > > > > I like this quote from RFC 6211: > > > > % There is a convention, undocumented as far as I > > % can tell, that the same hash algorithm should be used for both the > > % content digest and the signature digest. [...] > > > > It seems we are now documenting this as more than just convention :) > > Yes. > > > This section updates [RFC5652] to recommend that the originator > > include the CMSAlgorithmProtection attribute [RFC6211] whenever > > signed attributes or authenticated attributes are present. > > > > Why is the recommendation scoped to only the case when protected > > attributes are already present? Is the recommendation not generically > > applicable even when this would be the only protected attribute? > > Signed-data content type computes the signature differently if there are no protected attributes. In this case, there is only one digest calculation. So, this is not adding any attributes if there would not have been any in the first place. I understand that it would change the mechanics of how the signature is computed ... why does that matter for whether the new procedure is the right thing to do, though? Is the cost of the second digest calculation a significant burden? > > Section 6 > > > > The security properties of the CMS [RFC5652] signed-data and > > authenticated-data content types are updated to ensure that algorithm > > identifiers are adequately protected, which makes algorithm > > substitution attacks significantly more difficult. > > > > Is "ensure" the right word when we only recommend (not require) the use > > of the CMSAlgorithmProtection attribute? > > I suggest: > > The security properties of the CMS [RFC5652] signed-data and > authenticated-data content types are updated to offer protection for > algorithm identifiers, which makes algorithm substitution attacks > significantly more difficult. Thanks. > > Therefore, it remains important that a signer have a way to signal to > > a recipient which digest algorithms are allowed to be used in > > conjunction with the verification of an overall signature. This > > signalling can be done as part of the specification of the signature > > algorithm in an X.509v3 certificate extension [RFC5280], or some > > > > I'm not entirely sure I'm picturing what is intended by "part of the > > specification of the signature algorithm in an X.509v3 certificate > > extension" -- how is the signature algorithm relying on an X.509v3 > > extension? > > A certificate extension could be specified to says, only used this public key with a particular digest algorithm. Ah, I see; thanks. > > The CMSAlgorithmProtection attribute [RFC6211] offers protection for > > the algorithm identifiers used in the signed-data and authenticated- > > data content types. However, no protection is provided for the > > algorithm identifiers in the enveloped-data, digested-data, or > > encrypted-data content types. Likewise, The CMSAlgorithmProtection > > attribute provides no protection for the algorithm identifiers used > > in the authenticated-enveloped-data content type defined in > > [RFC5083]. > > > > I feel like we should say something about why we do not provide > > protection for those content types (e.g., why it is believed to be safe > > to not have such protection). > > This attribute does not fit in that structure. It is work for the future. > > I suggest: > > The CMSAlgorithmProtection attribute [RFC6211] offers protection for > the algorithm identifiers used in the signed-data and authenticated- > data content types. However, no protection is provided for the > algorithm identifiers in the enveloped-data, digested-data, or > encrypted-data content types. Likewise, The CMSAlgorithmProtection > attribute provides no protection for the algorithm identifiers used > in the authenticated-enveloped-data content type defined in > [RFC5083]. A mechanism for algorithm identifier protection for these > content types is work for the future. Thank you for clarifying the state of affairs. > > Section 8.2 > > > > The reference to RFC 3161 in Section 3.5 is facially adding a new > > MUST-level requirement for processing of the structures from RFC 3161, > > which would qualify as a normative reference in my interpretation of > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > .. (However, I believe that the "MUST" in that section is just repeating > > the requirement from a previous section in the more-specific context, so > > could safely be rewritten to not have the appearance of a new normative > > requirement, in which case RFC 3161 could properly remain as an > > informative reference.) > > I will make it a normative reference. My thinking was that RFC 3161 already had a normative reference to CMS, and this document is updating CMS... Okay. Thanks for all the updates and clarifications, Ben From nobody Thu Aug 27 11:37:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290DD3A11D7 for ; Thu, 27 Aug 2020 11:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=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 eOyG1dx5S3r4 for ; Thu, 27 Aug 2020 11:36:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953273A1161 for ; Thu, 27 Aug 2020 11:36:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1BF78300B91 for ; Thu, 27 Aug 2020 14:31:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UxdbGxtMjWaF for ; Thu, 27 Aug 2020 14:31:44 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 97F3130009B; Thu, 27 Aug 2020 14:31:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <20200827164147.GP16914@kduck.mit.edu> Date: Thu, 27 Aug 2020 14:31:44 -0400 Cc: IESG , LAMPS WG , lamps-chairs@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, tim.hollebeek@digicert.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <159839644343.26388.17212228211678584341@ietfa.amsl.com> <33A2A824-21C0-44C6-8D81-A1CBDD1D01CC@vigilsec.com> <20200827164147.GP16914@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 18:36:57 -0000 Ben: I think there are just two comments that have not reached closure. >>> Section 3.1 >>>=20 >>> The preexisting text allows implementations to fail to validate >>> signatures in some cases (when using a digest algorithm not included = in >>> the SignedData digestAlgorithms set); do we want to say anything = about >>> allowing (or requiring?) implementations to fail to validate = signatures >>> if the two digest algorithms are different? >>=20 >> I do not understand your suggestion. >>=20 >> The structure here is: >>=20 >> SignedData ::=3D SEQUENCE { >> version CMSVersion, >> digestAlgorithms DigestAlgorithmIdentifiers, >> encapContentInfo EncapsulatedContentInfo, >> certificates [0] IMPLICIT CertificateSet OPTIONAL, >> crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, >> signerInfos SignerInfos } >>=20 >> DigestAlgorithmIdentifiers ::=3D SET OF = DigestAlgorithmIdentifier >>=20 >> SignerInfos ::=3D SET OF SignerInfo >>=20 >> SignerInfo ::=3D SEQUENCE { >> version CMSVersion, >> sid SignerIdentifier, >> digestAlgorithm DigestAlgorithmIdentifier, >> signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, >> signatureAlgorithm SignatureAlgorithmIdentifier, >> signature SignatureValue, >> unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } >>=20 >> The preexisting text is also included in the NEW text. It is saying = that the verifier can fail the signature validation if = SignerInfo.digestAlgorithm in not in the SET carried in = SignedData.digestAlgorithms. >>=20 >> There can be many signatures over the same content. A SignerInfo is = included for each signature. Each signature can use a different digest = algorithm, so I am not sure what "two digest algorithms" you mean. >=20 > Basically, I was noting that the preexisting (and retained) text says > something about failing signature validation in some cases. The new = text > adds a MUST relating two digest algorithms (when signedAttrs is = present), > but it is perhaps ambiguous as to whether the requirement is only on = those > producing signatures or also applies to those verifying signatures. = Having > a specific mention about failing signature validation when the newly = added > MUST does not hold true (but worded appropriately) would be consistent = with > the preexisting text that discusses when signature validation could = fail, > and would clarify whether the newly added MUST applies to validation = as > well as generation of signatures. The MUST applies to the signature generation and validation. The = digestAlgorithm identifies the message digest algorithm, and any = associated parameters, used by the signer. So, I think it is obvious = that verification involves the same digest algorithm. Further, this is the (long) sentence you are talking about. I do not = think that adding "the signer and verifier" will make it more clear. If the signedAttrs field is present in the SignerInfo, then the same digest algorithm MUST be used to compute both the digest of the SignedData encapContentInfo eContent, which is carried in the message-digest attribute, and the digest of the DER-encoded signedAttrs, which is passed to the signature algorithm. Since there is only on digest algorithm identifier in the SignerInfo, I = cannot think of any additional check to add. >>> This section updates [RFC5652] to recommend that the originator >>> include the CMSAlgorithmProtection attribute [RFC6211] whenever >>> signed attributes or authenticated attributes are present. >>>=20 >>> Why is the recommendation scoped to only the case when protected >>> attributes are already present? Is the recommendation not = generically >>> applicable even when this would be the only protected attribute? >>=20 >> Signed-data content type computes the signature differently if there = are no protected attributes. In this case, there is only one digest = calculation. So, this is not adding any attributes if there would not = have been any in the first place. >=20 > I understand that it would change the mechanics of how the signature = is > computed ... why does that matter for whether the new procedure is the > right thing to do, though? Is the cost of the second digest = calculation > a significant burden? There is no desire to break previous signature, especially since we were = unable to find any implementations that did not always use the same = digest algorithm. We did no investigation about the impact of recommending that signed = attributes alway be present going forward, so I am reluctant to make = such a change at this point in the process. Russ From nobody Thu Aug 27 12:39:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C263A1253; Thu, 27 Aug 2020 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q9ymphs2xFHv; Thu, 27 Aug 2020 12:39:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E3D3A1251; Thu, 27 Aug 2020 12:39:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07RJd3sS002662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 15:39:05 -0400 Date: Thu, 27 Aug 2020 12:39:03 -0700 From: Benjamin Kaduk To: Russ Housley Cc: IESG , LAMPS WG , lamps-chairs@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, tim.hollebeek@digicert.com Message-ID: <20200827193903.GS16914@kduck.mit.edu> References: <159839644343.26388.17212228211678584341@ietfa.amsl.com> <33A2A824-21C0-44C6-8D81-A1CBDD1D01CC@vigilsec.com> <20200827164147.GP16914@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-update-alg-id-protect-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 27 Aug 2020 19:39:12 -0000 Hi Russ, On Thu, Aug 27, 2020 at 02:31:44PM -0400, Russ Housley wrote: > Ben: > > I think there are just two comments that have not reached closure. That sounds right. > >>> Section 3.1 > >>> > >>> The preexisting text allows implementations to fail to validate > >>> signatures in some cases (when using a digest algorithm not included in > >>> the SignedData digestAlgorithms set); do we want to say anything about > >>> allowing (or requiring?) implementations to fail to validate signatures > >>> if the two digest algorithms are different? > >> > >> I do not understand your suggestion. > >> > >> The structure here is: > >> > >> SignedData ::= SEQUENCE { > >> version CMSVersion, > >> digestAlgorithms DigestAlgorithmIdentifiers, > >> encapContentInfo EncapsulatedContentInfo, > >> certificates [0] IMPLICIT CertificateSet OPTIONAL, > >> crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, > >> signerInfos SignerInfos } > >> > >> DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier > >> > >> SignerInfos ::= SET OF SignerInfo > >> > >> SignerInfo ::= SEQUENCE { > >> version CMSVersion, > >> sid SignerIdentifier, > >> digestAlgorithm DigestAlgorithmIdentifier, > >> signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > >> signatureAlgorithm SignatureAlgorithmIdentifier, > >> signature SignatureValue, > >> unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > >> > >> The preexisting text is also included in the NEW text. It is saying that the verifier can fail the signature validation if SignerInfo.digestAlgorithm in not in the SET carried in SignedData.digestAlgorithms. > >> > >> There can be many signatures over the same content. A SignerInfo is included for each signature. Each signature can use a different digest algorithm, so I am not sure what "two digest algorithms" you mean. > > > > Basically, I was noting that the preexisting (and retained) text says > > something about failing signature validation in some cases. The new text > > adds a MUST relating two digest algorithms (when signedAttrs is present), > > but it is perhaps ambiguous as to whether the requirement is only on those > > producing signatures or also applies to those verifying signatures. Having > > a specific mention about failing signature validation when the newly added > > MUST does not hold true (but worded appropriately) would be consistent with > > the preexisting text that discusses when signature validation could fail, > > and would clarify whether the newly added MUST applies to validation as > > well as generation of signatures. > > The MUST applies to the signature generation and validation. The digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the signer. So, I think it is obvious that verification involves the same digest algorithm. > > Further, this is the (long) sentence you are talking about. I do not think that adding "the signer and verifier" will make it more clear. > > If the signedAttrs field is present in the SignerInfo, then the > same digest algorithm MUST be used to compute both the digest of > the SignedData encapContentInfo eContent, which is carried in the > message-digest attribute, and the digest of the DER-encoded > signedAttrs, which is passed to the signature algorithm. > > Since there is only on digest algorithm identifier in the SignerInfo, I cannot think of any additional check to add. Okay, thank you for talking through it; I am fine with no change here. > >>> This section updates [RFC5652] to recommend that the originator > >>> include the CMSAlgorithmProtection attribute [RFC6211] whenever > >>> signed attributes or authenticated attributes are present. > >>> > >>> Why is the recommendation scoped to only the case when protected > >>> attributes are already present? Is the recommendation not generically > >>> applicable even when this would be the only protected attribute? > >> > >> Signed-data content type computes the signature differently if there are no protected attributes. In this case, there is only one digest calculation. So, this is not adding any attributes if there would not have been any in the first place. > > > > I understand that it would change the mechanics of how the signature is > > computed ... why does that matter for whether the new procedure is the > > right thing to do, though? Is the cost of the second digest calculation > > a significant burden? > > There is no desire to break previous signature, especially since we were unable to find any implementations that did not always use the same digest algorithm. > > We did no investigation about the impact of recommending that signed attributes alway be present going forward, so I am reluctant to make such a change at this point in the process. So the concern is more about breaking at validation than at signature-generation time, okay. That makes more sense than how I was thinking about it ("of course you wouldn't just randomly require validators to make a breaking change"), and I can accept your reasoning for not wanting to make changes at this time without a stronger justification. Thanks again, Ben From nobody Mon Aug 31 06:48:58 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F763A13C0; Mon, 31 Aug 2020 06:48:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rfc-editor@rfc-editor.org, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, rdd@cert.org, Tim Hollebeek , spasm@ietf.org, The IESG , lamps-chairs@ietf.org, tim.hollebeek@digicert.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159888172832.14568.16635156655446349617@ietfa.amsl.com> Date: Mon, 31 Aug 2020 06:48:48 -0700 Archived-At: Subject: [lamps] Protocol Action: 'Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection' to Proposed Standard (draft-ietf-lamps-cms-update-alg-id-protect-05.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 31 Aug 2020 13:48:49 -0000 The IESG has approved the following document: - 'Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection' (draft-ietf-lamps-cms-update-alg-id-protect-05.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ Technical Summary This document updates the Cryptographic Message Syntax as specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected. It does so by making two changes: requiring that the originator use the same hash algorithm to compute the digest of the message content and the digest of signed attributes, and recommends that the originator use the CMSAlgorithmProtection attribute [RFC6211]. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality Nothing of note arose during the review of the document. This updated CMS guidance is not yet being implemented. Personnel Tim Hollebeek is the document shepherd. Roman Danyliw is the responsible area director.