From nobody Fri Jun 28 14:36:07 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 5DBA91202BD; Fri, 28 Jun 2019 14:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Jem5vs8uLtVk; Fri, 28 Jun 2019 14:36:03 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 E8B6A12028B; Fri, 28 Jun 2019 14:36:02 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id k8so12514830edr.11; Fri, 28 Jun 2019 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hKNuaERLnWsMAYFokY+GA/W+UdB3AJ4x/xfVlkTlU80=; b=M8zdrV0KSivPzS9vYVJLj+/7ZO1IcYsBOW3xSLghzFq1k2/Jf74UqQ1hMnNfkD/ZQe 0xvoUK+1fHv/zmq7KK5MM+7MSoI/sxLgWfeADTS3vDVpCVZAGv3lWhIN4Ez0nyhOJ3XL pGxZWbxidHCNaUR3ZnEzJ7ZuwpOu+361f8KdDZLgPjUg4C08TJTmwDJ7Hvfe1f6B5ti+ NMMSSM3um6tGqLVJzYuyecNxMBixGyNV7qir7iCDX8yxLIGbDgFl9CgUcS/PUqDZycQv Ozv/tB7kELdeOckH0aU+eNyANvE9S7MKYH6+14hcUe0V3jciqdO79B6OfZxjfoRJJ+TC vt9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hKNuaERLnWsMAYFokY+GA/W+UdB3AJ4x/xfVlkTlU80=; b=m3SJnipKp8ckb4R4MHlBG65HYBEaxU5sfpQjeLSgThBHSlJH7ZboM2YYwJgmlEqNuA GDtQOvrfMnAC3qRyprILLLx+Yht/jcJeXQpnQ+LrO3uL6/EK9y67WuWVdNyZrd5ADah9 F8ffh892G4N7NOaPOoII7fezcQbYcLP5pV7fUKHcSiFxuwj8SPtgg0iNmD2jDRkN33qv 2wa278BOkntKGpCrkJ6gIo5uJEvfOzwHEQbqVJ35m/jdmZEwzlruXe8oPiD6UgLtcv7S ufIcEU21cG3UN04v3OL+UJTNNSR/oz2wiv58QgvnsAlRCei7i4KWyaub6bGTZ6VWK9R3 AzeQ== X-Gm-Message-State: APjAAAXjMRjEhmKdJTQsK2uMgoOo11PI462bcdrYlw93msKL+XOedcc5 Yhp8OmmUq3VrvfSB1uF6KxFK6wyHfJK9xgZ2glA= X-Google-Smtp-Source: APXvYqxnodRxn2M+XZQxv6tLriNGiBAEHo6fISM3zC6wNdvLPXXn+MVgdInH1aBv3osECfRffvSP+Owto0sS9qcnrWQ= X-Received: by 2002:a17:906:401a:: with SMTP id v26mr11020624ejj.62.1561757761484; Fri, 28 Jun 2019 14:36:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Jun 2019 16:36:00 -0500 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 28 Jun 2019 16:36:00 -0500 Message-ID: To: Alberto Leiva , Russ Housley Cc: IETF SIDR , SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000099399f058c6910d5" 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: Fri, 28 Jun 2019 21:36:06 -0000 --00000000000099399f058c6910d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Adding sidrops.] Hi! I was just looking at this report=E2=80=A6 https://www.rfc-editor.org/errata_search.php?rfc=3D7935 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.=E2=80=9D It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the res= ulting 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 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 > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --00000000000099399f058c6910d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
[Adding sidrops.]

Hi!

I was just looking at this report=E2=80=A6

= The report says: "All existing RPKI readers and writers that I've = seen, as well as the global RPKI repository certificates themselves, curren= tly use rsaEncryption as the public key algorithm of subjectPublicKeyInfo. = Therefore, this change should also reflect existing practice.=E2=80=9D

It turns out that rfc82= 08, and then rfc8608 Updated rfc7935=E2=80=A6the resulting text is:<= /div>

= =C2=A0 =C2=A0o =C2=A0algorithm (an AlgorithmIdentifier type): The id-ecPubl= icKey OID
= =C2=A0 =C2=A0 =C2=A0 MUST be used in the algorithm field, as specified in S= ection 2.1.1
=C2=A0 =C2=A0 =C2=A0 of [RFC5480].=C2=A0 The value for the associated para= meters MUST be
=C2=A0 =C2=A0 =C2=A0 secp256r1, as specified in Section 2.1.1.1 of [RFC5= 480].


The erratum was file= d 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 (yda= hhrk@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 o= f
> > [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 sha256WithRSA= Encryption ({
> > 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 contex= t.
> > There's also a thread in this list in which people seem t= o have
> > experienced headaches over this topic. But the thread is talk= ing about
> > CMS signed objects (which I believe is different from certifi= cates),
> > and happened before 7935 was released, so it feels like the R= FC should
> > mandate something consistent with reality by now.
> >
> > Thanks for any pointers.
>
> You are right.
>
> In the subjectPublicKeyInfo, the algorithm identifier should be rs= aEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the publi= c key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP.
>
> In the signature, the algorithm identifier should be sha256WithRSA= Encryption, 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
=
--00000000000099399f058c6910d5-- From nobody Fri Jun 28 15:20:40 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 A8A61120105; Fri, 28 Jun 2019 15:20:37 -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 CiuwIdRbmLPy; Fri, 28 Jun 2019 15:20:35 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 7050D120157; Fri, 28 Jun 2019 15:20:35 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id u19so7203265ior.9; Fri, 28 Jun 2019 15:20:35 -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=crJBqNPJ12mgrtPMtCOPwgMApx8vjpD0U3Juhv9YBo8=; b=FAZZoQoNORsohQT+P0UEGOE4zIJ2vMRyUukzBnm7OqevJcdYoItXds8Q/JHjIAsskQ KNGgECikoPLHEOZ5gxbs6EPZV7vD88BTtUQPej9bC2MrzylWVoDzY9gnyyag2+Y6fyqh Dx6SpsqXWqaR9aCEj9RRxc6TkWCLawAt1PSl5SIadQHd1S9NkbU8WvG6aIYf0gMbOBew q7K8UdyJBxq90Is7ZpYKs6lsDeyqGMOxs8g3gfuWr7nv5SR6qYacu6ldaBzE7mGCD9qp C1S8SFHVp6uusVyfV2ljFuZpXa/W3/QgEOcBt84FsujWwyPrF/IjlniwEdICRHR9TfWx ch4A== 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=crJBqNPJ12mgrtPMtCOPwgMApx8vjpD0U3Juhv9YBo8=; b=mJGw7IP0cSY0qd4ZxsDEh0lpobQieVwwHcwFfGD+YHYeRbYGGjqjEIuGOCI5lT3P9i 7+zrb759DFLiK1hygKBRpHR9OqUwGDgbrb1sBaBwRIyjtjyCYTdlJv6GiSppYVuYMT4j CtIzW74JtAeAErTMNp7L6dC8Xke9z9LlT49vkecGN+YivrNoDFScWR5hel+4BaxC2IVY IYEyutTr5/smX3YJaQvuKhiVdVbONsRxK6nu2jrnVvsbbdUkrPJPgfZ/0+ZIMOxSZ5E4 1lkmIq7GQ07BJ0cHi3au8iaUcgs9KHk9SF6hFIaIz2e0/JLKEo2YPMBDKMnVcnXL+4JM TUsw== X-Gm-Message-State: APjAAAXWNYUw57LGuiYQFwTaz+/qWMD+dDAOflbznSCm1397J7hcPr1q KykkSVWga/rTwHJVACa0KMb0PZlLdV9InQezygM= X-Google-Smtp-Source: APXvYqzUyeB+Btp0g2MgecE7sGsx3Lv2Hq8+XJjEbgvXJ9XE4MMUgk6XvyMrTJGGkISRQO3ErCypYLTrob0eTcWxpTg= X-Received: by 2002:a02:600c:: with SMTP id i12mr13727734jac.108.1561760434452; Fri, 28 Jun 2019 15:20:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Fri, 28 Jun 2019 17:20:23 -0500 Message-ID: To: Alvaro Retana Cc: Russ Housley , IETF SIDR , SIDR Operations WG 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: Fri, 28 Jun 2019 22:20:38 -0000 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 wrot= e: > > [Adding sidrops.] > > Hi! > > I was just looking at this report=E2=80=A6 > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 > > The report says: "All existing RPKI readers and writers that I've seen, a= s well as the global RPKI repository certificates themselves, currently use= rsaEncryption as the public key algorithm of subjectPublicKeyInfo. Therefo= re, this change should also reflect existing practice.=E2=80=9D > > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the r= esulting 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 J= une. > > Does the report apply to rfc8608, or does the information there reflect e= xisting 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 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 > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Jun 28 15:26:13 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 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: In-Reply-To: From: Alberto Leiva Date: Fri, 28 Jun 2019 17:25:55 -0500 Message-ID: To: Alvaro Retana Cc: Russ Housley , IETF SIDR , SIDR Operations WG 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: 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 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 wr= ote: > > > > [Adding sidrops.] > > > > Hi! > > > > I was just looking at this report=E2=80=A6 > > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 > > > > The report says: "All existing RPKI readers and writers that I've seen,= as well as the global RPKI repository certificates themselves, currently u= se rsaEncryption as the public key algorithm of subjectPublicKeyInfo. There= fore, this change should also reflect existing practice.=E2=80=9D > > > > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the= 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 wr= ote: > > > > > > > > > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrot= e: > > > > > > > > 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 co= me > > > > 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 ab= out > > > > CMS signed objects (which I believe is different from certificates)= , > > > > and happened before 7935 was released, so it feels like the RFC sho= uld > > > > mandate something consistent with reality by now. > > > > > > > > Thanks for any pointers. > > > > > > You are right. > > > > > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEn= cryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public ke= y to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > > > > > In the signature, the algorithm identifier should be sha256WithRSAEnc= ryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v= 1.5 with SHA-256 as the hash algorithm. > > > > > > Russ > > > > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr From nobody Sat Jun 29 00:03: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 636F71200E6 for ; Sat, 29 Jun 2019 00:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SUBJ_BRKN_WORDNUMS=0.01] 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 UGLek7YcBH-M for ; Sat, 29 Jun 2019 00:03:40 -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 04B2512002F for ; Sat, 29 Jun 2019 00:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6C543300AE8 for ; Sat, 29 Jun 2019 02:44:21 -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 qmfGAKh7tNDD for ; Sat, 29 Jun 2019 02:44:18 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 199783009FF; Sat, 29 Jun 2019 02:44:18 -0400 (EDT) From: Russ Housley Message-Id: <5C033DD8-EE26-4413-875C-426FFC7E8A4C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 29 Jun 2019 03:03:34 -0400 In-Reply-To: Cc: Alberto Leiva , SIDR Operations WG , IETF SIDR To: Alvaro Retana References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sidr] [Sidrops] 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: Sat, 29 Jun 2019 07:03:43 -0000 --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro: I think that RFC 8208 is talking about the keys used to sign BGPsec, = where elliptic curve is used because the size a huge consideration. Russ > On Jun 28, 2019, at 5:36 PM, Alvaro Retana = wrote: >=20 > [Adding sidrops.] >=20 > Hi! >=20 > I was just looking at this report=E2=80=A6 > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 = =20 >=20 > 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.=E2=80=9D >=20 > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the = resulting text is: >=20 > 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]. >=20 >=20 > The erratum was filed in May of this year, and rfc8608 was published = in June. >=20 > Does the report apply to rfc8608, or does the information there = reflect existing practice? >=20 > Thanks! >=20 > Alvaro. >=20 > On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com = ) wrote: >=20 >> I see. Is this erratum-worthy?=20 >>=20 >> On Thu, May 23, 2019 at 11:23 AM Russ Housley > wrote:=20 >> >=20 >> >=20 >> >=20 >> > > On May 22, 2019, at 6:18 PM, Alberto Leiva > wrote:=20 >> > >=20 >> > > Hello=20 >> > >=20 >> > > Another question.=20 >> > >=20 >> > > RFC 7935 states the following:=20 >> > >=20 >> > > 3.1. Public Key Format=20 >> > >=20 >> > > (...)=20 >> > >=20 >> > > algorithm (which is an AlgorithmIdentifier type):=20 >> > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be=20= >> > > used in the algorithm field, as specified in Section 5 of=20 >> > > [RFC4055]. The value for the associated parameters from that=20 >> > > clause MUST also be used for the parameters field.=20 >> > >=20 >> > > I've never seen a certificate that declares = sha256WithRSAEncryption ({=20 >> > > pkcs-1 11 }) as its public key algorithm. Every certificate I've = come=20 >> > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }).=20 >> > >=20 >> > > (Certificates always define the signature algorithm as=20 >> > > sha256WithRSAEncryption, but that's a different field.)=20 >> > >=20 >> > > Is everyone doing it wrong, or am I missing something?=20 >> > >=20 >> > > I'm aware that this is likely a triviality--rsaEncryption and=20 >> > > sha256WithRSAEncryption probably mean the same in this context.=20= >> > > There's also a thread in this list in which people seem to have=20= >> > > experienced headaches over this topic. But the thread is talking = about=20 >> > > CMS signed objects (which I believe is different from = certificates),=20 >> > > and happened before 7935 was released, so it feels like the RFC = should=20 >> > > mandate something consistent with reality by now.=20 >> > >=20 >> > > Thanks for any pointers.=20 >> >=20 >> > You are right.=20 >> >=20 >> > 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.=20 >> >=20 >> > 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.=20 >> >=20 >> > Russ=20 >> >=20 >> >=20 >>=20 >> _______________________________________________=20 >> sidr mailing list=20 >> sidr@ietf.org =20 >> https://www.ietf..org/mailman/listinfo/sidr = =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alvaro:

I = think that RFC 8208 is talking about the keys used to sign BGPsec, where = elliptic curve is used because the size a huge consideration.

Russ


On Jun 28, 2019, at 5:36 PM, Alvaro Retana = <aretana.ietf@gmail.com> wrote:

[Adding= sidrops.]

Hi!

I was just looking at this report=E2=80=A6
https://www.rfc-editor.org/errata_search.php?rfc=3D7935&nbs= p;

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.=E2=80=9D

It turns out that rfc8208, and then rfc8608 Updated = rfc7935=E2=80=A6the 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 
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097--