From nobody Wed May 22 15:18:49 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922F51200B8 for ; Wed, 22 May 2019 15:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 BgSpEHsqPZx4 for ; Wed, 22 May 2019 15:18:46 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 22F9612004A for ; Wed, 22 May 2019 15:18:46 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id i63so5542952ita.3 for ; Wed, 22 May 2019 15:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XyFfy4r+cSZlUCdT75EP1lC1RfGsggvki4yRm+ERWTA=; b=DqzfwlEG9PUlPDDJBG9rb0leVVZlK9Vt4SSx/D3fewutaKR47xyF66881qKFU2HJhI B8vhs5hb84qdNUBvpblcA9+md8sqeT5z4bIycBj6hlPmbxKNVBnVcQlD7uMzih+6XwV0 G10OaxfDFSXZaiaSk6nMdk9vFwCOx25i8NrksQT6JkCXiuiHlHUIUSPHMc7Cl2NoauoX oogh6PQHbh/rmYz907nNTDr2po3mhxA/b6rphOMB0keFFwL2248B67avXkUDyFjLsQXt aP2i6bRidiV2x/hsxQ/IMeU42XN+Uj7bp4ZYA2nfnsiWg3vDXZa7LcHWJdS1TfYSOMdL 1d3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XyFfy4r+cSZlUCdT75EP1lC1RfGsggvki4yRm+ERWTA=; b=Pp8Ot8FJ/hQyeSmg1iBQUZFbh6TQygIWcBukvin3CCjGNQ0/5Pb/AyDZ5aayxfObRv yqzTLGAHpiHgRiyAV8hlQQoB/gm/UVosCkaYvBko6uE9eyurfJhsVGGg/0PW2Aa4EzrA Ev2T8euuiopQ4cblz3d7kKpCvGBCOp9LePFHuWXvurHj53b8lp2gYCO83v6FabBN76M8 p5nw8rRLA9kRAy4GQcL3RaLwGPd5quc3Vv/vJNFRmss4YqLkDFrFwsDt6PPpDlsjURw9 zCJxCXv4OkA81W0JB9gM4LcEs5VcEwOz8YoLRyM0MElACDFw19Eq5IP0s93mIcIXWry3 SWHA== X-Gm-Message-State: APjAAAXEDqtM2QMMnCQjAWdb9InMHOnJBg/txXW4WMSqFuYUY8pzX1Tq wbR41OZsWUdHjGAAnlQD7TVeYeasBl8OzVPYmJsh/xkc X-Google-Smtp-Source: APXvYqxbIYXU3Yxp/wiV3TrQilykj9f9hjxNsIHeFPMrA02gnC0P3vJyWrHqawRUZaGmV4J7loNb5NK05LltUp6so48= X-Received: by 2002:a02:1986:: with SMTP id b128mr61083089jab.136.1558563525216; Wed, 22 May 2019 15:18:45 -0700 (PDT) MIME-Version: 1.0 From: Alberto Leiva Date: Wed, 22 May 2019 17:18:34 -0500 Message-ID: To: sidr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 22:18:48 -0000 Hello Another question. RFC 7935 states the following: 3.1. Public Key Format (...) algorithm (which is an AlgorithmIdentifier type): The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be used in the algorithm field, as specified in Section 5 of [RFC4055]. The value for the associated parameters from that clause MUST also be used for the parameters field. I've never seen a certificate that declares sha256WithRSAEncryption ({ pkcs-1 11 }) as its public key algorithm. Every certificate I've come across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). (Certificates always define the signature algorithm as sha256WithRSAEncryption, but that's a different field.) Is everyone doing it wrong, or am I missing something? I'm aware that this is likely a triviality--rsaEncryption and sha256WithRSAEncryption probably mean the same in this context. There's also a thread in this list in which people seem to have experienced headaches over this topic. But the thread is talking about CMS signed objects (which I believe is different from certificates), and happened before 7935 was released, so it feels like the RFC should mandate something consistent with reality by now. Thanks for any pointers. From nobody Thu May 23 02:23:17 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C08B1200F8 for ; Thu, 23 May 2019 02:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_SUBJ_BRKN_WORDNUMS=0.01] 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 rKuHVm3Zs3bv for ; Thu, 23 May 2019 02:23:13 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 07EBD120019 for ; Thu, 23 May 2019 02:23:12 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 14E6A1DA6D; Thu, 23 May 2019 11:23:10 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 23 May 2019 11:23:09 +0200 From: Martin Hoffmann To: Alberto Leiva Cc: sidr@ietf.org Message-ID: <20190523112309.71b7ab70@glaurung.nlnetlabs.nl> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 09:23:15 -0000 Alberto Leiva wrote: >=20 > RFC 7935 states the following: >=20 > 3.1. Public Key Format >=20 > (...) >=20 > algorithm (which is an AlgorithmIdentifier type): > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > used in the algorithm field, as specified in Section 5 of > [RFC4055]. The value for the associated parameters from that > clause MUST also be used for the parameters field. >=20 > I've never seen a certificate that declares sha256WithRSAEncryption ({ > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). I=E2=80=99ve been struggling with this, too. My conclusion was that RFC 793= 5 is misleading at best. Section 5 of RFC 4055 talks about signature algorithms not public key algorithms. Section 1.2 of RFC 4055 states | The rsaEncryption object identifier continues to identify the subject | public key when the RSA private key owner does not wish to limit the | use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. | In this case, the rsaEncryption object identifier MUST be used in the | algorithm field within the subject public key information, and the | parameters field MUST contain NULL. So, for RSA v1.5, the key algorithm must be rsaEncryption. Routinator does indeed require that. It doesn=E2=80=99t insist on the presence of the = NULL, though, and allows absent parameters. The certificates we are generating in Krill will all have rsaEncryption as the algorithm and the NULL paramteres field. Kind regards, Martin From nobody Thu May 23 09:23:10 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A212012E for ; Thu, 23 May 2019 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SUBJ_BRKN_WORDNUMS=0.01] 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 fnEGiQWz-9S7 for ; Thu, 23 May 2019 09:23:06 -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 56B73120126 for ; Thu, 23 May 2019 09:23:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7768B300AEC for ; Thu, 23 May 2019 12:03: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 RqA3T6Z_5oBg for ; Thu, 23 May 2019 12:03:46 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 29F25300471; Thu, 23 May 2019 12:03:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Thu, 23 May 2019 12:23:03 -0400 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alberto Leiva X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 16:23:08 -0000 > On May 22, 2019, at 6:18 PM, Alberto Leiva wrote: >=20 > Hello >=20 > Another question. >=20 > RFC 7935 states the following: >=20 > 3.1. Public Key Format >=20 > (...) >=20 > algorithm (which is an AlgorithmIdentifier type): > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > used in the algorithm field, as specified in Section 5 of > [RFC4055]. The value for the associated parameters from that > clause MUST also be used for the parameters field. >=20 > I've never seen a certificate that declares sha256WithRSAEncryption ({ > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). >=20 > (Certificates always define the signature algorithm as > sha256WithRSAEncryption, but that's a different field.) >=20 > Is everyone doing it wrong, or am I missing something? >=20 > I'm aware that this is likely a triviality--rsaEncryption and > sha256WithRSAEncryption probably mean the same in this context. > There's also a thread in this list in which people seem to have > experienced headaches over this topic. But the thread is talking about > CMS signed objects (which I believe is different from certificates), > and happened before 7935 was released, so it feels like the RFC should > mandate something consistent with reality by now. >=20 > Thanks for any pointers. You are right. In the subjectPublicKeyInfo, the algorithm identifier should be = rsaEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the = public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. In the signature, the algorithm identifier should be = sha256WithRSAEncryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This = identifies PKCS#1 v1.5 with SHA-256 as the hash algorithm. Russ From nobody Thu May 23 11:17:09 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AAA12006A for ; Thu, 23 May 2019 11:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 tydWPi9UI7Q9 for ; Thu, 23 May 2019 11:17:04 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 A02AC120043 for ; Thu, 23 May 2019 11:17:04 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id g24so4448627iti.5 for ; Thu, 23 May 2019 11:17:04 -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=gjfXbSW4EHobWZ56Vje1ZsImz+ntJoAiMycVokYfJEA=; b=XlJzKiIbjRh1JGnEScPWwPtTmZuEr8f/FdeYsJ5t78+lgdYsEHPsoajsX1gYTbeb+0 ivjpD4SfIniH/SAZpxgzNLIUa8p3xBQPLL6ghzEuh9MW5SLzJO6qhRlAWq81wA9WBWJ3 JLgK9ksJfjzzsrWtWaFtHUpM/tk+NPvDSyHZCZeiXjjn54l8ClW6MyT+AxyoKM2vDzPK h+vEZ0jOMQo1ZAEuMQWE6E7d1qrzOy4QxVFm1b/5loJ99O3AOXuCTNm9llevDjoN5KAB ZbxOYer/Grqj/k2u+uIr/TQbzekBJVAOPZ95rRcVKNNUu3kL9W9kOdUxD0a+utxyzSNk jd9Q== 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=gjfXbSW4EHobWZ56Vje1ZsImz+ntJoAiMycVokYfJEA=; b=ZFx5XXfk2RkfetgQnAQyAXESgEQdYkQ+ytQRPanjBpljb6KYev+ruMptJ88iA9e9XE CvjKuaAWzpdETLKnEuhWpgCsUsRAYU6/cyd3Bp2tVMYFi9fJAKKrx76uCVAibbZ4dWv1 lReNx9dx+WeXMaD1qS5nuk8dGaYze/eS8XZG7+gInMS/h4TiG0lLrVod7icLUoUmA5DS uLXBwj6Axiu7Jv1YRJQPsevUJd3vFAAHbBrXKJq2c53GtmkhEpByyjwbglJRU5wzEQWj zfEepNHy8x+ia4AmJZMKPoZAKZvCDbHi3TI+y9b84FomtJEqWI/B9mURkzgzSpH0dUeE cUiQ== X-Gm-Message-State: APjAAAXCzS9qCfu19MgTd9F4k0uG8vIMpLR20eVL4f7RlBGea4jxVZVD /X+LZWOs2Xr1iDRff+pS3J+d+jziSmh8LvrsZFuPFQ== X-Google-Smtp-Source: APXvYqztQhtCAibT3z5musAVU+IA73n0EU0GNc1lXW5RaphIAOo7B4ku3bVh5ZzVpSaAoL0qcpJ8LL/PlO61mVt2rUQ= X-Received: by 2002:a24:149:: with SMTP id 70mr14302222itk.79.1558635423785; Thu, 23 May 2019 11:17:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Thu, 23 May 2019 13:16:53 -0500 Message-ID: To: Russ Housley Cc: IETF SIDR Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 18:17:07 -0000 I see. Is this erratum-worthy? On Thu, May 23, 2019 at 11:23 AM Russ Housley wrote: > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrote: > > > > Hello > > > > Another question. > > > > RFC 7935 states the following: > > > > 3.1. Public Key Format > > > > (...) > > > > algorithm (which is an AlgorithmIdentifier type): > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > > used in the algorithm field, as specified in Section 5 of > > [RFC4055]. The value for the associated parameters from that > > clause MUST also be used for the parameters field. > > > > I've never seen a certificate that declares sha256WithRSAEncryption ({ > > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). > > > > (Certificates always define the signature algorithm as > > sha256WithRSAEncryption, but that's a different field.) > > > > Is everyone doing it wrong, or am I missing something? > > > > I'm aware that this is likely a triviality--rsaEncryption and > > sha256WithRSAEncryption probably mean the same in this context. > > There's also a thread in this list in which people seem to have > > experienced headaches over this topic. But the thread is talking about > > CMS signed objects (which I believe is different from certificates), > > and happened before 7935 was released, so it feels like the RFC should > > mandate something consistent with reality by now. > > > > Thanks for any pointers. > > You are right. > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > In the signature, the algorithm identifier should be sha256WithRSAEncryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v1.5 with SHA-256 as the hash algorithm. > > Russ > > From nobody Thu May 23 14:10:56 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6A120189 for ; Thu, 23 May 2019 14:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 GWxBYGPhBMwq for ; Thu, 23 May 2019 14:10:47 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 28A2D120157 for ; Thu, 23 May 2019 14:10:47 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id e184so10665637ite.1 for ; Thu, 23 May 2019 14:10:47 -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:content-transfer-encoding; bh=AScmFBF7GyPI9h5NQtz9d4NIu9pHspxyKxtBvFgdfe0=; b=WsNR/h5O4bKXiShdYg0UsQ6K/49EuUf1hSqCEEUxy9uzp5Up2Gi/c3hHvMFjBkoZlw KQi4V/Ir1YuoykpXjYBPSrEdSJpx+gB8k0vbSpAgG2LFVlTJ1ZEvm/6IUFYIT/+Mhzql LvmxBIfYG1IBBHEuoPgl1+XtURdfK08L4nlc9cCOt53PGtXcOs47zVS9rJdpcD+Jbe13 D/jKfLsiC7Foyoiu4P06dVbI2hCHmrfMA1AE37OManzAAJXVuRbS+rThSJf9TEM6trjz c7ptmK3YWl41uyex3yk5jeoKYkWmRGY6g0tF1YjJPP0hPWTgkNh+gg1czT/Et/xH399o ooJQ== 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:content-transfer-encoding; bh=AScmFBF7GyPI9h5NQtz9d4NIu9pHspxyKxtBvFgdfe0=; b=TIhK8R/rTtcYunqvxP7SoPczSFRWvXXWLm8hehi0UVmGoJw2o5WwFhq0EbTVs2/IOD rnfGBykriT2ottH4Vx33SjMq8mfyDMZwOEsQM1118qs0P9HSRqFhOdIKd/G0xzGLiYX8 r94HqbomHYm2ZE+N4KNGD5C5l6DPB0GuEx4+xis0VJR5/GAR88itldgNVzoZKQm2wupc 4/wzIM6t74qi+bJamR64cURW50Ggk4VdZZk27TkFbWmPbGGsfR7FEO5qjyvKZ6Hz3dDn JfVcFpc/SjaJtajg1cMHfXJAgXSIYid42mU04l01pH9+5uESwz1rRd/cWZiepM643YPL j7qA== X-Gm-Message-State: APjAAAUqcKFm4UyB4edkAReZSCAzwXlaUK/PfLMXpzCN+uTQzdh8CD81 8OmPMgVl8bSX1zd9n+B6j4E5Qj3oWNu0ICIAEYrTSxdf X-Google-Smtp-Source: APXvYqz5gapFbNaX1z1TI9ow6ezB7LIXjzLlrfHzTONEALZ9WMVckNagngVQhMN1n5ha7Dc0ZcnBPqsRBeO9t95nTuc= X-Received: by 2002:a24:4f:: with SMTP id 76mr13996619ita.153.1558645846340; Thu, 23 May 2019 14:10:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Thu, 23 May 2019 16:10:35 -0500 Message-ID: To: Russ Housley , martin@opennetlabs.com Cc: IETF SIDR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 21:10:56 -0000 > Routinator > does indeed require that. It doesn=E2=80=99t insist on the presence of th= e NULL, > though, and allows absent parameters. Lol. So you struggled with absent vs NULL parameters too? I wondered whether I should have included that too in this query. On Thu, May 23, 2019 at 1:16 PM Alberto Leiva wrote: > > I see. Is this erratum-worthy? > > On Thu, May 23, 2019 at 11:23 AM Russ Housley wrot= e: > > > > > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrote: > > > > > > Hello > > > > > > Another question. > > > > > > RFC 7935 states the following: > > > > > > 3.1. Public Key Format > > > > > > (...) > > > > > > algorithm (which is an AlgorithmIdentifier type): > > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > > > used in the algorithm field, as specified in Section 5 of > > > [RFC4055]. The value for the associated parameters from that > > > clause MUST also be used for the parameters field. > > > > > > I've never seen a certificate that declares sha256WithRSAEncryption (= { > > > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). > > > > > > (Certificates always define the signature algorithm as > > > sha256WithRSAEncryption, but that's a different field.) > > > > > > Is everyone doing it wrong, or am I missing something? > > > > > > I'm aware that this is likely a triviality--rsaEncryption and > > > sha256WithRSAEncryption probably mean the same in this context. > > > There's also a thread in this list in which people seem to have > > > experienced headaches over this topic. But the thread is talking abou= t > > > CMS signed objects (which I believe is different from certificates), > > > and happened before 7935 was released, so it feels like the RFC shoul= d > > > mandate something consistent with reality by now. > > > > > > Thanks for any pointers. > > > > You are right. > > > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEncr= yption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public key= to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > > > In the signature, the algorithm identifier should be sha256WithRSAEncry= ption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v1= .5 with SHA-256 as the hash algorithm. > > > > Russ > > > > From nobody Fri May 24 10:05:18 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACFC12016C for ; Fri, 24 May 2019 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3--VDC3IOARz for ; Fri, 24 May 2019 10:05:15 -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 44F6B120130 for ; Fri, 24 May 2019 10:05:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C8670B80CFA; Fri, 24 May 2019 10:04:50 -0700 (PDT) To: gih@apnic.net, ggm@apnic.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ydahhrk@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190524170450.C8670B80CFA@rfc-editor.org> Date: Fri, 24 May 2019 10:04:50 -0700 (PDT) Archived-At: Subject: [sidr] [Technical Errata Reported] RFC7935 (5737) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 17:05:17 -0000 The following errata report has been submitted for RFC7935, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5737 -------------------------------------- Type: Technical Reported by: Alberto Leiva Popper Section: 3.1 Original Text ------------- algorithm (which is an AlgorithmIdentifier type): The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be used in the algorithm field, as specified in Section 5 of [RFC4055]. The value for the associated parameters from that clause MUST also be used for the parameters field. Corrected Text -------------- algorithm (which is an AlgorithmIdentifier type): The object identifier for RSA (rsaEncryption) MUST be used for the algorithm field, as specified in Section 3.2 of [RFC3370]. The value for the associated parameters from that clause MUST also be used for the parameters field. Notes ----- The field described in the paragraph belongs to a public key. The way I understand it, particularly due to the inclusion of a digest, "RSA PKCS #1 v1.5 with SHA-256" (sha256WithRSAEncryption) is not really a public key algorithm identifier; it's a signature algorithm identifier. (Courtesy of Russ Housley) rsaEncryption also allows the public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. All existing RPKI readers and writers that I've seen, as well as the global RPKI repository certificates themselves, currently use rsaEncryption as the public key algorithm of subjectPublicKeyInfo. Therefore, this change should also reflect existing practice. 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. -------------------------------------- RFC7935 (draft-ietf-sidr-rfc6485bis-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure Publication Date : August 2016 Author(s) : G. Huston, G. Michaelson, Ed. Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG