Onko “ RSA-ALKU YKSITYINEN AVAIN ” -määritystä?

Olen täällä, koska kysyn itseltäni saman kysymyksen kuin OP.

PKCS # 1 (RFC 3447) määrittelee ASN.1-rakenteen: RSAPrivateKey, sallii vain RSA-yksityisen avaimen lauseke.

PKCS # 8 (RFC 5208) määrittelee ASN.1-rakenteen: PrivateKeyInfo, joka sallii minkä tahansa yksityisen avaimen lausekkeen. (RSA-yksityisen avaimen kohdalla PrivateKeyInfo on joitain pakkaustietoja ja RSAPrivateKey-tiedoston uudelleenkäyttö PKCS # 1 -palvelusta.) Mutta sen säilömuoto on lainattu salaustuotteiden pakkaamiseen.

RFC 7468 (Johdanto): ” syistä, jotka yleensä johtuvat koordinoimattomuudesta tai huomaamattomuudesta, monet PKIX-, PKCS- ja CMS-kirjastot toteuttaa tekstipohjainen koodaus, joka on samanlainen – mutta ei identtinen – PEM-koodauksen kanssa. ”

Mikä kuuluu seuraavasti: Um, folk on päättänyt käyttää PEM-bittejä salaustiedostojensa pakkaamiseen . Täällä meillä on iloinen ponnistelu yrittää muodostaa se …

Valitettavasti RFC 7468 selventää PKCS # 8 / PrivateKeyInfo -pakkauksen nimellä ”BEGIN PRIVATE KEY”. Mutta ei PKCS # 1 / RSAPrivateKey-pakkausta nimellä ”BEGIN RSA PRIVATE KEY”.

”BEGIN RSA PRIVATE KEY” -pakettia kutsutaan joskus nimellä ”SSLeay-muoto” tai ”perinteinen muoto” yksityiselle avaimelle. Ainakin mikä antaa meille nimen tälle muodolle, mutta kuten sinäkään, en löydä ja toivotan tervetulleeksi jotain, joka lähestyy tämän muodon virallista kuvausta. Epäilen, että tätä ei ole olemassa.

Kommentit

• I'm here, because, I'm asking myself the same question as the OP. – – Selvennykseksi: onko tämä vastauksesi yllä esitettyyn kysymykseen, vai kysytkö itse itsellesi samaa kysymystä?

Sisäisen base64-sisällön muoto:

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- 

on dokumentoitu muodossa RFC3447 – Liite A.1.2 – RSA: n yksityisen avaimen syntaksit :

RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL } 

Tiedät jo, kuinka tämä koodata DER: n avulla ASN.1: n maku; ja kysymys on siitä, kuinka DER-binääritiedot todella kirjoitetaan tiedostoon.

Seuraava vaihe on dokumentoitu RFC 1421 – 4.3.2.4 Vaihe 4 : Tulostettava koodaus

• ne dokumentoivat binääridatan koodauksen base64: ssä
• koodaavat lähdön tekstiriveinä
• jokaisella rivillä ( viimeistä lukuun ottamatta), joka sisältää täsmälleen 64 tulostettavaa merkkiä
• ja viimeinen rivi, joka sisältää 64 tai vähemmän tulostettavaa merkkiä

Sitten on käytetty ”Kotelointiraja” (EB) kapseloitujen PEM-viestien rajoittamiseksi.

• EB: tä edeltävä merkkijono on: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
• EB: n jälkeinen merkkijono on: -----END PRIVACY-ENHANCED MESSAGE-----

Defuct Privacy Enhanced Mail käytti:

• viisi väliviivaa (-----)
• BEGIN something
• viisi väliviivaa (-----)

, jota seuraa

• viisi väliviivaa (-----)
• END something
• viisi väliviivaa (-----)

Nämä PEM-käytännöt siirrettiin julkisen avaimen, yksityisen avaimen ja varmenteiden käyttöön, mutta sopivia muutettu sanamuoto:

-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY----- 

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- 

-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY----- 

-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY----- 

-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE----- 

Kyllä. RFC7468 – PKIX-, PKCS- ja CMS-rakenteiden tekstikoodaukset

Tämä asiakirja ilmaisee tosiasialliset säännöt, joiden mukaan olemassa olevat toteutukset toimivat, ja määrittelee ne, jotta tulevat toteutukset voivat toimia yhdessä.

Tässä ”asiaankuuluva ote:

10. Yksi epäsymmetrinen avain ja yksityisen avaimen PKCS # 8 -tekstikoodaus

Salamattomat PKCS # 8: n yksityisen avaimen tietojen syntaksirakenteet (PrivateKeyInfo), jotka on nimetty uudelleen epäsymmetrisiksi avainpaketteiksi (OneAsymmetricKey), koodataan käyttämällä ”YKSITYINEN AVAIN” -tunnistetta. Koodattujen tietojen PITÄÄ olla BER ( DER: n suosima; katso liite B) koodattu ASN.1 PrivateKeyInfo -rakenne, kuten on kuvattu PKCS # 8: ssa [RFC5208], tai OneAsymmetricKey-rakenne, kuten on kuvattu kohdassa [RFC5958]. Nämä kaksi ovat semanttisesti identtisiä ja ne voidaan erottaa versionumeron mukaan.

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- 

Kommentit

• Kysyn aiheesta ” RSA YKSITYINEN AVAIN ”, ei ” SERTIFIKAATTIPYYNTÖ ”. Muuten, odotan PKCS # 8 tai PKCS # 1, ei PKCS # 10. Luku 10 olisi lähempänä. Mutta se ei määritä ’ t RSA: ta etiketissä, joten on järkevää käyttää PKCS # 8: ta tässä. Koska avaimen algoritmi määritettäisiin tarpeettomasti, voi olla OK (ja näin esimerkkejä) laittaa PKCS # 1 ” RSA-YKSI-AVAIMEN ” tiedosto.
• @ Kuten jo sanoin, etsin ” RSA-YKSITYISAUKAISTA ”, ei kohteelle ” YKSITYINEN AVAIN ”. Joten edes lukua 10 ei voida soveltaa, ja RFC7468 on väärä vastaus.
• @Gustave I ’ tiedän, että kirjoitit ” RSA YKSITYINEN AVAIN ”, mutta yksityisen avaimen muodon määrittäminen otsikossa on tarpeetonta ja tekniset tiedot ovat tärkeitä.
• ABNF lukee < < textualmsg = preeb * WSP (…) > > ja < < preeb = ” —- -BEGIN ” etiketti ” —– ” (…) > >. Joten miksi otsikko on mielestäsi tarpeeton?
• PKCS # 1 ( tools.ietf.org/html/rfc8017#appember-A.1.2 ) ei määritä mitään ’ t määritä mitään ASCII base64 -koodausta, eikä se myöskään määritä ’ t >