Tiêu chuẩn TCVN 7818-1:2007 về Kỹ thuật mật mã dịch vụ tem thời gian - Phần 1: Khung tổng quát

• Số hiệu: TCVN7818-1:2007
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2007

Bảng 1 - Trình tự theo thời gian của chữ ký số và tem thời gian

Trường hợp 1 (chữ ký bao gồm cả tem thời gian) không xác định chính xác thời điểm khi nào dữ liệu được ký. Nó chỉ khẳng định rằng việc ký được thực hiện sau khi dữ liệu đã được gắn tem thời gian. Trường hợp 2 biểu thị rằng dữ liệu đã được ký trước một thời điểm được tuyên bố. Trường hợp 3 xác định một khoảng thời gian trong đó tài liệu được ký.

4.4  Kiểm tra thẻ tem thời gian

Khi kiểm tra một thẻ tem thời gian trước hết giá trị thời gian đã được chứa trong tem thời gian được đánh giá, sau đó tính hợp lệ của thẻ tem thời gian chứa tham số thời gian được kiểm tra. Tính hợp lệ của một tem thời gian được kiểm tra thông qua việc đánh giá tính chính xác của thẻ tem thời gian. Một cách khác, việc đánh giá tính chính xác của thẻ tem thời gian có thể được ủy nhiệm cho bên thứ ba tin cậy (TTP).

4.5  Dịch vụ gắn tem thời gian

Có hai thao tác cơ bản được thực hiện trong quá trình gắn tem thời gian:

Thao tác gắn tem thời gian: liên kết bằng mật mã các giá trị thời gian với các giá trị dữ liệu.

Thao tác kiểm tra tem thời gian: đánh giá tính đúng đắn của các liên kết mật mã trên.

TSA cung cấp các dịch vụ gắn tem thời gian, còn thao tác kiểm tra tem thời gian có thể có sự tham gia của các tổ chức thẩm quyền tin cậy khác.

...

...

...

5  Liên lạc giữa các thực thể tham gia

Các thực thể tham gia trong tiến trình gắn tem thời gian gồm một bên là một thực thể yêu cầu tem thời gian hoặc kiểm tra tem thời gian, bên kia là một hoặc nhiều TSA. Giao dịch giữa các thực thể này sẽ được giới thiệu trong các Điều dưới đây.

5.1  Giao dịch yêu cầu tem thời gian

Liên lạc giữa một thực thể (người yêu cầu) và TSA khi yêu cầu một tem thời gian bao gồm các bước dưới đây:

Người yêu cầu tạo ra một giá trị băm cho dữ liệu sẽ được gắn tem thời gian. Các cơ chế tạo băm được cung cấp trong ISO/IEC 10118-2: 1997 Công nghệ thông tin - Kỹ thuật mật mã - Hàm băm - Phần 2: Hàm băm sử dụng thuật toán mã khối n bit; Phần 3: Hàm băm chuyên dụng và Phần 4: Hàm băm sử dụng số học mođulo.

Một thông điệp yêu cầu tem thời gian được gửi cho TSA gồm các thành phần dữ liệu sau:

Giá trị băm

Thuật toán băm được sử dụng

Một giá trị nonce

...

...

...

TSA kiểm tra tính đầy đủ của yêu cầu nhận được

TSA sinh một tem thời gian (thẻ tem thời gian). Bản thân tem thời gian là một cấu trúc dữ liệu bao gồm:

Tham số thời gian được sinh ra hoặc nhận được từ một nguồn tin cậy.

Dữ liệu đã được chuyển đến bởi người yêu cầu.

Dữ liệu được sinh bởi TSA để liên kết bằng mật mã giá trị thời gian với giá trị băm, thuật toán băm, và nonce (tùy chọn).

Nếu các liên kết mật mã sử dụng chữ ký số thì TSA có thể sử dụng các thuật toán mật mã cung cấp trong tiêu chuẩn ISO/IEC FCD 14888-3: Công nghệ thông tin - Kỹ thuật mật mã - Chữ ký số có gắn kèm thông báo - Phần 3: Các cơ chế dựa trên chứng chỉ, ISO/IEC FCD 15946-2: Công nghệ thông tin - Kỹ thuật mật mã - Kỹ thuật mật mã dựa trên đường cong elliptic : Chữ ký số và TCVN 7635 :2007 Kỹ thuật mật mã - Chữ ký số

TSA gửi trả thẻ tem thời gian cho người yêu cầu.

Người yêu cầu có thể kiểm tra ngay tính đầy đủ và tính đúng đắn của thẻ tem thời gian nhận được, hoặc cho phép một đối tác tin cậy thực hiện công việc trên.

Hình 1 chỉ ra quá trình liên lạc giũa người yêu cầu và TSA, các chữ số phù hợp với các bước mô tả ở trên

...

...

...

Hình 1 - Liên lạc giữa người yêu cầu và TSA

5.2  Giao dịch kiểm tra tem thời gian

Việc kiểm tra các thẻ tạo ra nhờ Cơ chế tạo thẻ độc lập sử dụng thông tin được chứa trong một thẻ tem thời gian riêng lẻ. Khi cần thiết, người kiểm tra có thể được yêu cầu nhận thêm thông tin bổ sung theo đòi hỏi của cơ chế nhằm hoàn thành thao tác kiểm tra; yêu cầu này có thể được thực hiện bởi người yêu cầu hoặc bởi bên thứ ba tin cậy nhân danh người yêu cầu.

Việc kiểm tra các thẻ tạo ra nhờ Cơ chế tạo thẻ liên kết được đề cập trong một tiêu chuẩn khác.

6  Định dạng thông điệp

Có hai kiểu thông điệp cần thiết để tạo ra các giao dịch được giới thiệu trong Điều 5: Thông điệp giữa người yêu cầu/người kiểm tra tem thời gian và TSA, thông điệp giữa TSA và người yêu cầu/người kiểm tra. Tất cả các thông điệp này sẽ được mô tả theo ASN.1. Môđun ASN.1 hoàn chỉnh được giới thiệu trong Phụ lục A. Các thông điệp sẽ có sự phân biệt theo các dịch vụ mà nó biểu diễn.

6.1  Yêu cầu gắn tem thời gian

Các thông điệp TimeStampReq được thực thể sử dụng để yêu cầu các dịch vụ tem thời gian từ những Tổ chức cấp tem thời gian. Thông điệp TimeStampReq có dạng như sau:

...

...

...

Trường dữ liệu

Mô tả

version

Số phiên bản của cú pháp

messageImprint

Nhà cung cấp dịch vụ gắn giá trị thời gian vào messageImprint.

reqPolicy

Chính sách dịch vụ được yêu cầu từ TSA phát hành thẻ tem thời gian.

nonce

...

...

...

certReq

Nếu có mặt trường này thì thông báo cho TSA cung cấp thông tin chứng chỉ.

extensions

Chứa các mở rộng cần có để hoàn thành một cách đúng đắn thao tác gắn tem thời gian được yêu cầu.

Kiểu MessageImprint được sử dụng để bọc dữ liệu dấu vết thông điệp cùng với định danh thuật toán được sử dụng để sinh ra dấu vết thông điệp.

Trường dữ liệu

Mô tả

hashAlgorithm

...

...

...

hashedMessage

Giá trị băm tương ứng của thông điệp sẽ được gắn tem thời gian, như đã được tính cùng với hàm băm đã được chỉ ra trong trường dữ liệu hashAlgorithm.

Hàm băm cần phải là hàm băm kháng va chạm.

TSAPolicyID được định nghĩa như sau:

TSAPolicylD ::= POLICY.&id({TSAPolicies})

6.2  Hồi đáp tem thời gian

Câu trả lời cho một yêu cầu tem thời gian là một cấu trúc dữ liệu TimeStampResp. Nó có dạng sau:

Bảng sau đây mô tả những trường dữ liệu mà còn chưa được định nghĩa.

...

...

...

Mô tả

accuracy

Độ chính xác của trường genTime khi được so với UTC

genTime

Thời gian mà TSA đưa vào trong Thẻ tem thời gian.

serialNumber

Là một số nguyên được gán bởi TSA cho mỗi Thẻ tem thời gian. Nó phải là duy nhất cho mỗi Thẻ tem thời gian đã được phát hành bởi một TSA đã biết.

Cấu trúc TSTInfo được bọc trong cấu trúc TimeStampToken nhờ phương pháp bọc ContentInfo phù hợp với mỗi thực thi TSA. Khi được bọc trong một cấu trúc ContentInfo (ContentInfo lại sử dụng cấu trúc EncapsulatedContentInfo), trường eContentType chứa định danh đối tượng sau:

...

...

...

GeneralizedTime là sự kết hợp của khuôn dạng cơ sở theo các ngày tháng ở dạng biểu diễn đầy đủ và khuôn dạng cơ sở theo Thời gian quy ước chung (Universal Time Coordinated - UTC) theo ISO 8601: Các phần tử dữ liệu và định dạng trao đổi - Trao đổi thông tin - Biểu diễn ngày và thời gian. Khuôn dạng này như sau:

Trong đó mỗi một ký tự (ngoại trừ ký tự cuối cùng) là một thay thế cho một chữ số:

CC biểu diễn thế kỷ (19-99)

YY biểu diễn năm (00-99)

MM biểu diễn một tháng thực tế (01-12)

DD biểu diễn ngày thực tế của tháng (01-31) (tùy theo từng tháng)

hh biểu diễn giờ thực tế của ngày (00-23)

mm biểu diễn cho số phút của giờ (00-59) và

...

...

...

ff là viết tắt cho các phần thập phân của giây

Ký tự Z (Zulu Time) đại diện cho Thời gian quy ước chung (UTC)

6.3  Kiểm tra tem thời gian

Giao thức kiểm tra tương tự với giao thức yêu cầu tem thời gian; nó cũng bao gồm một thông điệp yêu cầu (VerifyReq) và hồi đáp tương ứng (verifyResp). Các cấu trúc dữ liệu sau được áp dụng:

Trường requestlD gắn yêu cầu với phúc đáp tương ứng.

6.4  Các trường mở rộng

...

...

...

Người yêu cầu dịch vụ tem thời gian có thể đề xuất để nhận được tem thời gian cho nhiều giá trị băm từ một mục dữ liệu duy nhất.

Việc đưa ra nhiều giá trị băm nhận được từ một mục dữ liệu duy nhất nhờ sử dụng các hàm băm khác nhau cho phép người yêu cầu có thể bảo vệ thẻ tem thời gian nhận được khỏi các lỗi mật mã của một hàm băm riêng biệt bất kỳ.

Để có thể đề xuất nhiều giá trị băm, phần mở rộng sau được định nghĩa:

Mở rộng này được đưa vào trong trường “extensions” của cả thông điệp TimeStampReq đã được gửi đi bởi người yêu cầu tới TSA và trong trường “extensions” của cấu trúc TimeStarapToken kết quả đã được tạo ra bởi TSA và được trả về người yêu cầu.

Nếu có phần mở rộng này và TSA là có thể xử lý nó thì TSA cần phải liên kết bằng mật mã cả giá trị băm ở trong thông điệp yêu cầu tem thời gian đã được chỉ ra trong trường messageImprints và giá trị băm đã được đưa vào trong mở rộng này với giá trị thời gian mà TSA gán vào thẻ tem thời gian kết quả.

6.4.2  Mở rộng ExtMethod

Người yêu cầu của các dịch vụ tem thời gian có thể muốn chỉ ra cho TSA cụ thể nào đó phương pháp nào có thể sử dụng khi tạo ra thẻ tem thời gian thu được. Để thực hiện được điều đó, mở rộng sau được định nghĩa:

...

...

...

Nếu có phần mở rộng này và TSA có thể đáp ứng nó, thì TSA cần phải cố để hoàn thành yêu cầu đối với phương pháp đã được chỉ định, hoặc gửi trả về một thông báo chỉ ra rằng phương pháp này không thực hiện được. Nếu người yêu cầu định ra nhiều hơn một phương pháp có thể, thì TSA có thể chọn một trong những phương pháp đã được đề xuất để sử dụng trong việc tạo ra thẻ tem thời gian. Nếu không có phần mở rộng này, TSA sử dụng cơ chế tem thời gian ngầm định.

Phụ lục A

(Quy định)

Trích đoạn ASN.1 cho tem thời gian

Trích đoạn này chứa đoạn ký hiệu ASN.1 đúng dựa trên các chuẩn ASN.1 đã được kiểm tra cẩn thận bởi bộ kiểm tra cú pháp tin cậy thuộc dự án ASN.1 của ITU-T.

...

...

...

Phụ lục B

(Quy định)

Trích đoạn Cú pháp thông điệp mật mã

...

...

...

B.1  Giới thiệu

Phụ lục B mô tả CMS. Cú pháp này được sử dụng để ký số, tóm lược, xác thực, hoặc mã các thông điệp tùy ý.

CMS mô tả cú pháp bọc để bảo vệ dữ liệu. Nó hỗ trợ các chữ ký số, các mã xác thực thông điệp, và mã hoá. Cú pháp cho phép bọc nhiều lần, nên một lớp vỏ bọc có thể được lồng bên trong một bọc khác. Tương tự như thế, một bên có thể ký số dữ liệu nào đó đã được bọc trước đây. Nó cũng cho phép các thuộc tính tùy ý, chẳng hạn như thời gian ký đã được ký cùng với nội dung thông điệp, và cung cấp cho các thuộc tính khác chẳng hạn chữ ký xác nhận một chữ ký khác.

CMS có thể hỗ trợ nhiều kiến trúc về quản lý khoá dựa trên chứng chỉ, chẳng hạn như một kiến trúc đã được định nghĩa bởi nhóm công tác PKIX.

Các giá trị CMS được sinh ra nhờ ASN.1 sử dụng mã định dạng BER và DER. Các giá trị thường được biểu diễn dưới dạng chuỗi octet. Trong khi nhiều hệ thống có thể truyền các chuỗi octet tùy ý một cách đáng tin cậy, thì nhiều hệ thống thư điện tử lại không có khả năng đó. Tài liệu này không đề cập tới các cơ chế để mã hoá các chuỗi octet nhằm truyền tin cậy trong các môi trường như vậy.

B.2 Tổng quan

CMS nhìn chung đủ hỗ trợ nhiều kiểu nội dung khác nhau. Phụ lục này định nghĩa một nội dung bảo vệ ContentInfo. ContentInfo bọc một kiểu nội dung đã được định danh riêng lẻ, và kiểu định danh này lại có thể tiếp tục dùng để bọc tiếp theo. Phần này của tài liệu định nghĩa các kiểu: dữ liệu (data), dữ liệu được ký (signed-data).

Theo triết lý thiết kế chung, mỗi kiểu nội dung cho phép quá trình xử lý theo kiểu lần lượt đi qua sử dụng mã định dạng BER (Basic Encoding Rules) có độ dài không xác định. Thao tác lần lượt đi qua đặc biệt hữu ích nếu nội dung lớn, được lưu trữ trên băng từ, hoặc được “đặt ống” từ quá trình khác. Thao tác lần lượt đi qua có một điểm yếu đáng kể là khó thực hiện các thao tác mã định dạng dùng DER vì độ dài của các thành phần khác nhau có thể không được biết trước. Tuy nhiên, các thuộc tính đã được ký bên trong kiểu nội dung signed-data đòi hỏi cách mã định dạng DER. Các thuộc tính đã được ký cần phải được truyền đi theo định dạng DER để chắc chắn rằng những người nhận có thể kiểm tra một nội dung mà chứa một hoặc nhiều thuộc tính không nhận dạng được. Các thuộc tính đã được ký là một kiểu dữ liệu CMS yêu cầu cách mã định dạng DER.

B.3  Cú pháp chung

...

...

...

Các trường của Contentlnf o cố các ý nghĩa sau:

Trường dữ liệu

Mô tả

contentType

Kiểu của nội dung liên quan. Đó là một định danh đối tượng, là một chuỗi các số nguyên duy nhất được tổ chức có thẩm quyền cung cấp để định nghĩa kiểu nội dung.

content

Nội dung liên quan. Kiểu của nội dung có thể được xác định một cách duy nhất bởi contentType. Các kiểu hợp lệ là dữ liệu và dữ liệu được ký.

B.4  Kiểu nội dung dữ liệu

...

...

...

Kiểu nội dung dữ liệu được dự kiến tham chiếu tới các chuỗi octet tùy ý, chẳng hạn như các tệp văn bản ASCII; việc giải thích rõ hơn được thể hiện trong ứng dụng. Các chuỗi như vậy không cần có bất kỳ cấu trúc bên trong nào (mặc dù chúng có thể có định nghĩa ASN.1 hoặc cấu trúc khác riêng của mình).

Kiểu nội dung dữ liệu thường được bọc trong kiểu nội dung dữ liệu được ký.

B.5  Kiểu nội dung dữ liệu được ký

Kiểu nội dung dữ liệu được ký bao gồm nội dung của kiểu bất kỳ và không có hoặc có nhiều giá trị chữ ký. Một số bất kỳ những người ký có thể ký đồng thời một kiểu nội dung nào đó.

Ứng dụng điển hình của kiểu nội dung dữ liệu được ký biểu diễn chữ ký số của một người ký lên nội dung của kiểu nội dung dữ liệu, ứng dụng điển hình khác là phát hành các chứng chỉ và các danh sách hủy bỏ chứng chỉ (CRLs).

Quá trình xây dựng dữ liệu được ký bao gồm các bước sau:

Đối với mỗi người ký, tóm lược thông điệp, hoặc giá trị băm, được tính toán trên nội dung bằng một thuật toán tóm lược thông điệp đặc trưng cho người ký. Nếu người ký ký một thông tin bất kỳ khác với nội dung, thì tóm lược thông điệp của nội dung và thông tin khác lại được tóm lược bằng thuật toán tóm lược thông điệp của người ký (xem điều B.5.4), và kết quả là “tóm lược thông điệp”.

Với mỗi người ký, tóm lược thông điệp là được ký số nhờ khoá riêng của người ký.

...

...

...

Các thuật toán tóm lược thông điệp cho tất cả những người ký và các giá trị signerInfo cho tất cả mọi người ký được thu thập cùng với nội dung thành một giá trị signedData, như được định nghĩa trong điều B.5.1.

Người nhận tính toán tóm lược thông điệp một cách độc lập. Tóm lược thông điệp này và khoá công khai của người ký được sử dụng để kiểm tra giá trị chữ ký. Khoá công khai của người ký được tham chiếu tới hoặc bằng tên phân biệt người phát hành cùng với số seri đặc trưng của người phát hành hoặc bằng định danh khoá chủ thể giúp định danh một cách duy nhất chứng chỉ chứa khoá công khai. Chứng chỉ của người ký có thể được đưa vào trong trường chứng chỉ của SignedData.

Mục này được chia làm 6 phần. Phần đầu mô tả kiểu mức cao cao nhất signedData, phần thứ hai mô tả EncapsulatedContentInfo, phần thứ ba mô tả kiểu thông tin theo từng người ký SignerInfo, và các phần thứ tư, năm và sáu mô tả cách tính tóm lược thông điệp, các quá trình sinh chữ ký và kiểm tra chữ ký.

B.5.1  Kiểu SignedData

Định danh đối tượng xác định kiểu nội dung dữ liệu được ký:

Kiểu nội dung signed-data sẽ có kiểu ASN.1 SignedData:

Các trường của kiểu SignedData có các ý nghĩa sau:

...

...

...

digestAlgorithms là tập hợp của các định danh thuật toán tóm lược thông điệp. Một số bất kỳ của các phần tử có thể có trong tập hợp, kể cả 0. Mỗi phần tử định danh một thuật toán tóm lược thông điệp, cùng với các tham số tương ứng bất kỳ, được sử dụng bởi một hoặc nhiều những người ký. Tập hợp nhằm liệt kê các thuật toán tóm lược thông điệp được khai thác bởi tất cả những người ký, theo thứ tự nào đó, để thực hiện việc kiểm tra chữ ký một lần. Quá trình tóm lược thông điệp được mô tả ở điều B.5.4.

encapContentInfo là nội dung đã được ký, bao gồm định danh kiểu nội dung và chính bản thân nội dung. Các chi tiết của kiểu EncapsulatedContentInfo sẽ được bàn bạc trong điều B.5.2.

certificates là tập hợp của các chứng chỉ. Đó là tập của các chứng chỉ đủ để chứa các chuỗi từ một “root” hoặc “CA mức cao nhất” được chấp nhận tới tất cả người ký trong trường signerInfos. Có thể có nhiều chứng chỉ hơn mức cần thiết, và có thể có các chứng chỉ đủ để chứa các chuỗi từ hai hay nhiều CA mức cao nhất độc lập. Cũng có thể có ít chứng chỉ hơn cần thiết, nếu những người nhận còn có các cách khác để nhận được các chứng chỉ cần thiết (ví dụ, từ một tập các chứng chỉ trước đó). Như đã được thảo luận ở trên, nếu các chứng chỉ thuộc tính có mặt, thì giá trị của phiên bản sẽ là 3.

crls là một tập hợp của các CRL, là tập chứa thông tin đủ để xác định xem các chứng chỉ trong trường certificates có hợp lệ hay không, nhưng sự tương ứng như vậy là không cần thiết. Có thể có nhiều CRLs hơn và cũng có thể có ít CRLs hơn mức cần thiết.

signerInfos là một tập hợp thông tin theo từng người ký. Tập hợp này có thể có một số bất kỳ các phần tử, bao gồm số 0. Chi tiết về kiểu SignedInfo được thảo luận trong điều B.5.3.

B.5.2  Kiểu EncapsulatedContentInfo

Nội dung được trình bày trong kiểu EncapsulatedContentInfo:

Các trường của kiểu EncapsulatedContentInfo có các ý nghĩa như sau:

...

...

...

eContent là chính bản thân nội dung, được trình bày như một chuỗi octet. eContent không được biểu diễn theo mã định dạng DER.

Bỏ qua tùy chọn của eContent bên trong trường EncapsulatedContentInfo tạo khả năng xây dựng “các chữ ký ngoài”. Trong trường hợp của các chữ ký ngoài, nội dung được ký là không có mặt giá trị EncapsulatedContentInfo trong kiểu nội dung dữ liệu được ký. Nếu giá trị eContent bên trong EncapsulatedContentInfo không có mặt, thì signatureValue được tính và eContentType được gán thông qua giá trị eContent đã có.

Trong trường hợp suy biến, khi không có người ký, giá trị EncapsulatedContentInfo mà “được ký” sẽ không có giá trị. Trong trường hợp này, kiểu nội dung bên trong giá trị EncapsulatedContentInfo mà “được ký” cần phải là id-data (như được định nghĩa trong điều B.4), và trường nội dung của giá trị EncapsulatedContentInfo nên được bỏ qua.

B.5.3  Kiểu SignerInfo

Thông tin theo từng người ký được biểu diễn trong kiểu signerInfo:

Các trường của kiểu SignerInfo có ý nghĩa như sau:

version là số phiên bản cú pháp. Nếu SignerIdentifier là CHOICE issuerAndSerialNumber, thi version sẽ là 1. Nếu SignerIdentifier là subjectKeyIdentifier , thì version sẽ là 3.

sid định ra chứng chỉ của người ký (và do đó khoá công khai của người ký). Khoá công khai của người ký là cần cho người nhận để kiểm tra chữ ký. SignerIdentifier cung cấp 2 lựa chọn để chỉ ra khoá công khai của người ký. Lựa chọn issuerAndSerialNumber chỉ ra chứng chỉ của người ký bằng tên phân biệt của người ký và số seri của chứng chỉ; lựa chọn subjectKeyIdentifier chỉ ra chứng chỉ của người ký bằng giá trị mở rộng X.509 subjectKeyIdentifier.

...

...

...

SignedAttributes là một tập hợp của các thuộc tính được ký. Trường này là tùy chọn, nhưng nó cần phải có mặt nếu kiểu nội dung của giá trị EncapsulatedContentInfo mà được ký không là id- data. Mỗi SignedAttribute trong SET cần phải được mã ở dạng DER. Nếu trường có mặt, nó cần phải chứa ít nhất hai thuộc tính sau:

Thuộc tính content-type có giá trị của kiểu nội dung của giá trị EncapsulatedContentInfo được ký. Điều B.6.1 định nghĩa thuộc tính content-type. Thuộc tính content-type không nhất thiết phải có nếu sử dụng nó như phần của thuộc tính không được ký countersignature định nghĩa ở điều B.6.3.

Thuộc tính message-digest có giá trị là tóm lược thông điệp của nội dung. Điều B.6.2 định nghĩa thuộc tính message-digest.

signatureAlgorithm xác định thuật toán chữ ký và các tham số liên quan nào đó, được người ký sử dụng để sinh ra chữ ký số.

signature là kết quả của việc sinh chữ ký số nhờ tóm lược thông báo và khoá riêng của người ký.

unsignedAttribtes là một tập hợp của các thuộc tính mà không được ký. Trường này là tùy chọn. Các kiểu thuộc tính hữu ích, chẳng hạn như countersignatures, được định nghĩa trong điều B.6.

Các trường của kiểu SignedAttributes và UnsignedAttributes có ý nghĩa như sau:

attrType chỉ ra kiểu của thuộc tính. Nó là định danh đối tượng.

attrValues là một tập của các giá trị mà tạo nên thuộc tính. Kiểu của mỗi giá trị trong tập có thể được xác định duy nhất bởi attrValue.

...

...

...

Quá trình tính lược thông điệp tính tóm lược thông điệp trên nội dung được ký hoặc trên nội dung cùng với các thuộc tính đã được ký. Trong cả hai trường hợp, đầu vào khởi tạo cho quá trình tính tóm lược thông điệp là “giá trị” của nội dung bọc được ký. Đặc biệt, đầu vào khởi tạo là encapContentInfo eContent OCTET STRING mà quá trình ký được áp dụng vào. Chỉ có các octet tạo nên giá trị của eContent OCTET STRING là đầu vào cho thuật toán tóm lược thông điệp, còn các thẻ và octet độ dài thì không.

Kết quả của quá trình tính tóm lược thông điệp phụ thuộc vào việc trường signedAttributes có mặt hay không. Khi trường này vắng mặt, kết quả chỉ là tóm lược thông điệp của nội dung như đã được mô tả ở trên. Khi trường này có mặt, kết quả là tóm lược thông điệp của mã DER đầy đủ của giá trị SignedAttributes chứa trong trường signedAttributes. Vì giá trị SignedAttributes khi có mặt cần phải chứa kiểu nội dung và các thuộc tính tóm lược thông điệp nội dung nên các giá trị này được trực tiếp đưa vào trong kết quả. Thuộc tính kiểu nội dung không được yêu cầu khi được sử dụng như phần của thuộc tính không được ký countersignature như được định nghĩa trong điều B.6.3. Mã định dạng tách biệt của trường signedAttributes được dùng cho việc tính tóm lược thông điệp.

Thẻ IMPLICIT [0] trong trường signedAttributes không được sử dụng cho mã DER, thay vào đó thẻ EXPLICIT SET OF được sử dụng. Tức là mã DER của thẻ SET OF, thay cho của thẻ IMPLICIT [0], được đưa vào trong việc tính tóm lược thông điệp cùng với các octet độ dài và nội dung của giá trị SignedAttributes.

Khi trường signedAttributes vắng mặt, thì chỉ có các octet tạo nên giá trị của signedData encapContentInfo eContent OCTET STRING (ví dụ, các nội dung của một tệp) là đầu vào của việc tính tóm lược thông điệp. Điều này có ưu thế rằng độ dài của nội dung được ký không cần phải được biết trước quá trình sinh chữ ký.

Mặc dù thẻ encapContentInfo eContent OCTET STRING và các octet độ dài không được đưa vào trong việc tính tóm lược thông điệp nhưng chúng vẫn được bảo vệ bởi các phương thức khác. Các octet độ dài được bảo vệ bởi bản chất của thuật toán tóm lược thông điệp vì nó là không thể tính toán được để tìm hai thông điệp khác nhau bất kỳ có độ dài tùy ý mà có cùng một tóm lược thông điệp.

B.5.5  Quá trình sinh chữ ký thông điệp

Đầu vào của quá trình sinh chữ ký bao gồm kết quả của quá trình tính tóm lược thông điệp và khoá riêng của người ký. Các chi tiết của quá trình sinh chữ ký phụ thuộc vào thuật toán chữ ký được khai thác. Định danh đối tượng cùng với các tham số bất kỳ mà định ra thuật toán ký được khai thác bởi người ký là được đưa vào trong trường signatureAlgorithm. Giá trị chữ ký đã được sinh ra bởi người ký được mã định dạng như là OCTET STRING và được đưa vào trong trường signature.

B.5.6  Quá trình kiểm tra chữ ký thông điệp

Đầu vào của quá trình kiểm tra chữ ký thông điệp bao gồm kết quả của quá trình tính tóm lược thông điệp và khoá công khai của người ký. Người nhận có thể nhận được khoá công khai đúng đối với người ký bằng các cách bất kỳ, nhưng phương pháp được ưu tiên là từ chứng chỉ đã nhận được từ trường ceritificates của signedData. Việc lựa chọn và kiểm tra tính hợp lệ của khoá công khai của người ký có thể dựa trên việc kiểm tra tính hợp lệ đường dẫn chứng thực cũng như ngữ cảnh bên ngoài khác, nhưng không thuộc phạm vi của phụ lục này. Các chi tiết của việc kiểm tra chữ ký phụ thuộc vào thuật toán chữ ký được khai thác.

...

...

...

B.6  Các thuộc tính hữu ích

Điều này định nghĩa các thuộc tính có thể được sử dụng với dữ liệu được ký. Các thuộc tính không được liệt kê theo một thứ tự cụ thể.

B.6.1  Content Type

Kiểu thuộc tính content-type chỉ ra kiểu nội dung của giá trị Contentinfo mà được ký trong dữ liệu được ký. Kiểu thuộc tính content-type được yêu cầu nếu có mặt một thuộc tính được xác thực bất kỳ.

Thuộc tính content-type phải là thuộc tính được ký hoặc thuộc tính được xác thực; nó không thể là thuộc tính không được ký, thuộc tính không được xác thực hoặc thuộc tính không được bảo vệ.

Định danh đối tượng sau định ra thuộc tính content-type:

Các giá trị của thuộc tính kiểu nội dung có kiểu ASN.1 ContentType:

ContentType ::= OBJECT IDENTIFIER

...

...

...

Mỗi một cú pháp SignedAttributes và AuthAttribute đều được định nghĩa như là SET OF Attributes. SignedAttributes trong signerInfo cần không bao gồm đa giá trị của thuộc tính content-type. Tương tự, AuthAttributes trong AuthenticatedData cần phải không bao gồm đa giá trị của thuộc tính content - type.

B.6.2  Tóm lược thông điệp

Kiểu thuộc tính message-digest chỉ ra tóm lược thông điệp của encapContenInfo eContent OCTET STRING được ký trong signed-data (xem điều B.5.4). Đối với signed-data, tóm lược thông điệp được tính bằng thuật toán tóm lược thông điệp của người ký. Kiểu thuộc tính được ký message-digest được yêu cầu nếu các thuộc tính bất kỳ có mặt.

Thuộc tính message-digest phải là thuộc tính được ký, nó không thể là thuộc tính không được ký. Định danh đối tượng sau chỉ ra thuộc tính message-digest:

Các giá trị thuộc tính message-digest có kiểu ASN.1 MessageDigest:

MessageDigest ::= OCTET STRING

Thuộc tính messge-digest cần phải có giá trị thuộc tính đơn lẻ, mặc dù cú pháp được định nghĩa như là SET OF AttributeValue. Cần không phải là không có hoặc đa giá trị của AttributeValue có mặt.

Cú pháp SignedAttributes được định nghĩa như là SET OF Attributes. SignedAttributes trong signerInfo cần phải không bao gồm đa thể hiện của thuộc tính message-digest.

...

...

...

Kiểu thuộc tính countersignature chỉ ra một hoặc nhiều chữ ký trên các octet của các nội dung của dạng mã DER của trường signatureValue của giá trị signerInfo trong signed-data. Cho nên, kiểu thuộc tính countersignature ký tiếp chữ ký khác (ký kế tiếp).

Thuộc tính countersignature cần phải là thuộc tính không được ký, nó không thể là thuộc tính được ký.

Định danh đối tượng sau chỉ ra thuộc tính Countersignature :

Các giá trị Countersignature có cùng ý nghĩa như các giá trị signerInfo đối với các chữ ký bình thường, ngoại trừ rằng:

Trường signedAttributes cần phải chứa thuộc tính message-digest nếu nó chứa một thuộc tính khác bất kỳ, nhưng không cần chứa thuộc tính content-type, vì không có kiểu nội dung cho Countersignature.

Đầu vào của quá trình tóm lược thông điệp là các octet nội dung có dạng mã DER của trường signatureValue của giá trị signerInfo mà thuộc tính liên kết với.

Thuộc tính countersignature có thể có nhiều giá trị thuộc tính. Cú pháp được định nghĩa như là SET OF AttributeValue, và cần phải có một hoặc nhiều giá trị của AttributeValue có mặt.

Cú pháp UnsignedAttributes được định nghĩa như là SET OF Attributes. UnsignedAttributes trong signerInfo nên có thể bao gồm đa giá trị của thuộc tính countersignature.

...

...

...

Tài liệu tham khảo

[RFC2459] IETF RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile (Hồ sơ CRL và Chứng chỉ theo Hạ tầng cơ sở khóa công khai X.509 Internet).

[RFC3161] IETF RFC 3161: Internet X.509 Public Key Intrastructure Time-Stamp Protocol (TSP) (Giao thức tem thời gian theo Hạ tầng cơ sở khóa công khai X.509 Internet).