프로그래밍 방식으로 CSR 작성

Question

프로그래밍 방식으로 CSR을 작성하려고합니다. ASN.1, RFC 2986, X.509에 대해 읽었습니다.
OpenSSL을 사용하여 생성 된 DER로 인코딩 된 여러 CSR 파일을 수동으로 파싱했습니다.
모든 것이 몇 가지를 제외하고 명확한 같습니다

1. 공개 키 부분은 비트 문자열의 콘텐츠하기 전에 다음 바이트 8D 00 30 81 89 02 81 81를 포함 (및 03 81 후). 이게 뭐야? DER로 인코딩 된 모든 CSR 파일에 이러한 파일이 들어 있습니다. 나는 RFC에서 그들에 관해 아무것도 발견하지 못했다.

2. 서명 부분에는 서명 내용 이전에 다음 명확하지 않은 바이트가 포함되어 있지만 03 81 이후에 포함됩니다. 이 부분에는 BIT STRING의 마지막 옥텟에 대한 정보가 들어 있습니다 (실제로 마지막 바이트에서 얼마나 많은 비트가 채워 져야하는지). 그러나 이러한 바이트를 디코딩하는 방법을 이해할 수 없습니다. 예를 들어, 서명은 다음과 같을 수 있습니다 :
   03h는 비트 문자열 형식, 비트 문자열의 81h 길이가 03 81 81 00 64 12 ... 24 B1 28
   는 64 12 ... 24 B1 28는 서명입니다 (하지만이 길이 80H있다). 나는 부분 81 00을 이해하지 못한다.

미리 감사드립니다.

Answer 1

1. SubjectPublicKeyInfo의 BIT STRING은 공개 키 알고리즘에 따라 다릅니다. 내용은 다시 DER로 인코딩됩니다. 가능성은 RFC 3370을 참조하십시오.

2. 이 다음과 같이 해석하는 것입니다 서명이 보이는 경우

28 B1 24 ... 81

03

처럼 81 00 64 12. DER은 TLV (태그 길이 값) 인코딩입니다. 그래서 첫 번째 바이트 (그들의 말의 옥텟)는 정확하게 알아 차린 것처럼 BIT STRING의 태그 - 03을 나타냅니다.

번째 바이트 길이 결정

장주기 형하여, 길이 옥텟 최초 옥텟 및 하나 이상의 후속하는 옥텟으로 구성된다. 초기 옥텟은 다음과 같이 인코딩되어야한다.

a) 비트 8은 1이어야한다;

b) 비트 7 ~ 1은 부호있는 2 진 정수 과 최상위 비트가 7 인 길이 옥 테트의 후속 옥텟 수를 부호화해야한다.

81은 비트 8이 1로 설정되어 있으므로 나머지 비트는 전체 길이를 결정하는 바이트 수를 나타냅니다. 귀하의 경우에는 단순히 1 바이트입니다. 그래서 다음 바이트는 당신의 길이입니다 - 81은 129 바이트의 서명 길이와 같습니다. 따라서 다음 129 바이트는 00부터 시작하여 값을 나타냅니다.

Answer 2

'프로그래밍 방식으로'라고 말하면 정확히 무엇을 의미합니까? 코드? 그렇다면 어떤 언어를 사용하고 있습니까?BouncyCastle JCE 공급자에는 Java를 사용하는 경우 PKCS # 10 요청을 생성하는 클래스가 들어 있습니다. 필요한 구성 요소 (DN, 공개 키 등)를 지정하기 만하면됩니다. Microsoft 환경에 더 적합한 .Net 구현도 있습니다.