PP pki data

서명은 그것을 검증하는 공개 키 없이는 아무 가치가 없으며, BIP70은 그 공개 키를 따로 두지 않고 인증서 안에 담아 보냈습니다. 이 필드는 원시 DER 인증서 목록을 감싼 작은 protobuf 래퍼를 담고 있었고, 순서는 판매자에서 바깥쪽으로 향했습니다. 그 안에 무엇이 들어 있었는지가 지갑이 회사 이름을 표시할지 아니면 경고만 표시할지를 결정했습니다.

작동 방식

상태: 역사적입니다. PP pki data는 PaymentRequest 메시지의 다섯 필드 중 3번째 필드였으며, Bitcoin Core는 2020년 6월 3일에 출시된 버전 0.20.0에서 이 필드를 읽는 코드를 삭제했습니다.

바이트 안에는 X509Certificates라는 protobuf 메시지가 있었고, 반복 필드는 정확히 하나였으며 각 항목은 이진 형식의 완전한 인증서였습니다. 순서는 임의로 두지 않고 규정되어 있었습니다. 판매자 자신의 인증서가 먼저 오고, 그다음 공개 루트에 도달하는 데 필요한 중간 인증서가 이어졌습니다.

루트 자체는 의도적으로 빠져 있었고, 그 이유는 BIP70의 범위를 훨씬 넘어 일반화됩니다. 검증하려는 상대방에게서 받은 루트는 아무것도 증명하지 못합니다. 누구나 루트를 하나 만들어 원하는 것에 서명할 수 있기 때문입니다. 신뢰는 이미 기기에 설치된 목록에서 와야 합니다.

사용된 인코딩인 DER은 ASN.1의 정규 이진 형식입니다. 하나의 구조에 정확히 하나의 유효한 바이트 열이 대응합니다. BEGIN CERTIFICATE 줄이 붙은 익숙한 PEM 형식은 같은 바이트를 base64로 나타낸 것으로 공간을 약 3분의 1 더 차지하므로, 전송 형식은 항상 원시 형식입니다.

인증서가 요청 크기의 대부분을 차지했습니다. 출력, 타임스탬프, 메모를 합쳐도 수백 바이트 정도인데, RSA-2048 인증서 하나만 해도 이름이나 확장을 세기 전에 256바이트 모듈러스와 256바이트 서명을 담고 있으며, 이런 인증서가 두 개 이어지면 수천 바이트에 이릅니다. pki 유형이 "none"일 때는 이 필드가 그냥 비어 있었고, 지갑은 목적지 외에는 표시할 것이 없었습니다.

확인할 수 있는 곳

같은 인증서 목록이 같은 리프 우선 순서로 여러분이 만드는 모든 HTTPS 연결에 도착합니다.

TLS 서버는 자신의 인증서를 먼저 보내고 중간 인증서를 그 뒤에 보내며, 위에 설명한 이유로 루트는 생략합니다. 어떤 사이트가 보내는 정확한 목록은 명령 하나로 읽을 수 있으며, openssl s_client -showcerts -connect example.com:443을 실행하면 인쇄되는 것은 BIP70이 담고 있던 것과 동일한 자료를 이진 형식이 아닌 PEM으로 표시한 것입니다.

비트코인을 구매하는 사람에게 교훈은 이 바이트들이 말해 주지 않는 것에 있습니다. 유효한 체인은 어떤 기관이 발급 시점에 해당 도메인 이름의 통제를 확인했다는 것만 증명합니다. 회사를 누가 소유하는지, 페이지가 거래소의 복제본인지, 그 거래소가 출금을 처리할 수 있는지에 대해서는 아무것도 말하지 않습니다. 피싱 사이트도 무료로 몇 초 만에 얻은 완전히 유효한 인증서를 갖고 있으며, 그 인증서가 만드는 자물쇠 표시는 진짜와 구별되지 않습니다.

그러므로 자물쇠가 아니라 도메인을 읽으십시오. 검색 광고가 아니라 한 번 만들어 둔 북마크를 통해 거래소에 접속하고, 돈을 보관하는 사이트에서 인증서 경고가 나오면 안내 문구가 아니라 완전한 정지 신호로 받아들이십시오.

PP pki data vs 인증서 체인

PP pki data는 컨테이너였고, 인증서 체인은 그 안에 들어간 것입니다. pki data라는 이름은 BIP70 문서나 보관된 지갑 소스 코드를 읽을 때만 의미가 있습니다. 그 용어를 사용한 것이 그것 외에는 없기 때문입니다. 반면 체인은 여러분이 매일 의존하는 살아 있는 것이며, BIP70이 문서로 남긴 순서 규칙, 즉 리프 인증서가 먼저 오고 루트 인증서를 생략한다는 규칙은 TLS가 지금도 따르는 규칙입니다.