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

 TIÊU CHUẨN QUỐC GIA

TCVN 7818-1 : 2007
ISO/IEC 18014-1 : 2002

CÔNG NGHỆ THÔNG TIN - KỸ THUẬT MẬT MÃ
DỊCH VỤ TEM THỜI GIAN - PHẦN 1: KHUNG TỔNG QUÁT

Information technology - Cryptographic technique
Stamping services - Part 1: Framework

Mục lục

Lời nói đầu

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ và định nghĩa

4  Thảo luận chung về tem thời gian

4.1  Các thực thể tham gia vào quá trình gắn tem thời gian

4.2  Tem thời gian

4.3  Sử dụng tem thời gian

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

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

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

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

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

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

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

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

6.3  Kiểm tra tem thời gian

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

Phụ lục A

Phụ lục B

B.1  Giới thiệu

B.2  Tổng quan

B.3  Cú pháp chung

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

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

B.5.1  Kiểu SignedData

B.5.2  Kiểu EncapsulatedContentInfo

B.5.3  Kiểu SignerInfo

B.5.4  Quá trình tính tóm lược thông điệp

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

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

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

B.6.1  Content Type

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

B.6.3  Kiểu Countersignature

Tài liệu tham khảo

Lời nói đầu

TCVN 7818-1 : 2007 hoàn toàn tương đương với ISO/IEC 18014-1 : 2002

TCVN 7818-1 : 2007, Tiểu ban Kỹ thuật Tiêu chuẩn TCVN/JTC1/SC27 “Các kỹ thuật mật mã” biên soạn, Ban Cơ yếu Chính phủ đề nghị, Bộ Khoa học và Công nghệ công bố.

CÔNG NGHỆ THÔNG TIN - KỸ THUẬT MẬT MÃ - DỊCH VỤ TEM THỜI GIAN
PHẦN 1: KHUNG TỔNG QUÁT

Information technology - Cryptographic technique
Time-stamping services - Part 1: Framework

1  Phạm vi áp dụng

Tiêu chuẩn này:

Xác định đối tượng xác thực của tem thời gian

Mô tả mô hình tổng quát của dịch vụ cung cấp tem thời gian

Định nghĩa dịch vụ cung cấp tem thời gian

Định nghĩa các thủ tục cơ bản của quá trình gắn Tem thời gian

Thiết lập các thủ tục giữa các thực thể liên quan.

2  Tài liệu viện dẫn

Các tài liệu viện dẫn dưới đây rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu không ghi năm công bố thì áp dụng bản mới nhất, bao gồm cả các sửa đổi.

ISO 8601:2000, Data elements and interchange formats - information interchange - Representation of datas and times (Các phần tử dữ liệu và khuôn dạng trao đổi - Trao đổi thông tin - Biểu diễn dữ liệu và thời gian);

ISO/IEC 8824 - 1: 1998/ X.680: ITU -T Recommendation X.680 (1997), Infomation technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (Đề xuất X.680 (1997), Công nghệ thông tin - Ký hiệu cú pháp trừu tượng 1 (ASN.1): Quy định phép biểu diễn cơ sở);

ISO/IEC 8824 - 2: 1998/ X.681: ITU -T Recommendation X.680 (1997), Information technology - Abstract Syntax Notation One (ASN.1): Information object Specification (Đề xuất X.680 (1997), Công

nghệ thông tin - Ký hiệu cú pháp trừu tượng 1 (ASN.1): Quy định đối tượng thông tin);

ISO/IEC 8824 - 3: 1998/ X.682: ITU -T Recommendation X.680 (1997), Infomation technology - Abstract Syntax Notation One (ASN.1): Constraint specification (Đề xuất X.680 (1997), Công nghệ thông tin - Ký hiệu cú pháp trừu tượng 1 (ASN.1): Quy định các ràng buộc);

ISO/IEC 8824 - 4: 1998/ X.683: ITU -T Recommendation X.680 (1997), Infomation technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specification (Đề xuất X.680 (1997), Công nghệ thông tin - Ký hiệu cú pháp trừu tượng 1 (ASN.1): Tham số hóa các quy định ASN.1);

ISO/IEC 8825 - 1: 1998/ X.690: ITU -T Recommendation X.690 (1997), Infomation technology-ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Đề xuất X.690 (1997) (Công nghệ thông tin - Các quy tắc mã định dạng ASN.1: Quy định các Quy tắc mã cơ sở (BER), Quy tắc mã chính tắc (CER) và Các quy tắc mã phân biệt (DER));

ISO/IEC 9798 - 1 : 1997 Information technology - Security techniques - Entity authentication - Part 1:general (Công nghệ thông tin - Kỹ thuật mật mã - xác thực thực thể - Phần 1: Mô tả chung);

ISO/IEC 10118 (all parts), Information technology - Security techniques - Hash - fuctions ((tất cả các phần) Công nghệ thông tin - Kỹ thuật mật mã - Hàm băm);

ISO/IEC 11770 - 1 : 1997 Information technology - Security techniques - Key management - Part 1: Framework (Công nghệ thông tin - Kỹ thuật mật mã - Quản lý khóa - Phần 1: Khung tổng quát);

ISO/IEC 11770 - 3: 1996 Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques (Công nghệ thông tin - Kỹ thuật mật mã - Quản lý khóa - Phần 3: Cơ chế sử dụng kỹ thuật mật mã không đối xứng);

ISO/IEC 14888 - 2: 1999 Information technology - Security techniques - Digital signatures with appendix - Part 2: Identity -base mechanisms (Công nghệ thông tin - Kỹ thuật mật mã - Chữ ký số gắn kèm thông báo - Phần 2: Cơ chế dựa trên định danh);

ISO/IEC 14888 - 3: 1999 Information technology - Security techniques - Digital signatures with appendix - Part 3: Certificate - base mechanisms (Công nghệ thông tin - Kỹ thuật mật mã - Chữ ký số gắn kèm thông báo - Phần 3: Cơ chế dựa trên chứng chỉ);

ISO/IEC 15946 - 2; Information technology - Security techniques - Cryptographic techniques based on ellptic curves (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 - Phần 2: Chữ ký số);

TCVN 7635 ; 2007 Kỹ thuật mật mã - Chữ ký số.

3  Thuật ngữ và định nghĩa

Các thuật ngữ sau đây đã được định nghĩa trong iSO/IEC 9798-1:

Xác thực thực thể (entity authentication): Khẳng định rằng một thực thể đúng là đối tượng được yêu cầu.

Các thuật ngữ sau đây đã được định nghĩa trong ISO/IEC 10118-1:

Hàm băm kháng va chạm (collision-resistant hash-function): Một hàm băm thỏa mãn đặc tính sau: Không thể tính toán để tìm được hai đầu vào khác biệt mà có ánh xạ đầu ra giống nhau.

Giá trị băm (hash value): Chuỗi bít đầu ra của một hàm băm.

Các thuật ngữ sau đây đã được định nghĩa trong TCVN 7817 - 1: 2007:

Cơ quan chứng thực (certification authority - CA): Một trung tâm tin cậy tạo ra và phân phối các chứng chỉ khóa công khai. Ngoài ra, CA có thể tạo và phân phối các khóa cho các thực thể.

Khóa riêng (private key): Một khóa trong cặp khóa phi đối xứng của thực thể và chỉ được sử dụng bởi thực thể đó.

Khóa công khai (public key): Một khóa trong cặp khóa phi đối xứng của thực thể và được công bố công khai.

Chứng chỉ khóa công khai (public key certificate): Thông tin về khóa công khai của một thực thể được ký bởi một cơ quan chứng thực vì thế chống được sự giả mạo.

Số tuần tự (sequence number): Tham số biến thiên theo thời gian mà giá trị của nó được nhận từ một dãy số và không có sự lặp lại trong một khoảng thời gian xác định.

Tem thời gian (time stamp): Một tham số biến thiên theo thời gian xác định một thời điểm trong một hệ tham chiếu về thời gian thông dụng.

Tham số biến thiên theo thời gian (time-variant parameter): Một mục dữ liệu được một thực thể dùng để kiểm tra rằng một thông điệp là không bị sử dụng lại. Nó có thể là một số ngẫu nhiên, một số tuần tự hoặc là một tem thời gian.

Các thuật ngữ sau đây đã được định nghĩa trong TCVN 7817-3 : 2007:

Bên thứ ba tin cậy (Trusted third party - TTP): Một tổ chức có thẩm quyền về an toàn hoặc đại diện của nó được các thực thể khác tin tưởng trong lĩnh vực hoạt động liên quan tới an toàn.

Các thuật ngữ sau đây đã được định nghĩa trong TCVN 7635 : 2007:

Hàm băm (hash function)

Một thuật toán chuyển đổi mỗi thông điệp biểu diễn dưới dạng bít có độ dài bất kỳ thành một chuỗi bit có độ dài cố định. Chuỗi bit có độ dài cố định đó được gọi là “giá trị băm”, “mã băm”, hay đơn giản là “tóm lược” của thông điệp đầu vào. Các thuật toán băm mật mã được thiết kế sao cho thoả mãn các tính chất sau:

1. Tính một chiều hay tính kháng tiền ảnh: Không thể tìm được trong thời gian cho phép một thông điệp có giá trị băm cho trước;

2. Tính kháng tiền ảnh thứ hai: Cho trước thông điệp M1, không thể tìm được trong thời gian cho phép một thông điệp M2 khác M1 sao cho giá trị băm của M1 và M2 là như nhau;

3. Tính kháng xung đột: Không thể tìm được hai chuỗi bít khác nhau có cùng một giá trị băm.

Chữ ký số (digital signature)

Là một chuỗi số, kết quả của phép biến đổi mật mã trên thông điệp dữ liệu nhằm cung cấp một phương tiện để kiểm tra tính xác thực của nguồn gốc thông điệp dữ liệu, tính toàn vẹn của dữ liệu và tính không thể chối bỏ của người đã ký.

Tiêu chuẩn này áp dụng các thuật ngữ định nghĩa sau:

3.1

Biểu diễn của các mục dữ liệu (data items' representation)

Một mục dữ liệu hoặc một biểu diễn nào đó từ dữ liệu, ví dụ như một giá trị băm mật mã của dữ liệu.

3.2

Tổ chức cấp tem thời gian (time-stamping authority - TSA)

Bên thứ ba được tin cậy để cung cấp dịch vụ tem thời gian

3.3

Dịch vụ tem thời gian (time -stamping service)

Dịch vụ cung cấp bằng chứng rằng một mục dữ liệu đã tồn tại trước một thời điểm xác định.

CHÚ THÍCH: Một ví dụ của dịch vụ tem thời gian là bổ sung tem thời gian vào một biểu diễn các mục dữ liệu và ký kết quả.

3.4

Người yêu cầu cấp tem thời gian (time-stamp requester)

Thực thể sở hữu dữ liệu muốn được gắn tem thời gian.

CHÚ THÍCH: Người yêu cầu cũng có thể là Bên thứ ba tin cậy kể cả Tổ chức cấp tem thời gian.

3.5

Thẻ tem thời gian (time- stamp token)

Cấu trúc dữ liệu chửa một liên kết mật mã có khả năng kiểm tra được giữa biểu diễn của một mục dữ liệu và một giá trị thời gian. Một thẻ tem thời gian cũng có thể có cả các mục dữ liệu bổ sung thêm trong quá trình liên kết.

3.6

Người kiểm tra tem thời gian (time-stamp verifier)

Thực thể sở hữu dữ liệu và muốn kiểm tra rằng dữ liệu đó được gắn một tem thời gian hợp lệ. Tiến trình kiểm tra có thể được thực hiện bởi bản thân người kiểm tra hoặc thông qua bên thứ ba được tin tưởng.

4  Thảo luận chung về tem thời gian

Việc dữ liệu số dễ dàng bị sửa đổi trên các phương tiện lưu trữ đặt ra yêu cầu là bằng cách nào có thể kiểm chứng được khi nào dữ liệu này đã được tạo ra hoặc được thay đổi lần cuối cùng. Việc gắn tem thời gian số sẽ cung cấp sự trợ giúp để có thể chứng minh tính đúng thời điểm. Việc gắn tem thời gian số phải đáp ứng đầy đủ các yêu cầu dưới đây:

Một tham số biến thiên theo thời gian phải được liên kết chặt chẽ với dữ liệu theo cách không thể giả mạo nhằm cung cấp bằng chứng rằng dữ liệu đó đã tồn tại trước một thời điểm xác định.

Dữ liệu có thể được cung cấp theo cách mà nó không bị lộ.

Các phương pháp gắn tem thời gian đang được dùng đáp ứng các yêu cầu trên thông qua việc gắn tem thời gian vào giá trị băm của dữ liệu. Điều đó cho phép kiểm soát được tính toàn vẹn và tính bí mật của dữ liệu, còn chính bản thân dữ liệu không bị lộ. Giá trị băm của dữ liệu sẽ được liên kết mật mã với giá trị thời gian hiện tại bởi Tổ chức cấp tem thời gian (TSA). Sự liên kết này minh chứng cho tính toàn vẹn và xác thực của tem thời gian. Một thẻ tem thời gian cung cấp các thành phần trên sẽ được gửi cho người yêu cầu cấp tem thời gian.

Các thẻ tem thời gian cũng có thể bao gồm thông tin liên quan đến các thẻ được sinh ra trước đó. Vấn đề này liên quan đến các cơ chế tạo tem thời gian có liên kết sẽ được đề cập ở Phần 3 của bộ tiêu chuẩn về Tem thời gian.

4.1  Các thực thể tham gia vào quá trình gắn tem thời gian

Các thực thể dưới đây có thể tham gia vào quá trình gắn tem thời gian:

Thực thể sở hữu dữ liệu mà dữ liệu đó muốn được gắn tem thời gian, tức muốn có bằng chứng về sự tồn tại của dữ liệu tại một thời điểm nhất định. Lúc này thực thể đó đóng vai trò là người yêu cầu (requester) một tem thời gian. Một thực thể có thể chứng minh rằng dữ liệu đã được gắn tem thời gian mà thực thể đó nhận được có một tem thời gian hợp lệ, thực thể đó đóng vai trò như là người kiểm tra (verifier) tem thời gian.

Tổ chức cấp tem thời gian (TSA) cung cấp dịch vụ gắn tem thời gian. Bản chất của dịch vụ này là có độ nhạy cảm cao vì nó giúp xác minh được tính đúng thời điểm của dữ liệu và đặc biệt tính đúng đắn của các phần từ mật mã liên quan đến các dữ liệu này. TSA cung cấp bằng chứng chứng minh rằng dữ liệu đã tồn tại tại một thời điểm nhất định và đảm bảo tính chuẩn xác của tham số thời gian.

Tất cả các thực thể đã được giới thiệu liên lạc với nhau theo một giao thức bắt tay hai chiều. Điều đó có nghĩa là một thực thể gửi một yêu cầu tới TSA và nhận một tem thời gian (xem chi tiết trong điều 5.1 và điều 5.2). Thẻ tem thời gian phải chứa một lượng thông tin đủ để cho phép một thực thể có thể kiểm tra tại một thời điểm sau đó.

4.2  Tem thời gian

Tem thời gian được sử dụng để đưa ra một bằng chứng về sự tồn tại của dữ liệu tại một thời điểm cụ thể. Điều này có thể được thực hiện thông qua việc liên kết mật mã tem thời gian với một biểu diễn của mục dữ liệu.

Dữ liệu được gắn tem thời gian có thể được gắn tiếp tem thời gian một lần nữa tại một thời điểm sau đó. Điều này là cần thiết trong các trường hợp sau:

Mật mã nguyên thủy được sử dụng để liên kết giá trị thời gian với dữ liệu gần đến thời điểm kết thúc thời gian sử dụng (ví dụ khóa dùng để ký của TSA sắp hết hạn).

TSA có thể sắp được thay bởi một TSA khác.

Thuật toán băm của người yêu cầu cần phải xem xét lại.

Bởi vậy dữ liệu đã được gắn tem thời gian bởi một TSA tương ứng có thể nhận được một tem thời gian cấp để đạt tới bất kỳ một trong các điều kiện ở trên. Bằng cách này thời hạn hợp lệ của tem thời gian đang tồn tại được kéo dài.

Dữ liệu có thể được gắn lại tem thời gian trước khi mật mã nguyên thủy được dùng để liên kết thời gian, các giá trị băm và các tham số tùy chọn khác cùng gần hết thời hạn hoạt động. Tem thời gian được sinh ra sau đó là một tem thời gian mới không có một mối liên hệ nào với các tem thời gian cũ có liên quan đến dữ liệu và nó được gọi là việc cấp lại tem thời gian.

Việc cấp lại tem thời gian cũng có thể là cần thiết khi hàm băm được dùng để tạo ra giá trị băm từ dữ liệu ban đầu có vấn đề cần phải xem xét lại. Trong trường hợp này, cả thẻ tem thời gian cũ và dữ liệu ban đầu phải được bao hàm trong giá trị băm được tính được đệ trình để để phục vụ cho việc cấp lại tem thời gian.

Dịch vụ cấp tem thời gian có thể vận hành trực tuyến và không trực tuyến (ví dụ như giao thức lưu lại sau đó chuyển tiếp), sự khác biệt được thể hiện ở mức vận chuyển của các giao thức truyền thông giữa các thực thể tham gia.

4.3  Sử dụng tem thời gian

Một tem thời gian không thể hiện thời điểm chính xác khi một tài liệu điện tử đã được sinh ra, bị thay đổi hay thậm chí được ký. Thực thể cung cấp tài liệu để gắn tem thời gian có thể ký tài liệu đó một cách độc lập với TSA, trong khi TSA liên kết mật mã một giá trị thời gian với giá trị băm của một tài liệu đã được ký.

Điều đó chỉ chứng minh rằng tài liệu đã tồn tại trước khi tem thời gian được gắn vào.

Các tem thời gian cũng đóng một vai trò quan trọng đối với tính hợp lệ của các tài liệu được ký. Có ba khả năng khác nhau về thời điểm khi thực hiện việc gắn tem thời gian và việc ký dữ liệu có thể xảy ra. Điều này dẫn đến các kết quả khác nhau khi xem xét tính hợp lệ về thời gian của chữ ký. Bảng 1 mô tả các trường hợp đó.

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.

Thời gian được cung cấp phải đáp ứng yêu cầu chung về tính chính xác; dịch vụ cung cấp thời gian cho TSA nằm ngoài phạm vi của tiêu chuẩn này.

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

Chỉ hai thành phần đầu tiên là bắt buộc, thành phần thứ ba là tùy chọn.

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:

Bảng sau giải thích các biến và các giá trị của chúng

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.

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.

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:

Thêm vào đó, trường eContent chứa cấu trúc TSTInfo, nó được mã theo DER như một chuỗi octet.

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à

ss biểu diễn các giây của phút (00-59)

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

6.4.1  Mở rộng ExtHash

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:

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 TimeStampToken kết quả được tạo ra bởi TSA và được trả về cho người yêu cầu.

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ã

Phụ lục dưới đây là một phần của Cú pháp thông điệp mật mã RFC 2630 CMS giới thiệu một số kiểu nội dung cần thiết cho việc gắn tem thời gian. Nó bao gồm những định nghĩa tương ứng được đưa ra trong RFC 2630. Cú pháp ASN.1 sử dụng một số tiêu chuẩn hiện hành đã được tham chiếu trong mục 2 của Tiêu chuẩn này.

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

CMS liên kết định danh kiểu nội dung với nội dung. Cú pháp sẽ có kiểu ASN.1 ContentInfo:

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

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

Định danh đối tượng dưới đây xác định 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ý.

Đối với mỗi người ký, giá trị chữ ký và thông tin khác đặc trưng cho người ký được thu thập vào một giá trị signerInfo, như được định nghĩa trong điều B.5.3. Những chứng chỉ và những CRL cho mỗi người ký, những thông tin không liên quan với bất kỳ người ký nào sẽ cũng được thu thập trong bước này.

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:

version là số phiên bản của cú pháp. Nếu các chứng chỉ thuộc tính không có mặt trong trường certificates, kiểu nội dung được bọc là id-data, và tất cả các phần tử của SignerInfos là phiên bản 1, thì giá trị của version sẽ là 1. Ngược lại, nếu các chứng chỉ thuộc tính có mặt, kiểu nội dung được bọc là khác với id-data, hoặc bất kỳ một phần tử nào trong số các signerInfos là phiên bản 3, thì giá trị của phiên bản sẽ là 3.

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:

eContentType là định danh đối tượng xác định một cách duy nhất kiểu nội dung.

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.

digestAlgorithm xác định thuật toán tóm lược thông điệp, và các tham số tương ứng, được sử dụng bởi người ký. Tóm lược thông điệp được tính hoặc trên nội dung được ký hoặc nội dung cùng với các thuộc tính được ký nhờ quá trình được mô tả trong điều B.5.4. Thuật toán tóm lược thông điệp cần phải ở trong danh sách các thuật toán được liệt kê trong trường digestAlgorithms của SignerData tương ứng.

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.

B.5.4  Quá trình tính tóm lược thông điệp

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.

Người nhận có thể không dựa vào giá trị tóm lược thông điệp bất kỳ đã được tính bởi người khởi gửi. Nếu signerInfo của signedData bao gồm signedAttributes, thì tóm lược thông điệp của nội dung cần phải được tính như đã được mô tả trong điều B.5.4. Để cho chữ ký là hợp lệ, giá trị tóm lược thông điệp đã được tính bởi người nhận cần phải giống như giá trị của thuộc tính messageDigest đã được đưa vào trong signedAttributes của signedData signerInfo.

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ột thuộc tính content-type cần có một giá trị thuộc tính đơn lẻ, mặc dù cú pháp được định nghĩa như SET OF AttributeValue. Giá trị của AttributeValue phải khác 0 và không được đa giá trị.

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.

B.6.3  Kiểu Countersignature

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.

Một countersignature, vì nó có kiểu signerInfo, tự nó có thể chứa một thuộc tính countersignature. Vì thế có thể xây dựng một loạt tùy ý của các countersignatures.

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