Küsimus:
Mis vahe on X.509 ja PKCS # 7 sertifikaadil?
golem
2014-11-19 04:56:52 UTC
view on stackexchange narkive permalink
  1. Kas ma õigesti helistan faili .p7b faililaiendiga, mis on Windowsis salvestatud kui "Krüptograafilise sõnumi süntaks Standard - PKCS # 7 sertifikaadid (.P7B)" - "PKCS # 7 sertifikaat"? Või on seda parem nimetada 'X.509 sertifikaadiks, mis on salvestatud PKCS # 7 vormingus'?

  2. Millal valiks üks sertifikaadi vormingu teise asemel? Kas nendel vormingutel on mingeid erilisi tugevusi või nõrkusi?

  3. Selle küsimuse lisamine pärast kahte esimest muudatust. Mille poolest erineb PKCS # 7 vorming võrreldes DER / PEM-failivormingutega?

Täname


Redigeerimine nr 1: Linuxi all olev Firefox pakub mulle võime mõne veebisaidi sertifikaati eksportida järgmiselt:

  • X.509 sertifikaat (PEM)
  • X.509 sertifikaat (DER)
  • X.509 Sertifikaat (PKCS # 7)

Kas see tähendab, et siin on PKCS # 7 lihtsalt binaarne failivorming, mis sarnaneb DER-iga, kuid erineb sellest? Kui tõene, siis .p7b-fail on lihtsalt X.509-sertifikaat, mis on salvestatud PKCS-i # 7-vormingus (erinevalt PEM- või DER-vormingutest).


Muuda # 2: järgige minu esimest muudatust. Sellel lehel OpenSSL: Documents, pkcs7 soovitatakse, et PKCS # 7 saab krüptida kas DER-is või PEM-is. Sellest järeldan, et PKCS # 7 ei ole selge binaarfailivorming. Nüüd olen täiesti segaduses.


Muuda # 3: Okei, sain aru PEM- ja DER-vormingute suhetest. PEM-faili Base64 kodeeritud kasulikkus on tegelikult DER-vormingus andmed. Seega on X.509 sertifikaat esialgu kodeeritud DER-vormingus ja seejärel võite soovi korral kodeerida saadud 'DER-i kodeeritud sertifikaadi' PEM-i kodeeritud sertifikaadiks. Mul on endiselt probleeme pusle PKCS # 7 osa sobitamisega.


Muuda # 4: veel üks teave. PKCS # 7 näib olevat konteiner, mis võimaldab enne XR-vormingus kodeerimist ühendada mitu X.509-sertifikaati (mis erineb PEM-vormingust, kus saate sertifikaate kimpida ühte faili, kleepides need lihtsalt üksteise järel) .

Kaaluge muudatuste postitamist vastusena oma küsimusele.
Kaks vastused:
dave_thompson_085
2014-11-19 22:01:39 UTC
view on stackexchange narkive permalink

Olete arenenud enamasti õigeks, kuid selleks, et lisada mitu punkti ja laiendada @CoverosGene'i vastust rohkem kui mul endal meeldis redigeerimisel teha:

X.509 määratleb sertifikaadi (ja mõned muud siin mitteolulised asjad) ASN.1-s (väga!) Üldise andmete struktureerimise meetodi, millel on mitu määratletud kodeeringut, millest DER eristatakse Kodeerimine Esitus on üsna tavaline ja seda kasutatakse siin.

PEM vorming - mitut tüüpi andmete puhul, millest sertifikaat on ainult üks - on palju öeldut kahendkood ( DER) base64-s kodeeritud andmed (muuda) jaotatuna ridadeks tavaliselt iga 64 tähemärgi järel (kuid on ka variatsioone), lisaks päise- ja haagiseread, mis koosnevad kriipsudest + BEGIN või END + andmete tüüp juhtum SERTIFIKAAT + kriipsud. Need read tunduvad inimesele üleliigsed, kuid need on eeldatavad ja enamasti tarkvara jaoks vajalikud. PEM (Privacy Enhanced Mail) oli tegelikult turvalise e-posti täielik standard, mis on nüüdseks enamjaolt unustatud (vt allpool) va jaoks selle kodeerimisvorming. (redigeeri) Alates 2015. aastast on RFC 7468, mis kirjeldab üksikasjalikult enamus 'PEM-vormingute kasutamist tänapäevaste krüptoandmete jaoks.

PKCS # 7 määratles RSA (ettevõte, mitte algoritm) krüpteeritud ja / või allkirjastatud andmete mitmeotstarbelise vorminguna. See anti üle IETF-ile ja sellest sai RFC 2630, seejärel RFC 3369, seejärel RFC 3852 CMS krüptograafiliste sõnumite süntaks . a>, siis RFC 5652, seega Windowsi (inetopt) viiba sõnastus. "PKCS # 7" tähendab sageli nii algset RSA PKCS-i nr 7 kui ka IETF-i järeltulijat CMS-i, samamoodi kasutatakse nii SSET-i kui ka algset Netscape'i protokolli ja IETF-i järglast TLS-i transporditaseme turvalisus.

Vorming .p7b või .p7c on PKCS # 7 / CMS erijuhtum: SignedData struktuur, mis sisaldab pole "sisu" ja null SignerInfot, kuid üks või mitu sertifikaati (tavaliselt) ja / või CRL-id (harva). Tagasitee, kui see pakkus standardset viisi (muuda) ahela moodustamiseks vajalike sertifikaatide komplekti käsitsemiseks (mitte tingimata korras).

PKCS # 7 / CMS on (on?) Ka ASN.1 ja olenevalt asjaoludest võib see olla kas DER või BER , tihedalt seotud kodeering, millel on väga väikesed erinevused, millega enamik DER-dekoodreid hakkama saavad.

Kuigi PKCS # 7 / CMS-i, nagu kõiki DER- või BER-objekte, saab PEM-vormindada, pole ma näinud ühtegi muud rakendust peale openssl (redigeeri) serte on harva. (Java CertificateFactory suudab PKCS7 / CMS-certs-lugeda ainult DER-ist või PEM-ist, kuid CertPath.getEncoded kirjutab selle ainult DER-i.) Seevastu nii DER- kui ka PEM-vormingud ühtsed sertifikaadid on tavalised.

PKCS # 7 / CMS-i kasutatakse ka S / MIME turvalise e-posti (mitu RFF-i alates 5751-st) aluseks. Põhimõtteliselt kodeeris PEM PKCS # 7 ASCII-tekstiks, mida 1980ndate e-posti süsteemid hõlpsasti käsitsesid, samas kui S / MIME tähistab CMS-i kui MIME-üksusi, mis on kodeeritud mitmel viisil, kuidas tänapäevased e-posti süsteemid saavad hakkama.

OpenSSL ajas asjad segi, rakendades järjekorras: käsk pkcs7 , mis tegeleb ainult certs-CRLs juhtumiga, mitte täis PKCS # 7; käsk crl2pkcs7 , mis tegelikult käitleb CRL-e ja sertifikaate, kuid jällegi mitte ülejäänud PKCS-i # 7; smime käsk, mis tegelikult käsitab nii krüptitud kui ka allkirjastatud sõnumite puhul nii S / MIME kui ka PKCS # 7 / CMS-i; ja käsk cms , mis tegeleb nii S / MIME kui ka PKCS # 7 / CMS-iga täieliku juhtumikomplekti jaoks.

Seega kirjeldaksin valikuid järgmiselt: a cert in PEM- või DER-vorming; (üksik) tsert PKCS # 7 konteineris või lühidalt lihtsalt p7 ja mainige PEM-i ainult harvadel juhtudel, kui see kehtib; või PKCS-i nr 7 või p7 sertikett . Semantiline erinevus ühe sertide ja tertide keti vahel on vähemalt sama oluline kui vormis erinevus sertide enda või konteineri vahel.

Ja see ei saavuta isegi sertifikaadi laialdast segadust. iseenesest (mõne muu üksuse puhul, enamasti CA juur või ankur) ja privatekey PLUSi sertifikaadi - või tavaliselt ahela - kombinatsiooni, mida kasutate oma identiteedi tõestamiseks, näiteks SSL / TLS-serverina või allkirjastamisel S / MIME e-post. See kasutab algselt Microsofti PFX-i isikliku teabe vahetuse vormingut või selle standardset vormi PKCS # 12 või "p12".

Võib-olla tasub mainida, et PKCS # 7 / CMS-i "SignedData" struktuur, mida kasutatakse pelgalt sertifikaatide kotina, on _tellimata_: võite panna mitu sertifikaati, kuid formaat ei jälgi tellimusi. Seetõttu saab see sertifikaatide ketti transportida täpselt nii hästi, kui IKEA müüb mööblit. Dekoodrid peavad ikkagi välja töötama, kes kes ketis alla kirjutas.
@Thomas hea punkt, muudetud. Ja sama ka SignedData puhul, mis * edastab allkirja (või mitu), kuid see jääb selle küsimuse reguleerimisalast välja.
Gene Gotimer
2014-11-19 20:22:53 UTC
view on stackexchange narkive permalink

PKCSi nr 7 võib pidada vorminguks, mis võimaldab mitut sertifikaati kokku siduda, kas DER- või PEM-kodeeringus, ning see võib sisaldada sertifikaate ja sertifikaatide tühistamise loendeid (CRL).

Per RFC2315, PKCS # 7 on

  üldine süntaks andmetele, mis võivad sellele krüptograafiat rakendada, näiteks digitaalallkirjad ja digitaalsed ümbrikud. Süntaks lubab rekursiooni, nii et näiteks ühe ümbriku saab teise sisse pesitseda või üks osapool saab alla kirjutada varjatult ümbritsetud digitaalsetele andmetele.  


See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...