" BEGIN RSA PRIVATE KEY " 형식에 대한 사양이 있습니까?

지금까지 BEGIN RSA PRIVATE KEY 접두사와 END RSA PRIVATE KEY 접미사를 사용하는 파일 형식에 대한 사양 (RFC 또는 유사)을 찾지 못했습니다. . 정의 된 위치는 어디입니까? 공식적인 이름이 있습니까? 최소한 일련의 PEM RFC와 관련이있는 것 같습니다.

공백 처리, base64 세부 정보에 대한 참조 정보를 찾고 있습니다. , 하나의 파일에 다른 키 결합 등.

이 질문은 페이로드의 ASN 인코딩에 관한 것이 아닙니다.

OpenPGP 사양은 유사한 ASCII-Armor 형식을 설명합니다.
tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
대부분의 PEM 형식 (RSA 개인 키 제외)은 RFC 7468 : Textual Encodings of PKIX, PKCS 및 CMS 구조 . 예를 들어 공백 처리 주제에 대한 지침이 있습니다. RFC는 기본적으로 그 세부 사항은 파서에 따라 다릅니다.
user4982에게 감사합니다. 이것이 제가 찾고있는 종류의 소스입니다. 그러나 RFC 7468에는 레이블 " 암호화 된 개인 키 "에 대한 정보가 포함되어 있지만 ' t for " RSA 개인 키 ".
PEM은 RFC 1421 은 헤더의 전체 형식 등을 설명합니다.하지만 ' " RSA 개인 키 ". 1997 년의이 기사 에서는 OpenSSL을 사용하여 이미 언급하고 있습니다.

답변

저는 OP와 동일한 질문을하고 있기 때문에 여기에 있습니다.

PKCS # 1 (RFC 3447)은 ASN.1 구조를 정의합니다. RSAPrivateKey, 허용 RSA 개인 키의 표현 만.

PKCS # 8 (RFC 5208)은 ASN.1 구조 인 PrivateKeyInfo를 정의하여 모든 개인 키의 표현을 허용합니다. (RSA 개인 키의 경우 PrivateKeyInfo는 일부 패키징 정보이며 PKCS # 1의 RSAPrivateKey 재사용입니다.)

PEM (Privacy Enhanced Mail)은 보안 이메일을위한 기존 방법입니다. 그러나 컨테이너 형식은 암호화 항목을 패키징하기 위해 차용되었습니다.

RFC 7468 (소개) : “ 기본적으로 비 조정 또는 부주의로 귀결되는 이유로 많은 PKIX, PKCS 및 CMS 라이브러리 PEM 인코딩 과 유사하지만 동일하지는 않은 텍스트 기반 인코딩을 구현합니다. “

다음과 같이 읽습니다. 음, 사람들은 PEM 비트를 사용하여 암호화 파일을 패키징하기로 결정했습니다. . 여기서 우리는 그것을 공식화하기위한 유쾌한 노력을 기울이고 있습니다 …

아아, RFC 7468은 PKCS # 8 / PrivateKeyInfo 패키징을 “BEGIN PRIVATE KEY”로 명확히합니다. 그러나 PKCS # 1 / RSAPrivateKey를 “BEGIN RSA PRIVATE KEY”로 패키징하는 것은 아닙니다.

“BEGIN RSA PRIVATE KEY”패키징은 때때로 “SSLeay 형식”또는 “전통적인 형식”이라고 불립니다. 최소한이 형식에 대한 이름을 알려 주지만 여러분과 마찬가지로이 형식에 대한 공식적인 설명에 접근하는 것을 찾을 수 없으며 환영 할 것입니다. 존재하지 않는 것 같습니다.

I'm here, because, I'm asking myself the same question as the OP. – – 명확하게하기 : 위에서 질문 한 질문에 대한 답변입니까, 아니면 실제로 동일한 질문을하고 있습니까?

답변 h2>

내부의 base64 콘텐츠 형식 :

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

는 RFC3447-부록 A.1.2-RSA 개인 키 구문 :

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 }

이미 DER를 사용하여 인코딩하는 방법을 알고 있습니다. ASN.1의 풍미; 문제는 실제로 DER 바이너리 데이터를 파일에 쓰는 방법에 관한 것입니다.

다음 단계는 RFC 1421-4.3.2.4 4 단계에 설명되어 있습니다. : 인쇄 가능한 인코딩

바이너리 데이터를 base64로 인코딩하는 문서
출력을 텍스트 줄로 인코딩
각 줄 ( 마지막을 제외하고) 정확히 64 개의 인쇄 가능한 문자를 포함
및 64 개 이하의 인쇄 가능한 문자를 포함하는 마지막 줄

그러면 “캡슐화 경계”(EB)가 사용됩니다. 캡슐화 된 PEM 메시지를 구분합니다.

EB 이전 문자열 : -----BEGIN PRIVACY-ENHANCED MESSAGE-----
EB 이후 문자열 : -----END PRIVACY-ENHANCED MESSAGE-----

다음을 사용한 것은 개인 정보 보호 강화 메일 입니다.

5 개의 하이픈 (-----)
BEGIN something
5 개의 하이픈 (-----)

뒤에

5 개의 하이픈 (-----)
END something
5 개의 하이픈 (-----)

이러한 PEM 규칙은 공개 키, 개인 키 및 인증서에 적용되었지만 변경된 문구 :

-----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-----

답변

예. RFC7468-PKIX, PKCS 및 CMS 구조의 텍스트 인코딩

이 문서는 기존 구현이 작동하고 향후 구현이 상호 운용 될 수 있도록 정의하는 사실상의 규칙입니다.

관련 발췌문은 다음과 같습니다.

10. 하나의 비대칭 키 및 PKCS # 8 개인 키 정보의 텍스트 인코딩

비대칭 키 패키지 (OneAsymmetricKey)로 이름이 변경된 암호화되지 않은 PKCS # 8 개인 키 정보 구문 구조 (PrivateKeyInfo)는 “PRIVATE KEY”레이블을 사용하여 인코딩됩니다. 인코딩 된 데이터는 BER ( DER 선호, 부록 B 참조) 인코딩 된 ASN.1 PrivateKeyInfo 구조 (PKCS # 8 [RFC5208]에 설명 된대로) 또는 OneAsymmetricKey 구조 ([RFC5958]에 설명 된대로 두 개는 의미 상 동일하며 버전 번호로 구별 할 수 있습니다.

" RSA 개인 키에 대해 묻습니다. ", " 인증 요청 "이 아닙니다. 그건 그렇고, PKCS # 10이 아니라 PKCS # 8 또는 PKCS # 1을 기대합니다. 10 장은 더 가까울 것입니다. 그러나 ' 라벨에 RSA를 지정하지 않으므로 여기서 PKCS # 8을 사용하는 것이 좋습니다. 키 알고리즘이 중복으로 지정되므로 PKCS # 1을 " RSA PRIVATE KEY " 파일입니다.
@ 이미 말씀 드렸듯이 " RSA PRIVATE KEY "를 찾고 있습니다. " 개인 키 " 용이 아닙니다. 따라서 10 장도 해당되지 않으며 RFC7468은 잘못된 답입니다.
@Gustave I ' " RSA PRIVATE KEY ", 그러나 헤더에 개인 키의 형식을 지정할 필요가 없으며 사양이 관련됩니다.
ABNF는 < < textualmsg = preeb * WSP (…) > > 및 < < preeb = " —- -BEGIN " 라벨 " —– " (…) > > 그렇다면 헤더가 불필요한 이유는 무엇입니까?
PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) ' ASCII base64 인코딩을 지정하지 않으며 ' 헤더. PKCS # 8은 ' ASCII base64 인코딩도 지정하지 않습니다. 10 장은 실제로 -----BEGIN PRIVATE KEY-----를 지정합니다. -----BEGIN RSA PRIVATE KEY----- 헤더를 지정하는 표준에 대한 링크가 있습니까?

“ BEGIN RSA PRIVATE KEY ” 형식에 대한 사양이 있습니까?

댓글

답변

댓글

답변

댓글

답글 남기기 답글 취소하기