pem — PEM 봉투 벗기기
-----BEGIN CERTIFICATE----- 와 -----END CERTIFICATE----- 사이의 접힌 base64 에서 가운데 바이트(DER) 를 꺼낸다(RFC 7468). 키 파일도 같은 모양이고 라벨만 다르다. codec 은 base64 를 알지만 줄 접기는 모른다 — 이 모듈이 머리말을 벗기고 접힘을 펴서 넘긴다. 인증서는 밖에서 받는다(certbot 같은 도구가 파일로 놓아 준다). ACME 는 짓지 않는다.
무엇을 약속하고 무엇을 하지 않나
Proc-Type: 4,ENCRYPTED). 첫 번째 것만 낸다 — 한 파일에 여러 개(인증서 체인)가 있으면 뒤엣것은 부르는 쪽이 다시 부른다. URL-safe base64 는 없다. 파서이지 신뢰 판단이 아니다 — 검증은 하지 않는다.| op | 하는 일 |
|---|---|
find_from | hay 안에서 needle 찾기(없으면 len hay) |
body_off | -----BEGIN <라벨>----- 다음 줄의 자리. 0 = 없음 |
end_off | -----END <라벨>----- 의 자리. 0 = 없음 |
unwrap | PEM 한 덩이 → DER 바이트. option u64(쓴 바이트 수), 실패는 none |
표 50.1 — pem 의 op
unwrap src label scratch out 의 scratch 는 두 몫을 진다 — 머리말 조립(앞)과 펴 놓은 base64(뒤). len scratch ≥ len src + 라벨 길이 + 16 이면 넉넉하다.
라벨을 요구하는 이유. unwrap 은 무엇을 여는지 이름으로 받고, BEGIN 과 END 의 라벨이 다르면 거절한다. 한 파일에 여러 개가 들어 있는 것이 정상이다. 짝을 맞추지 않으면 CERTIFICATE 를 열려다 다음 것의 BEGIN 까지 삼켜 쓰레기를 디코드한다 — 그리고 base64 는 쓰레기도 조용히 받아들인다.
줄 끝은 LF 도 CRLF 도 받는다 — http 와 반대다. 그쪽은 경계가 곧 보안이라 맨 LF 를 거절한다(요청 밀반입). 여기는 파일 형식이고 실제 파일이 둘 다 쓴다. 엄격함은 미덕이 아니라 도구다 — 무엇을 막는지에 따라 세기가 달라진다.
왜 decode 가 아니라 unwrap 인가. utf8.decode 가 이미 있고, 이름이 겹치면 한정해 불러도 처리기가 다른 모듈의 시그니처로 타입을 재는 알려진 결함이 있다. 두 모듈을 함께 쓰는 시험이 그 조합이 깨지는 것을 잡았다. 라이브러리는 혼자 초록인 것으로 충분하지 않다 — 조합되어야 쓸 수 있다.
PEM → DER → PKCS#8 → 32 바이트 스칼라로 가는 길은 der 와 함께다 — pem.unwrap src "PRIVATE KEY" sc buf 로 DER 을 얻고, der.p8_inner_off 와 der.ec_priv_off 로 스칼라의 자리를 찾는다.
확인하는 것 — openssl 이 낸 산물과의 대조(인증서 DER 375 바이트가 같고, PKCS#8 안의 스칼라가 자리 36 · 길이 32), 라벨 불일치와 봉투 없음의 거절, VM·네이티브 일치. 시험 벡터의 스칼라는 합성값 01 02 … 20 이다 — 구조는 openssl 이 낸 그대로이므로 파서를 재는 힘은 같고, 명백히 비밀이 아니다.