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 <[email protected]> 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 ([email protected]) wrote: > > I see. Is this erratum-worthy? > > On Thu, May 23, 2019 at 11:23 AM Russ Housley <[email protected]> wrote: > > > > > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
