Re: [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates

Alberto Leiva <ydahhrk@gmail.com> Fri, 28 June 2019 22:26 UTC

Return-Path: <ydahhrk@gmail.com>
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 7AAC612018E; Fri, 28 Jun 2019 15:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_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 8dqydjp0j0Th; Fri, 28 Jun 2019 15:26:09 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 182951201AA; Fri, 28 Jun 2019 15:26:07 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id r185so15758929iod.6; Fri, 28 Jun 2019 15:26:07 -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=eFKPD6y3LBJr3qCD6JtFzlSElggS27EJkH4tgivwHVc=; b=AwwktxWNg3gpZmCmA63PP6aDQlnYU3Ou1oggHJju+zT73VqOIr3Dhu0Z2WvnFUsMYt dzHspALgzfoQuhAvEoG379SaATkkLN7FcX2YhWfYhzgeEKygpRccIWdI1ZbQRsEzmPbF az3wJ3uvrwRdVqeimecZACxliU4M3rSC+VN64fwLyZ91IsQDByo/1O4XTdFTRGcdeUli RoZaZ8Xpeh3Iv40ti5YnqLWe4jxM0gZMdGSgdCVR4K0KlJy7epI0ZDkP+iTl/ZPzsu+o iKx4OJyo2+UwCzrpHvfiW7ZWyIOuLw5+64wx7O3V81e/TDc4b+qSgxs5bVytLglkb1X4 lkwQ==
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=eFKPD6y3LBJr3qCD6JtFzlSElggS27EJkH4tgivwHVc=; b=Qn0NCKXv4OpQDpq9s0mzUIYRDjsYIpvFiPv6wJ6+JMCGCxX1QIEYQwO7NmhQpKCjBV qI9kthjYgpFmJ6cYIcbUohUjbdij43BuLZbI4g8ix7p9PVU2+RHxd5R5ccOj77rz4m2N hWoNPHpd0oi040HZ3dMyP73iS0IqZe2NOoirDKN1K9R10Oda1sUkmq4G8JPP42go/4YX 3AC3TyGFJJs1TlmfmyWud8YKIB34hT25WnAQK488F5nrRagBsGkRVC1U8tLBvLfY8hkQ zn4OuCAJyPPbFFkqtYwGrfrApsjRH9up/0dSQO8WHigcUOLnpouRvQJe2TRMuGmv88PI 3tpA==
X-Gm-Message-State: APjAAAUpPgPKvAsaA00Xe9MehC3m8W7ZaoFKy9Px/CrOIZevScIkNmAI aBQ8n9LtJhuTJM428t6FIjNthyVgwI45Gx04Mmg=
X-Google-Smtp-Source: APXvYqwayh+N8lgN925jsT4YKj8LyDcsaeezjUhQw5cZo8Wu9IsUXuzoiQsMEy3AFTfeWcd+f+XlMpYR0G/mTeVDKC0=
X-Received: by 2002:a02:ad17:: with SMTP id s23mr14595474jan.137.1561760766355; Fri, 28 Jun 2019 15:26:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAA0dE=VOCvxb_0-pEB8CO=JZ9FShVf=pQ43pCmAeYCf9LRTTcw@mail.gmail.com> <ACD43E1A-5BBC-4710-A3D4-72EA7E1BC79F@vigilsec.com> <CAA0dE=Wzdrr3kQiM98yehFHKeAafPgoRWQXdg1HoO0Ey0caLLQ@mail.gmail.com> <CAMMESsxYwV48N9pa0vuFP01DTJxx67zt4PFSr7OxPZHsj+83xQ@mail.gmail.com> <CAA0dE=UkRAn7E4fUs4uw8euZQcR5ZQezVfAksaypWc7KU-HNuQ@mail.gmail.com>
In-Reply-To: <CAA0dE=UkRAn7E4fUs4uw8euZQcR5ZQezVfAksaypWc7KU-HNuQ@mail.gmail.com>
From: Alberto Leiva <ydahhrk@gmail.com>
Date: Fri, 28 Jun 2019 17:25:55 -0500
Message-ID: <CAA0dE=X5vmNDLkzuBSqRAvOtG8iwzd_Tz7Z2Wj_=ES+bjABmAQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: Russ Housley <housley@vigilsec.com>, IETF SIDR <sidr@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/EP3qC6wCRpLbjjeryUIufe5jHbk>
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 <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2019 22:26:12 -0000

Oh, never mind. Both sections include "BGPsec Router Certificates."
*scraches head* I don't know what's happening.

On Fri, Jun 28, 2019 at 5:20 PM Alberto Leiva <ydahhrk@gmail.com>; wrote:
>
> I think those particular sections of RFCs 7935 and 8608 are talking
> about different documents:
>
> 3.  Asymmetric Key Pair Formats
>    The key formats used to compute signatures on CA certificates, BGPsec
>    Router Certificates, and CRLs are as specified in Section 3 of
>    [RFC7935].  This section addresses key formats found in the BGPsec
>    Router Certificate requests and in BGPsec Router Certificates.
> (https://tools.ietf.org/html/rfc8608#section-3)
>
> On Fri, Jun 28, 2019 at 4:36 PM Alvaro Retana <aretana.ietf@gmail.com>; wrote:
> >
> > [Adding sidrops.]
> >
> > Hi!
> >
> > I was just looking at this report…
> > https://www.rfc-editor.org/errata_search.php?rfc=7935
> >
> > The report says: "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.”
> >
> > It turns out that rfc8208, and then rfc8608 Updated rfc7935…the resulting text is:
> >
> >    o  algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID
> >       MUST be used in the algorithm field, as specified in Section 2.1.1
> >       of [RFC5480].  The value for the associated parameters MUST be
> >       secp256r1, as specified in Section 2.1.1.1 of [RFC5480].
> >
> >
> > The erratum was filed in May of this year, and rfc8608 was published in June.
> >
> > Does the report apply to rfc8608, or does the information there reflect existing practice?
> >
> > Thanks!
> >
> > Alvaro.
> >
> > On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com) wrote:
> >
> > I see. Is this erratum-worthy?
> >
> > On Thu, May 23, 2019 at 11:23 AM Russ Housley <housley@vigilsec.com>; wrote:
> > >
> > >
> > >
> > > > On May 22, 2019, at 6:18 PM, Alberto Leiva <ydahhrk@gmail.com>; 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
> > >
> > >
> >
> > _______________________________________________
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr