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.i...@gmail.com> wrote: > > [Adding sidrops.] > > Hi! > > I was just looking at this report… > https://www.rfc-editor.org/errata_search.php?rfc=7935 > <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 (ydah...@gmail.com > <mailto:ydah...@gmail.com>) wrote: > >> I see. Is this erratum-worthy? >> >> On Thu, May 23, 2019 at 11:23 AM Russ Housley <hous...@vigilsec.com >> <mailto:hous...@vigilsec.com>> wrote: >> > >> > >> > >> > > On May 22, 2019, at 6:18 PM, Alberto Leiva <ydah...@gmail.com >> > > <mailto:ydah...@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 <mailto:sidr@ietf.org> >> https://www.ietf..org/mailman/listinfo/sidr >> <https://www.ietf.org/mailman/listinfo/sidr> > _______________________________________________ > Sidrops mailing list > sidr...@ietf.org <mailto:sidr...@ietf.org> > https://www.ietf.org/mailman/listinfo/sidrops > <https://www.ietf.org/mailman/listinfo/sidrops>
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
