TÌM HIỂU VỀ XÂY DỰNG ĐƯỜNG DẪN CHỨNG THỰC

HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA AN TOÀN THÔNG TIN

BÁO CÁO ĐỀ TÀI MÔN HỌC
CHỨNG THỰC ĐIỆN TƯ
TÌM HIỂU VỀ XÂY DỰNG ĐƯỜNG DẪN CHỨNG THỰC

Gv hướng dẫn:Hoàng Đức Tho
Sinh viên tham gia :
Lớp
:

HÀ NỘI 2/2016

1
Nhóm 1 – AT9A – HV kỹ thuật mật mã


LỜI MỞ ĐẦU
Với sự phát triển mạnh mẽ của công nghệ thông tin và truyền thông
(CNTT&TT), việc từng bước xây dựng chính phủ điện tử đã trở nên tất yếu tại
nhiều quốc gia trên thế giới. Tại Việt Nam, chủ trương xây dựng Chính phủ điện
tử và ứng dụng CNTT trong các hoạt động của Đảng, Nhà nước đang từng bước
được cụ thể hóa bằng các chính sách, các văn bản quy phạm pháp luật, các đề
án, dự án và các chương trình trọng điểm quốc gia về ứng dụng CNTT.
Cùng với chủ trương đó, vấn đề đảm bảo an toàn thông tin trong các giao
dịch điện tử, với cốt lõi là hệ thống chứng thực điện tử là nhiệm vụ hết sức quan
trọng.
Chứng thực điện tử đang là giải pháp quan trọng nhất để bảo đảm bí mật,
xác thực và toàn vẹn dữ liệu trong các giao dịch điện tử phục vụ hoạt động điều
hành của Chính phủ, đảm bảo quốc phòng - an ninh và các hoạt động kinh tế xã hội. Hầu hết các quốc gia có nền kinh tế, công nghệ phát triển và mức độ sẵn

2
Nhóm 1 – AT9A – HV kỹ thuật mật mã


sàng của Chính phủ điện tử cao (Hàn Quốc, Mỹ, Singapore, Trung Quốc,
Malaysia...) đều đã ứng dụng chứng thực điện tử một cách đồng bộ và rộng rãi.
Giao dịch thực hiện qua mạng được bảo đảm an toàn sẽ góp phần thúc
đẩy ứng dụng CNTT trong cải cách hành chính, điện tử hóa quy trình làm việc,
tiến tới xây dựng Chính phủ điện tử. Các giao dịch truyền thống dựa trên các
văn bản giấy chỉ được thay thế bằng các giao dịch điện tử khi chứng thực điện tử
và chữ ký số được thừa nhận về mặt pháp lýỵ́ và an toàn về mặt công nghệ.
Do thời gian hạn chế cũng như kiến thức và kinh nghiệm về lĩnh vực còn
non trẻ nên trong bài báo cáo không thể không có sai sót mong quý thầy cô góp
ý thêm để nhóm có thể hoàn thiện tốt hơn các đề tài nghiên cứu về sau!
Xin chân thành cảm ơn!

3
Nhóm 1 – AT9A – HV kỹ thuật mật mã


CHƯƠNG 1.

TÌM HIỂU VỀ XÂY DỰNG ĐƯỜNG DẪN CHỨNG

THỰC
1.1

GIỚI THIỆU
Cơ sở hạ tầng an ninh rộng khắp khóa công khai (PKI) hỗ trợ một số các
dịch vụ bảo mật liên quan bao gồm bảo mật dữ liệu, tính toàn vẹn dữ liệu và

xác thực thực thể cuối. Về cơ bản, các dịch vụ này dựa trên việc sử dụng
đúng cặp khóa công khai/bí mật. Các thành phần công khai của cặp khóa
này được phát hành dưới hình thức chứng chỉ khóa công khai kèm theo các
thuật toán thích hợp, nó được sử dụng để xác thực chữ kí số, mã hóa dữ liệu
hoặc cả hai.
Trước khi chứng chỉ được đưa vào sử dụng, thì nó đã được xác nhận. Để
được xác nhận như là một chứng chỉ, một chuỗi chứng chỉ hoặc một đường
dẫn chứng thực giữa chứng chỉ và một điểm tin cậy phải được thành lập.Và
mỗi chứng chỉ trong mỗi đường dẫn phải được kiểm tra. Quá trình này được
gọi là quy trình đường dẫn chứng nhận.
Nói chung,quy trình đường dẫn chứng nhận bao gồm 2 giai đoạn:
1. Xây dựng đường dẫn
2. Xác nhận đường dẫn
Cụ thể được mô tả như sau:
1. Xây dựng đường dẫn: liên quan đến “kiến trúc” một hoặc nhiều đường
dẫn chứng chỉ tiêu biểu. Lưu ý rằng việc chúng ta sử dụng “tiêu biểu”
ở đây là để chỉ ra rằng mặc dù chứng chỉ có thể tạo thành chuỗi, đường
dẫn bản thân nó có thể không hợp lệ vì những lí do khác nhau như là
độ dài đường dẫn, tên hoặc chính sách hạn chế của chứng chỉ
2. Xác nhận đường dẫn: bao gồm việc chắc rằng mỗi chứng chỉ trong
đường dẫn còn thời hạn hiệu lực, chưa bị thu hồi, đảm bảo tính toàn
vẹn, vv…; bất kì ràng buộc nào đánh vào một phần hoặc tất cả các
đường dẫn của chứng chỉ đều được chú trọng (ví dụ: ràng buộc về
chiều dài đường dẫn, ràng buộc tên, ràng buộc về chính sách). Tuy
4
Nhóm 1 – AT9A – HV kỹ thuật mật mã


nhiên ở một số khía cạnh có thể liên quan với việc xác thực đường dẫn
thi thoảng được đưa ra xem xét trong suốt quá trình xây dựng đường

dẫn theo thứ tự để tạo ra được cơ hội lớn nhất có thể tìm được một
1.2

đường dẫn chứng nhận chấp nhận được dù sớm hay muộn.
MỤC ĐÍCH,PHẠM VI,GIẢ THUYẾT
Quy trình xây dựng đường dẫn có thể khá phức tạp và mang tính học

thuật ở một mức độ nào đó của thử nghiệm và lỗi và có rất ít tài liệu hiện có để
thảo luận các vẫn đề liên quan đến quy trình xây dựng đường dẫn chứng
nhận.Vì thế sau đây ta sẽ xem xét để làm rõ các thuật ngữ, xem xét lại các vấn
đề có liên quan đến quy trình xây dựng đường dẫn chứng thực để tạo ra các
khuyến nghị thích hợp. Tuy nhiên, không có nghĩa bắt buộc nhà cung cấp như
thế nào đấy phải thực hiện xây dựng đường dẫn, cũng không phải là chúng ta
đang cố gắng miêu tả một thuật toán xây dựng đường dẫn hoàn chỉnh.Nhà
cung cấp được tự ý thực hiện xây dựng đường dẫn logic của họ khi họ thấy
thích hợp.Tuy nhiên,chương này cung cấp những thông tin hữu ích cần được
đưa vào xem xét khi đánh giá và thực hiện thuật toán xây dựng đường dẫn
chứng nhận.
Ta chỉ tập trung vào version 3 của chứng chỉ khóa công khai theo như
định nghĩa trong ấn bản thứ tư của X.509. Chúng ta thừa nhận rằng các hình
thức khác của chứng chỉ vẫn tồn tại bao gồm version 1 và version 2 của chứng
chỉ khóa công khai đã được định nghĩa ở lần xuất bản X.509 trước đó. Tuy
nhiên,chúng ta chỉ tập trung vào chứng chỉ khóa công khai version 3 vì đó là
những hình thức phổ biến nhất của chứng chỉ được tìm thấy ở hầu hết các
doanh nghiệp và chính phủ, và nhiều phần mở rộng chỉ hỗ trợ với version 3 là
rất cần thiết cho việc kiểm soát các mối quan hệ trong kinh doanh trên miền
PKI. Ta sẽ thảo luận phần mở rộng của chứng chỉ version 3, cái mà được sử
dụng để tạo điều kiện cho quy trình xây dựng đường dẫn chứng thực. Cần lưu
ý rằng những thảo luận này liên quan đến phần mở rộng chứ không áp dụng
vào chứng chỉ khóa công khai version 1 hoặc version 2.

1.3

CÁC KHÁI NIÊM CƠ BẢN
5
Nhóm 1 – AT9A – HV kỹ thuật mật mã


Cấu trúc cơ bản của các chứng chỉ khóa công khai version3 được minh
họa trong hình sau:

Các chứng chỉ được phát hành bởi các nhà cung cấp chứng chỉ (CA) đến
các CA khác hoặc đến các thực thể cuối. (ví dụ: người dùng cuối, các thiết bị,
các web server, các tiến trình). Các CA cũng có thể tự cấp phát chứng chỉ cho
mình.
Các chứng chỉ được cấp phát cho các CA khác được gọi là các chứng chỉ
CA, và các chứng chỉ được cấp phát cho các thực thể cuối được gọi là các chứng
chỉ thực thể cuối. Việc gia hạn chứng chỉ để phân biệt giữa 2 loại chứng chỉ trên.
Ấn bản thứ 4 của X.509 định nghĩa một bên có nhu cầu chứng thực như
“một người dùng hoặc đại lý dựa trên dữ liệu trong chứng chỉ trong việc đưa ra
quyết định”. Nói cách khác, bên có nhu cầu chứng thực sử dụng chúng chỉ thực
thể cuối cho các mục đích rõ ràng. Ví dụ: một người có thể chứng thực một
người gửi thông điệp đến cho mình và xác minh tính toàn vẹn của thông điệp
bằng cách sử dụng chứng chỉ tương ứng với người tạo ra thông điệp để xác minh
1 chữ kí số kết hợp với thông điệp. Một nút cuối tin cậy là một chứng chỉ CA
(hoặc chính xác hơn, khóa xác minh công khai của một CA) được sử dụng bởi
bên có nhu cầu chứng thực như là điểm khởi đầu cho việc xác thực đường dẫn.
Bên có nhu cầu có thể có một hoặc nhiều nút cuối tin cậy bắt nguồn từ một số
nguồn. Ví dụ, một nút cuối tin cậy có thể là khóa công khai của một root CA
hoặc CA cấp phát một hoặc nhiều chứng chỉ trực tiếp đến các bên có nhu cầu.
6

Nhóm 1 – AT9A – HV kỹ thuật mật mã


Một chứng chỉ mà một CA cấp phát cho một CA khác được gọi là một
chứng chỉ chéo (cross-certificate). Một CA cấp cao hơn có thể cấp phát một
chứng chỉ chéo đến một CA cấp dưới như thấy trong các mô hình phân cấp. Nó
được gọi là chửng chỉ chéo một chiều hoặc đơn phương. Khi một CA cấp phát
một chứng chỉ đến các CA khác, nó được gọi là xác thực chéo lẫn nhau hoặc
song phương. Nó thường được tìm thấy trong các môi hình phân phối. Nhưng
lưu ý rằng có nhiều ví dụ trong công nghiệp, thời hạn xác thực chéo để biểu thị
trường hợp song phương duy nhất. Tuy nhiên từ góc độ kĩ thuật, xác thực chéo
có thể là đơn phương. Điều này được nêu ra trong phiên bản thứ 4 của X.509 ,
xác thực chéo được định nghĩa như sau:
Chứng chỉ chéo: là một chứng chỉ được phát hành bởi các nhà phân phối
và đối tượng là các CA khác. Các CA phát hành các chứng chỉ đến các
CA khác như một cơ chế cho phép các đối tượng CA tồn tại (trong mô
hình phân cấp nghiêm ngặt) hoặc để nhận ra sự tồn tại của chúng (trong
mô hình phân phối). Cấu trúc chứng chỉ chéo được sử dụng cho cả hai
mô hình trên.
Việc xây dựng đường dẫn chứng thực liên quan đến việc phát hiện ra một
chuỗi chứng chỉ giữa chứng chỉ thực thể cuối và nút cuối tin cậy được công
nhận. Các đường dẫn xác thực có thể được xây dựng theo chiều thuận ( tức là từ
chứng chỉ thực thể cuối đến nút cuối tin cậy) phù hợp cho các mô hình phân cấp
tin cậy hoặc ngược lại (từ nút cuối tin cậy đến chứng chỉ thực thể cuối) phù hợp
cho mô hình phân phối tin cậy. Và bài viết này sẽ chứng minh rằng một thuật
toán xây dựng đường dẫn mạnh mẽ có khả năng xây dựng đường dẫn theo cả 2
chiều. Trong thực tế nó phù hợp để xây dựng các phần của một đường dẫn
chứng thực sử dụng một phương pháp và các phần khác của việc chứng thực sử
dụng phương pháp khác.
Trước khi chúng ta bắt đầu xem xét các vấn đề liên quan đến quá trình

xây dựng đừng dẫn chứng thực ta xẽ tìm hiểu một số nguyên tắc cơ bản đường
sau khái niệm “certificate chaining”
7
Nhóm 1 – AT9A – HV kỹ thuật mật mã


1.3.1

Name chaining

Ở cấp độ cơ bản nhất, một đường dẫn chứng thực phải có “name chain”
giữa nút cuối tin cậy được công nhận và chứng chỉ mục tiêu (ví dụ: chúng chỉ
thực thể cuối). Làm việc từ nút cuối tin cậy đến chứng chỉ mục tiêu, có nghĩa là
tên đối tượng trong một chứng chỉ phải là tên nhà phát hành trong chứng chỉ tiếp
theo trong đường dẫn. Hình 3 sẽ mô tả khái niệm này:

Trong ví dụ này, đường dẫn bắt đầu với một chứng chỉ tự kí có chứa khóa
công khai của nút cuối tin cậy. Đường dẫn kết thúc với chứng chỉ thực thể cuối.
Tất cả các chứng chỉ khác chứa trong đường dẫn được xem như các CA trung
gian. Lưu ý rằng mỗi chứng chỉ trong chuỗi từ chứng chỉ cuối cùng là một
chứng chỉ CA.
Khi xây dựng các đường dẫn xác thực theo chiều thuận, ta có thể sử dụng
tổ chức phát hành DN trong chứng chỉ thực thể cuối để lấy chúng chỉ mà đã
được phát hành cho các CA cấp phát chứng chỉ thực thể cuối. Như minh họa
trong hình 2, tổ chức cấp phát là CA2 trong chứng chỉ thực thể cuối sẽ dẫn đến
chứng chỉ của CA2. Một khi lấy được chứng chỉ của CA2 , ta có thể sử dụng tổ
chức phát hành DN trong chứng chỉ của CA2 để lấy chứng chỉ của CA1. Cuối
cùng, tổ chức cấp phát DN trong chứng chỉ của CA1 dẫn đến chứng chỉ của
8
Nhóm 1 – AT9A – HV kỹ thuật mật mã

CA0. Logic này cũng được áp dụng khi xây dựng các đừng dẫn chứng thực
theo chiều ngược lại.
Nếu CA được đảm bảo để chỉ có một cặp khóa công khai/ bí mật hoạt
động tại bất kì thời gian nhất định, đáp ứng yêu cầu của name chaining sẽ là tất
cả những gì cần để xây dựng một đường dẫn chứng thực. Tuy nhiên có thể các
CA có nhiều hơn một cặp khóa ký hợp lệ tại cùng một thời điểm. Điều này có
nghĩa là chỉ name chaining không đủ để xác định liệu đường dẫn chứng thực là
một ứng cử viên hợp pháp không. Vậy ta sẽ tiếp tục xem xét về “key identifier
chaining”
1.3.2

Key indentifier chaining

The Authority Key Identifier (AKID) và Subject Key Identifier (SKID) là
phần mở rộng của chứng chỉ có thể được sử dụng để tạo thuận lợi cho quá trình
xây dựng đường dẫn chứng thực. Như đã mô tả trong X.509 và RFC3208, AKID
được sử dụng để phân biệt khóa công khai từ một CA khác khi 1 CA có nhiều
khóa ký, và SKID cung cấp một phương tiện để xác thực chứng chỉ chứa một
khóa công khai cụ thể.
Tương tự như “name chaining” giữa nút cuối tin cậy và chứng chỉ thực
thể cuối, SKID của chứng chỉ đầu tiên là AKID của chứng chỉ tiếp theo trong
đường dẫn. Hình 3 sẽ mô tả khái niệm này. Lưu ý kể từ khi AKID và SKID là
phần mở rộng của chúng chỉ, khái niệm về key identifier chaining chỉ áp dụng
cho các chúng chỉ khóa công khai version 3.

9
Nhóm 1 – AT9A – HV kỹ thuật mật mã

1.3.3

Cấu trúc và sử dụng AKID/SKID

Theo như trong X.509, AKID có thể được biểu diễn bằng cách sử dụng
một keyIdentifier, 1 authorityCertIssuer, cặp authoritySerialNumber, hoặc cả
2. Tuy nhiên X.509 cũng nói rằng:
Các dạng keyIdentifier có thể được sử dụng để chon các chứng chỉ
CA trong quá trình xây dựng đường dẫn. authorityCertIssuer,
authoritySerialNumber pair chỉ có thể được sử dụng để cung cấp
độ ưu tiên cho một chứng chỉ trong quá trình xây dựng đường dẫn.
Ngoài ra, Internet Certificate and CRL Profile cho rằng trường
keyIdentifier trong AKID phải được bao gồm trong tất cả các chứng chỉ được
tạo ra bằng cách tuân theo các CA (với ngoại lệ là các chứng chỉ tự kí, trong
trường hợp này keyIdentifier sẽ được chứa trong SKID, các tùy chọn và
AKID). Hơn nữa Internet Certificate and CRL Profile chỉ ra rằng: trường
keyIdentifier của AKID phải được bao gồm trong tất cả các chứng chỉ được
tạo ra bằng cách tuân theo các CA để tạo điều kiện cho việc xây dựng các
chuỗi.
Theo X.509, SKID chỉ có thể được biểu diễn bằng cách sử dụng
keyIdentifier (tức là, cú pháp của SKID không bao gồm authorityCertIssuer,
10
Nhóm 1 – AT9A – HV kỹ thuật mật mã


authoritySerialNumber pair). Tuy nhiên, the Internet Certificate and CRL
Profile lại nói rằng tất cả các chứng chỉ CA phải bao gồm phần mở rộng
SKID: giá trị của Subject Key Identifier phải là giá trị được đặt trong trường
key identifier của AKID… của các chứng chỉ được cấp phát bởi chủ thể của

chứng chỉ này.
Do đó, một CA phù hợp với Internet Certificate and CRL profile phải ở
trong AKID của tất cả các chứng chỉ mà nó cấp phát với cùng keyIdentifier
lằm trong SKID của chứng chỉ được sử dụng để xác minh chữ kí số trên
những chứng chỉ được cấp phát.
1.3.4

Tính toán giá trị keyIdentifier

Có nhiều phương pháp để tính keyIdentifier. Các phương pháp sau được
đề cập cụ thể trong Internet Certificate and CRL Profile:
- 20byte giá trị SHA-1 của khóa công khai (không bao gồm tag, chiều dài,
các bit không sử dụng).
- 1 giá trị 4bit 0100 tiếp theo là các trọng số nhỏ nhất của giá trị SHA-1 của
khóa công khai (subject public key).
- Một dãy đơn điệu tăng của dãy số nguyên. Lưu ý rằng chúng chỉ là các
khuyến nghị- hồ sơ không ủy quyền một thuật toán cụ thể.
Ở đây ta cần lưu ý 2 điều quan trọng. Đầu tiên, trong khi keyIdentifier có
thể là duy nhất trên nhiều miền PKI (ví dụ, khi giá trị băm SHA-1 của khóa
công khai được sử dụng ). Chỉ bảo đảm rằng keyIdentifier là duy nhất liên
quan đến khóa công khai được đưa ra trong bối cảnh của một tổ chức phát
hành. Điều này có nghĩa là chúng ta không thể chỉ dựa trên giá trị
keyIdentifier để đảm bảo rằng ta có chứng chỉ hợp lệ. Thứ 2, có thể có một tổ
chức cấp phát có thể gia hạn chứng chỉ (tức là, một khóa công khai tương tự
cũng được phát hành trong một chứng chỉ mới) và giá trị keyIdentifier có thể
giống nhau trong nhiều hơn một chứng chỉ. Đây là lý do tại sao chúng ta sử
11
Nhóm 1 – AT9A – HV kỹ thuật mật mã

dụng authorityCertIssuer. authorityCertIssuer pair có thể cần thiết để lựa
chọn một chứng chỉ trong số những cái khác (tức là: số serial được đảm bảo
là duy nhất cho mỗi chứng chỉ được cấp phát bởi 1 CA mặc dù khóa công
khai tương tự có thể được cấp lại).
1.4

XÁC NHẬN CHỨNG CHỈ HỢP LỆ
Trong bối cảnh các doanh nghiệp, hầu hết các nhà cung cấp PKI đã dựa

vào việc sử dụng các vùng lưu trữ cho việc lưu trữ và thu hồi chứng chỉ. Trong
nhiều trường hợp, nó được hỗ trợ bởi một thư viện dựa trên chuẩn X.509 với
sự tương tác client-server được hỗ trợ bởi Lightweight Directory Access
Protocol (LDAP). X.509 định nghĩa các thuộc tính thư mục cụ thể mà các
chưng chỉ CA và các chứng chỉ thực thể cuối được lưu trữ. Trong khi có một
số tranh cãi về thuộc tính nên được sử dụng, X.509 version4 chỉ thị các yêu
cầu cụ thể, các hành vi mong đợi. Cú pháp và dự kiến sử dụng các thuộc tính
phù hợp với X.509 được mô tả dưới đây.
a. Các thuộc tính chứng chỉ X.509
X.509 định nghĩa một số thuộc tính của chứng chỉ. Ở đây ta quan tâm đến
các thuộc tính cACertificate và crossCertificatePair. Thuộc tính userCertificate
được sử dụng để lưu trữ các chứng chỉ thực thể cuối nhưng để đơn giản chúng
ta giả định rằng các chứng chỉ thực thể cuối đã có trong tay trước quá trình xây
dựng đường dẫn chứng thực.
Theo quy định trong X.509: thuộc tính cACertificate của đường dẫn thư
mục của CA được sử dụng để lưu trữ các chứng chỉ tự kí và các chứng chỉ
được cấp phát cho các CA bởi các CA trong cùng lĩnh vực của CA này. Định
nghĩa về lĩnh vực hoàn toàn là vấn đề của chính sách địa phương.
Theo định nghĩa, chứng chỉ tự cấp là chứng chỉ CA nơi mà tổ chức phát
hành DN và chủ thể DN là giống nhau. Chứng chỉ tự kí là một chứng chỉ tự
cấp nơi khóa bí mật được sử dụng để kí chứng chỉ tương ứng với khóa công

khai trong chứng chỉ (tức là khóa công khai trong chứng chỉ được sử dụng để
12
Nhóm 1 – AT9A – HV kỹ thuật mật mã


xác minh chữ kí số kết hợp với chứng chỉ). X.509 tạo ra sự phân biệt, từ đó
chứng chỉ tự cấp không được đảm bảo nó cũng là chứng chỉ tự kí. Điều này có
thể được minh họa bằng cách dùng việc gia hạn khóa CA là ví dụ. Để cho phép
chuyển cặp khóa ký cũ thành mới, CA sẽ cấp phát một chứng chỉ mà chứa
khóa công khai cũ đã được kí bởi khóa kí bí mật mới và một chứng chỉ chứa
khóa công khai cũ được kí bởi khóa kí bí mật cũ. Cả hai chúng chỉ này đã được
tự cấp, nhưng không phải là tự kí.
Thuộc tính cặp chứng chỉ chéo bao gồm 2 phần: issuedToThisCA và
issuedByThisCA. Theo quy định của X.509: phần issuedToThisCA của thuộc
tính crossCertificatePair của đường dẫn thư mục của CA được sử dụng để lưu
trữ tất cả, ngoại trừ các các chứng chỉ tự cấp được cấp bởi CA này. Tùy chọn,
các phần issuedByThisCA của thuộc tính crossCertificatePair của đường dẫn
thư mục của CA có thể chứa một tập hợp con của các chứng chỉ được cấp bởi
CA này đến các CA khác. Và đối tượng CA không phải là một nhánh của tổ
chức cấp phát CA trong một hệ thống phân cấp, sau đó tổ chức cấp phát CA sẽ
phong tỏa các chứng chỉ trong phần issuedByThisCA của thuộc tính
crossCertificatePair của đường dẫn thư mục riêng của mình.
Điều này dẫn chúng ta đến một số kết luận:
- Thứ nhất, chúng ta mong muốn từng CA chứa thuộc tính cACertificate
trong thư mục riêng của mình ,đăng nhập bằng chứng chỉ tự cấp riêng của
mình, nếu có. Điều này sẽ bao gồm bất kỳ chứng chỉ tự ký cũng như bất
kỳ chứng chỉ cấp bởi CA với hỗ trợ cập nhập khóa CA .
- Thứ hai, chúng ta có thể thấy chứng chỉ được cấp cho một CA đã được
ban hành bởi các CA khác thuộc cùng một "khu" để được lưu trữ trong
các thuộc tính cACertificate vào thư mục riêng của nó . Trong một vùng

chưa xác định, một ví dụ có thể là một PKI domain đơn bao gồm một hệ
thống các CA. Trong trường hợp cụ thể này, chúng ta có thể mong đợi
rằng CA được cấp để lưu trữ các chứng chỉ cấp cho chúng bởi CA cấp
trên của chúng trong các thuộc tính cACertificate của thư mục riêng của
chúng. Tuy nhiên, cho rằng "lãnh địa" là không xác định và được diễn
13
Nhóm 1 – AT9A – HV kỹ thuật mật mã


giải, không có đảm bảo rằng điều này sẽ được thực hiện nhất quán bởi tất
cả các nhà cung cấp.
- Thứ ba, chúng ta sẽ mong đợi để xem các yếu tố issuedToThisCA của các
thuộc tính chứng chỉ chéo được đặt cùng với chứng chỉ đã được cấp cho
CA này bởi các CA khác. (Điều này cho thấy rằng cả cACertificate và
issuedToThisCA có thể được lưu giữ khi phát hành CA là trong lĩnh vực
tương tự như cấp cho CA.)
- Cuối cùng, chúng tôi mong chờ các thuộc tính issuedByThisCA lưu giữ
với chứng chỉ cấp bởi CA này cho các CA khác khi những người CA
không thuộc hệ thống phân cấp tương tự. Đặc biệt, chúng ta sẽ thấy các
thuộc tính issuedByThisCA lưu giữ với chứng chỉ được ban hành từ CA
thường được tìm thấy trong một mô hình tin cậy phân phối. Mặc
dù issuedByThisCA có thể được lưu giữ trong một domain phân cấp, nó
không hợp lý để giả định rằng điều này sẽ luôn luôn đúng cho mọi trường
hợp.
Vì vậy, chúng ta có thể bắt buộc những điều sau cho CA cho phù hợp với ấn
bản thứ 4 của X.509:
- Tất cả các chứng chỉ tự ban hành phải được lưu trữ trong các thuộc tính
cACertificate của thư mục CA phát hành;
- Tất cả các chứng chỉ đã cấp cho CA trừ các chứng chỉ tự ban hành phải
được lưu trữ trong các yếu tố issuedToThisCA của thuộc tính crosscertificate của thư mục của CA ;

- Tất cả các chứng chỉ cấp bởi một CA tới CA cuối hay ngang hàng phải
được lưu trữ trong các yếu tố issuedByThisCA của cross-certificate của
đường dẫn thư mục của CA đang phát hành.
Ấn bản thứ 4 của X.509 cũng định nghĩa một thuộc tính pkiPath có thể
được sử dụng để lưu trữ một phần hoặc đường dẫn xác nhận hoàn tất. Mỗi
con đường được biểu diễn bởi một chuỗi các thập chứng. X.509 mô tả việc
sử dụng các thuộc tính này như sau: thuộc tính này có thể được lưu trữ trong
đường dẫn thư mục CA và sẽ chứa một số đường dẫn chứng thực từ CA đến
14
Nhóm 1 – AT9A – HV kỹ thuật mật mã


các CA khác. Thuộc tính này, nếu được sử dụng, cho phép phục hồi hiệu quả
hơn các chứng chỉ chéo mà là hình thức thường được các đường dẫn chứng
thực sử dụng. Như vậy sẽ không có bất kì yêu cầu cụ thể nào cho thuộc tính
này được sử dụng và tập các giá trị mà được lưu trữ trong thuộc tính sẽ
không đại diện cho toàn bộ các đường dẫn chứng thực thuận cho bất kì CA
nào.
Vì chúng ta không nhận thức được bất kỳ triển khai đã tồn tại mà sử dụng
các thuộc tính pkiPath theo cách này, và kể từ khi X.509 ngụ ý rằng việc sử
dụng thuộc tính này là tùy chọn, chúng ta không khám phá sử dụng các thuộc
tính này hơn nữa.

b. Sử dụng các tiện ích mở rộng của chứng chỉ cá nhân
Trong nhiều trường hợp, hệ thống của khách hàng được cấu hình với địa chỉ
IP mặc định và / hoặc tên DNS của một hoặc nhiều kho lưu giữ. Những kho
được truy vấn cho các chứng chỉ cần thiết. Ngoài ra, trung tâm tìm kiếm thường
được thiết lập để các chứng chỉ thích hợp có thể dễ dàng đặt và lấy ra.
Như một thay thế, Internet Certificate and CRL Profile xác định một phần
mở rộng riêng gọi là phần mở rộng Authority Information Access (AIA). Như đã

nêu trong RFC3280, AIA "chỉ ra làm thế nào để truy cập thông tin và dịch vụ
CA cho người phát hành chứng chỉ, trong đó phần mở rộng sẽ xuất hiện." Một
khả năng sử dụng phần mở rộng này là dùng một danh sách các "CA đã cấp
chứng chỉ tốt hơn CA đã cấp chứng chỉ có chứa phần mở rộng này ... được thiết
kế để hỗ trợ người sử dụng chứng chỉ trong việc lựa chọn một đường dẫn chứng
thực mà kết thúc tại một điểm đáng tin cậy của người sử dụng chứng chỉ”. Nó
vẫn còn để được nhìn thấy cách sử dụng các phần mở rộng riêng AIA có thể phát
triển theo thời gian. Hiện nay, Microsoft (Windows 2000 và Windows XP) sử
dụng AIA để trỏ đến vị trí chứng chỉ của CA phat hành. Trong tương lai, chúng
15
Nhóm 1 – AT9A – HV kỹ thuật mật mã


ta có thể thấy các nhà cung cấp sử dụng AIA để trỏ đến thông tin bổ sung như
một danh sách các CA cấp trên.
Internet Draft Certificate and CRL Profile mới nhất cũng định nghĩa một
phần mở rộng riêng gọi là phần mở rộng tiếp cận thông tin chủ thể (SIA). Phần
mở rộng này "chỉ ra làm thế nào để truy cập thông tin và dịch vụ cho các đối
tượng của các chứng chỉ, trong đó phần mở rộng sẽ xuất hiện." Một khả năng sử
dụng phần mở rộng này là để xác định đâu là CA phát hành các chứng chỉ (và có
thể CRL) mà nó tạo ra. Đây là điều mà chúng ta có thể được khai thác trong
tương lai.
c. Những lựa chọn khác
Đó là thực tế phổ biến để gửi chứng chỉ khóa công khai cần thiết để xác
minh chữ ký kỹ số cùng với dữ liệu chữ ký số . Ví dụ, bảo mật e-mail dựa trên
các hỗ trợ S/MIME. Nó cũng có thể gửi đường dẫn xác nhận một phần hoặc
toàn bộ cho các bên cần chứng thực qua giao thức - perhaps sử dụng cú pháp
thuộc tính pkiPath quy định tại X.509. Trong những trường hợp này, một
số (hoặc có lẽ tất cả) đường dẫn chứng thực có thể không phải được lấy từ các
nguồn bên ngoài.

Tuy nhiên, trong các miền PKI kết nối phức tập và đa dạng, nó không chắc
rằng người khởi tạo một thông báo sẽ biết một đường dẫn chứng thực hoàn
toàn giữa nút cuối tin cậy của bên có nhu cầu chứng thực và chứng chỉ của
người khởi tạo. Thậm chí nếu một đường dẫn được biết, không có đảm bảo
rằng đây sẽ là đường dẫn mà sẽ đáp ứng được các tiêu chí xác minh đường dẫn
thu bởi các bên tin cậy (hoặc bởi bất kỳ CA trung gian). Trong khi có thể có
một số trường hợp chúng ta có thể tận dụng các kiến thức về đường dẫn một
phần, trong hầu hết trường hợp, chúng tôi sẽ cần một thuật toán xây dựng
đường dẫn mạnh mẽ có khả năng phát hiện một đường dẫn chứng thực hoặc
đầy đủ hơn.

1.5

XÂY DỰNG CÁC ĐƯỜNG DẪN CHỨNG THỰC
16
Nhóm 1 – AT9A – HV kỹ thuật mật mã


Các ví dụ tiếp theo được thiết kế để minh họa một số vấn đề có thể gặp
phải khi xây dựng đường dẫn chứng thực. Nói chung, các ví dụ là độc lập với
cơ chế sử dụng để lấy các chứng chỉ cần thiết. Sự phù hợp với ấn bản thứ 4 của
X.509 được giả định.
a) Ví dụ đơn giản: hệ thống phân cấp nghiêm ngặt
Hãy bắt đầu với một ví dụ tương đối đơn giản. Hình 4 minh họa một hệ
thống phân cấp nghiêm ngặt của CA. Các hình bát giác đại diện cho CA, các
mũi tên đại diện cho cấp chứng chỉ và các hình chữ nhật mặt cắt đại diện cho
chứng chỉ. Các thuộc tính thư mục X.509 cụ thể được sử dụng để lưu trữ
mỗi chứng chỉ được xác định. Hãy kiểm tra những gì sẽ xảy ra khi User1 sẽ
gửi một email có chữ ký cho User2. Người ta cho rằng chứng chỉ xác minh
User1 được chuyển tải cùng với các thông điệp.

Trong ví dụ này, User2 là bên tin cậy. Vì chúng ta đang cố gắng xác minh
chữ ký số sử dụng chứng chỉ xác minh User1, chúng ta cần phải xây dựng một
con đường chứng thực giữa chứng chỉ của User1 và một CA tin tưởng được
công nhận bởi User2. Trong trường hợp này, CA0 là CA gốc, sự tin tưởng
chung cho tất cả người dùng trong hệ thống cấp bậc nghiêm ngặt này.Về cơ
bản, User2 muốn biết nếu CA0 đã thiết lập một mối quan hệ tin cậy (hoặc trực
tiếp hoặc gián tiếp) với các tổ chức phát hành chứng chỉ User1 (trong trường
hợp này là CA1). Nói cách khác, nếu các bên dùng phần mềm có khả năng giải
quyết các đường chứng nhận CA0-> CA1-> User1, sau đó chúng ta sẽ có
một đường dẫn chứng thực hợp lý.
Xây dựng đường dẫn chứng thực trong hệ thống phân cấp nghiêm ngặt là
khá đơn giản. Đường dẫn thường được xây dựng theo chiều thuận (tức là,
chúng ta bắt đầu với chứng chỉ của mục tiêu và làm việc trên đường dẫn của
chúng ta , tới nơi xác thực gốc). Do đó, các phần mềm của bên tin cậy sẽ bắt
đầu với xác mính chứng chỉ của User1 và làm việc theo cách của mình để tới
CA0. Kể từ khi các phần mềm bên tin cậy biết CA1 là tổ chức phát hành
chứng chỉ cho User1 (các tổ chức phát hành DN trong chứng chỉ User1 là

17
Nhóm 1 – AT9A – HV kỹ thuật mật mã


CA1), điều này được thực hiện bằng cách lấy các yếu tố cấp bởi CA được lưu
trữ trong các đường dẫn thư mục cho CA1.
Sau đó chúng ta khám phá ra rằng CA0 là tổ chức phát hành chứng chỉ
CA1, và bây giờ chúng ta có một đường dẫn chứng thực giữa chứng chỉ của
user1 và một nút cuối tin cậy được công nhận bởi User2.

Figure 4: Path Construction Illustration – Strict Hierarchy

b) Ví dụ phức tạp hơn: chứng chỉ céo đơn với mô hình phân cấp và mô
hình ủy thác phân phối
Chúng tôi sẽ sử dụng hình 5 để minh họa cho một quá trình xây dựng
đường dẫn phức tạp hơn giữa hai lĩnh vực PKI mà có xác nhận lẫn nhau . Như
trên, hình bát giác đại diện cho CA và các hình chữ nhật mặt cắt đại diện cho
chứng chỉ. Các thư mục X.509 cụ thể các thuộc tính được sử dụng để lưu trữ
mỗi chứng chỉ được xác định. Như trong ví dụ trước, các mũi tên một chiều
đại diện cho cấp chứng chỉ. Các mũi tên hai chiều (bao gồm cả mũi tên nét đứt
18
Nhóm 1 – AT9A – HV kỹ thuật mật mã


giữa CA0 và CA5) đại diện cho xác nhận lẫn nhau . Như vậy, miền PKI ở trên
bên trái là một mô hình phân cấp tin cậy trong khi miền PKI ở trên bên phải là
một mô hình phân phối tin cậy.
Trong ví dụ này, User3 nhận được một e-mail có chữ ký từ User2. User3 là
bên tin cậy và chứng chỉ để được xác nhận là chứng chỉ kiểm định của
User2. Chứng chỉ kiểm định của User2 đi kèm với các e-mail được gửi đến
User3.
Các nhiệm vụ chính là xây dựng một đường dẫn chứng thực giữa chứng chỉ
xác minh của User2 và một nút cuối tin cậy mà User3 được chứng nhận (trong
trường hợp này là CA7). Chúng ta có thể thấy rằng một khả năng để làm việc
theo cách của chúng ta từ nút cuối tin cậy của các bên tin cậy cuối cùng để tìm
ra cách chứng thực chéo CA5 cấp cho CA0. Điều này được gọi là xây dựng
đường dẫn theo chiều ngược và nó tạo ra một con đường từ CA7-> CA5->
CA0. Con đường này được xây dựng bằng cách lấy các chứng chỉ cấp bởi CA
dưới đường dẫn thư mục của CA7, dẫn đến việc thu hồi các chứng chỉ
issuedByThisCA dưới đường dẫn thư mục của CA5.
Figure 5: Path Construction Illustration – Single Inter-Domain CrossCertification

19
Nhóm 1 – AT9A – HV kỹ thuật mật mã


Một khi chúng ta "tiếp cận" CA0, nó có thể không thể tiếp tục xây dựng
các đường dẫn ngược, vì ta không thể phụ thuộc vào thành phần
issuedByThisCA để được gắn bởi các CA thuộc về một hệ thống phân cấp.
Thậm chí nếu các thành phần issuedByThisCA gắn với mỗi CA trong miền phân
cấp, việc tìm kiếm theo chiều ngược từ CA0 sẽ kém hiệu quả hơn việc tìm kiếm
theo chiều thuận từ CA4. Cụ thể, chúng ta sẽ gặp phải hai con đường có thể phát
ra từ CA0 (không kể các liên kết trở lại CA5), nhưng chỉ có một con đường có
thể dẫn từ CA4 trở lại lên đến CA0.
Vì vậy, chúng ta làm gì tiếp theo? Bây giờ chúng ta cố gắng xây dựng các
phần còn lại của hướng thuận, có nghĩa là chúng ta làm việc theo cách của
chúng ta trở lại với chứng chỉ mục tiêu là CA0. Điều này được thực hiện bằng
cách tìm kiếm các yếu tố cấp bởi CA trong đường dẫn thư mục của CA4 (nhớ lại
rằng CA4 là chứng chỉ mục tiêu của tổ chức phát hành). (Tùy chọn, chúng ta có
thể tìm kiếm thông tin này trong thuộc tính chứng chỉ, nhưng thuộc tính này
không được bảo đảm đến được người dùng như đã thảo luận trước đó.) Điều này
dẫn chúng ta phát hiện các chứng chỉ từ CA2 tới CA4, lần lượt, dẫn chúng ta
đến các chứng chỉ từ CA0 tới CA2. Bây giờ chúng ta có một chuỗi hoàn chỉnh
các chứng chỉ giữa các chứng chỉ mục tiêu và nút cuối tin cậy được công nhận
bởi các bên tin cậy từ CA7-> CA5- > CA0-> CA2-> CA4-> User2. Tất nhiên,
trong ví dụ này, thứ tự của việc xây dựng đường dẫn có thể bị đảo ngược. Đó là,
chúng ta có thể xây dựng các đường dẫn một phần CA0-> CA2-> CA4- > User2
đầu tiên, và sau đó chúng ta có thể làm việc theo cách của chúng ta trở lại từ
CA7 tới CA0.
Để hoàn thành, chúng ta hãy có một cái nhìn nhanh chóng vào những gì
sẽ xảy ra khi User3 gửi một e-mail đã ký cho User2. Bây giờ User2 là bên tin
cậy, và chúng ta cần phải xây dựng một đường dẫn chứng thực giữa chứng chỉ

xác minh User3 và một nút cuối tin cậy được công nhận bởi User2 (trong trường
hợp này là CA0). Cụ thể, chúng ta cần CA0-> CA5-> CA7-> User3 (một lần
nữa bỏ qua các con đường thông qua CA6). Như vậy, chúng ta có thể xây dựng
các con đường cần thiết bằng cách lấy các xác nhận chéo mà CA0 cấp cho CA5
20
Nhóm 1 – AT9A – HV kỹ thuật mật mã


thu được từ các thuộc tính issuedByThisCA trong đường dẫn thư mục của CA0,
mà sẽ dẫn chúng ta đến các chứng chỉ chéo được caaps bởi CA5 dến CA7 thu
được từ thuộc tính issuedByThisCA trong đường dẫn thư mục của CA5.
c) Xây dựng đường dẫn chứng thực ngược so với thuận
Trong một hệ thống phân cấp chặt chẽ, làm việc theo chiều thuận, nên
chúng ta luôn được đảm bảo có thể tìm các phần tử issuedToThisCA của thuộc
tính cross-certificate pair gắn người dùng với chứng chỉ đã được cấp cho từng
cấp dưới CA. Ngoài ra, nó thường là hiệu quả hơn để xây dựng con đường một
hướng trong một hệ thống phân cấp. Trong một số trường hợp, điều này sẽ dẫn
đến một và chỉ có một con đường chứng thực có thể. Trong những trường hợp
khác, một số giới hạn của đường dẫn thay thế có thể được xây dựng như là một
kết quả của sự tồn tại của nhiều chứng chỉ mỗi CA.
Khóa định danh có thể được sử dụng để giải quyết cho một dduwowngf
dẫn duy nhất trong một số trường hợp, nhưng điều này có thể không luôn luôn
có ích(ví dụ, khi phiên bản 1 hoặc 2 của chứng chỉ đang được sử dụng hoặc khi
cùng khóa công khai được tái phát hành và giá trị khóa định danh dựa trên khóa
công cộng). Trong mọi trường hợp, số lượng đường chứng nhận có thể được như
được giới hạn khi làm việc ở phía trước . Hướng trong một hệ thống phân cấp
nghiêm ngặt trong các ví dụ trước ở trên, người ta có thể thấy rằng các đường
dẫn cấp chứng chỉ có thể đã được xây dựng theo chiều thuận - thậm chí trong
mô hình phân phối.
Mặc dù điều này có thể đúng trong ví dụ đơn giản này, điều này chỉ có thể

do thực tế rằng có một đơn liên miền chứng nhận chéo và một số lượng hạn chế
của các CA tham gia.
Khi chúng ta gặp phải một mô hình tin cậy phân phối, xây dựng cấp chứng
chỉ con đường ở phía trước hướng có thể trở nên kém hiệu quả. Điều này là do
thực tế là chúng ta có thể bắt gặp hàng chục hoặc thậm chí hàng trăm các
nguyên tố chuyển tiếp liên kết với một CA cho, không phải chỉ một hoặc hai.

21
Nhóm 1 – AT9A – HV kỹ thuật mật mã


Điều này được minh họa trong hình 6, nơi mà chúng tôi đã giới thiệu một
cầu CA (BCA1) giữa hai lĩnh vực PKI. Mặc dù chúng ta có thể dễ dàng xây
dựng các con đường từ chứng chỉ mục tiêu là CA0 (như chúng ta đã thấy trước
đó), điều này trở nên phức tạp hơn nhiều khi chúng ta cố gắng tiếp tục ở làm
việc theo chiều thuận từ CA0. Cụ thể, BCA1 có thể được chứng nhận chéo với
hàng chục hoặc thậm chí hàng trăm các CA khác (bao gồm cả cầu khác CA), và
những người CA có thể được chứng nhận chéo với hàng chục, hàng trăm người
khác. Nếu chúng ta chỉ nhìn vào yếu tố cấp bởi CA, chúng ta có thể gặp phải
một số lượng lớn các CAs dẫn ra khỏi con đường chúng ta đang tìm kiếm.
Cố gắng để tạo mọi đường dẫn thuận rõ ràng ít thực tế hơn là trong những
trường hợp khác. Xây dựng theo hướng ngược lại cũng liên quan đến việc thử và
sai, nhưng chúng ta sẽ luôn luôn được làm việc với một (một phần) con đường
phát ra từ nút cuối tin cậy vì chúng ta đang trả lời các câu hỏi "những người bạn
đã cấp chứng chỉ để" thay vì "những người đã ban hành chứng chỉ cho bạn.
" Trong khi điều này có thể không đủ cho bản thân để thuyết phục mọi người
rằng chiều ngược là thích hợp nhất trong một môi trường phân phối, cũng có
một số hiệu quả mà có thể được thực hiện khi xây dựng đường dẫn trong hướng
ngược lại, như đã thảo luận.
Figure 6: Path Construction Illustration – Fully Distributed

22
Nhóm 1 – AT9A – HV kỹ thuật mật mã


Điều này dẫn chúng ta đến kết luận rằng việc xây dựng con đường chứng nhận
theo chiều thuận là tối ưu cho mô hình phân cấp tin cậy, và xây dựng con đường
chứng nhận theo hướng ngược lại là tối ưu cho mô hình phân phối tin cậy.
1.6

ĐÁNH GIÁ CÁC ĐƯỜNG DẪN CHỨNG THỰC TRONG QUÁ

TRÌNH XÂY DỰNG ĐƯỜNG DẪN
Cho đến nay , chúng ta chưa đưa ra bất kì hình thức xác nhận đường dẫn
hoặc tiêu chuẩn hữu ích mà có thể xem xét trong quá tronhf xây dựng đường
dẫn. Mặc dù có thể bỏ qua bất kì tiêu chí xác nhận nào nhưng việc này có thể
dẫn đến sự thiếu hiệu quả lớn. Điều này đặc biệt đúng trong các môi trường
PKI kết nối đa dạng và phức tạp.
Để hiểu hơn về vấn đề này, t sẽ xem xét lại các ví dụ. Khi đi ra từ nút cuối tin
cậy của user3, ta bắt gặp cầu CA (BCA1) thay thế cho chứng chỉ chéo trực
tiếp mà CA5 cấp phát cho CA0. Không kể đến chứng chỉ chéo BCA1 cấp
phát cho CA5, bây giờ chúng ta có 4 chứng chỉ chéo xuất phát từ BCA1 tham
gia vào, mà mỗi cái có thể dẫn đến hàng chục chứng chỉ khác. Sẽ tốt hơn nếu
ta nhận ra rằng chứng chỉ chéo BCA1 cấp phát cho CA0 có khả năng đưa ta
đến gần hơn với nơi mà t cần phải đi. Vậy, khi ta lấy tất cả các đường dẫn
issuedByThisCA gắn với đường dẫn thư mục của BCA1, nó sẽ cải thiện đáng
kể hiệu xuất nếu bằng cách nào đó ta biết CA0 là đường dẫn chúng ta đang
tìm kiếm.
Kể từ khi hệ phân cấp nghiêm ngặt thường dựa trên quy ước đặt tên theo thức
bặc, ta có thể tận dụng lợi thế của thực tế rằng CA0 của DN cỏ thẻ là tập con

của các RDN (Relative Distinguished Name) trong chứng chỉ mục tiêu. (ví
dụ: chứng chỉ của user2 ) hoặc CA4 của RDNs (biết được từ nhà cấp phát
DN trong chứng chỉ của CA2). Nó cách khác, một khi ta phát hiện ra chứng
chỉ chéo được cấp phát bởi CA5 đến CA0, ta sẽ mình đang đi đúng hướng, từ
đó, các RDN trong CA0 của DN sẽ nối với một tập con của các RDN ttrong
chứng chỉ của user2 của nhà cấp phát DN và/hoặc chủ thể DN. Điều này
không có nghĩa rằng các mục khác không dẫn đến một đường dẫn hợp pháp,
23
Nhóm 1 – AT9A – HV kỹ thuật mật mã


nhưng không có nghĩa ta muốn thử CA0 đầu tiên. Ngoài ra, ta có thể xây
dựng đường dẫn riêng CA0->CA2->CA4->User2 đầu tiên, vì vậy, ta có thể
biết rằng mình có một đường dẫn chứng thực khi ta gặp phải chứng chỉ chéo
BCA1 cấp phát cho CA0 khi làm việc theo hướng ngược lại.
Như đã đề cập trước đó, có thể có những vẫn đề nhất định trong việc xem xét
để tối đa hóa cơ hội mà đường dẫn chứng thực phù hợp đưa ra được một
đường dẫn chấp nhận được. Trong thực tế, một số nhà cung cấp đã phát triển
một hệ thống ưu tiên đường dẫn chứng thực với lỗ lực đưa ra các đường dẫn
có khả năng hợp logic nhất. Ví dụ một phần mềm miễn phí CPL
(Certification Path Library) mà ưu tiên thức tự các chứng chỉ được xem xét
trong quá trình xây dựng đường dẫn có sẵn để tải về từ
. Theo Path
Development API - Interface Control Document [Ref4], các quy tắc ưu tiên
như sau:
1. Các chứng chỉ lấy từ thuộc tính cACertificate sẽ cos dộ ưu tiên cao hơn
các chứng chỉ lấy từ thuộc tính crossCertificate.
2. Các chứng chỉ trong thuật toán cấp phát OID= đối tượng thuật toán ODI
sec được ưu tiên.
3. Các chứng chỉ mà các chính sách đòi hỏi sẽ có độ ưu tiên cao hơn các

chứng chỉ khác. Giữa các chứng chỉ mà các chính sách đòi hỏi, các chứng
chỉ này nối với nhiều chính sách trong thiết lập chính sách chấp nhận
được ban đầu sẽ được ưu tiên,
4. Các chứng chỉ với ít yếu tố RDN trong tổ chứng cấp phát DN nên có độ
ưu tiên.
5. Các chứng chỉ mà nối với nhiều RDN giữa các tổ chức cấp phát DN và
DN nút cuối tin cậy của bên có nhu cầu chứng thực nên được ưu tiên.
6. Các chứng chỉ nối với nhiều RDN giữa các chủ thể DN với issuer DN nên
được ưu tiên.
24
Nhóm 1 – AT9A – HV kỹ thuật mật mã


7. Các chứng chỉ có thời hạn hiệu lực dài nên được ưu tiên.
Có thể lấy tiêu chí xác nhận đường dẫn cụ thể vào xem xét trong quá trình xây
dựng đường dẫn. Ý tưởng là để tang cơ hội một hoạc nhiều đường dẫn vượt qua
nhiều thủ tục xác nhận đường dẫn toàn diện hơn. Tuy nhiên điều này có thể giúp
ta loại bỏ các đường dẫn kém tối ưu.
Xây dựng các đường dẫn chứng thực: Forward vs. Reverse [Ref3] xác định một
số tiêu chí xác nhận có thể được xem xét trong quá trình xây dựng đường dẫn:
- Các hạn chế về tên.
- Xử lý chính sách chứng chỉ
- Xác nhận chứng chỉ.
Việc lấy 1 hoặc nhiều đường dẫn để xem xét trong quá trình xây dựng đường
dẫn chứng thực có thể loại bỏ một số đường dẫn kém tối ưu. Có thể có các tiêu
chí khác để xác nhận đường dẫn mà các nhà cung cấp muốn xem xét. (ví dụ hạn
chế chiều dài đường dẫn). Ý tưởng là bạn có thể đưa ra các chứng chỉ mà không
thể đáp ứng được 1 tập con của các tiêu chí xác nhận đường dẫn.=> thúc đẩy
một quá trình “prune as you go”, đặc biệt là khi xây dựng các đường dẫn theo
hướng ngược lại.

Tuy nhiên có thể có các hạn chế liên quan đến điều này. Ví dụ, có các vấn đề
nhất định mà không thể được xác định cho đến khi toàn bộ đường dẫn được xây
dựng. Ngoài ra, điều này hàm ý rằng logic xây dựng đường dẫn có thể sử lí ít
nhất một tập con của logic xác minh đường dẫn như được nêu ra trong ấn bản
thứ tư của X,509 và Internet Certificate and CRL Profile. Điều này có thể không
đơn giản trong trường hợp một nhà cung cấp tách ra xây dựng đường dẫn và các
quy trình xác minh đường dẫn. Cuối cùng, chúng ta có thể thực hiện kiểm tra
tính hợp lệ của một đường dẫn mà không loại bỏ một đường dẫn nào, mặc dù
các thử tục xác minh đường dẫn đầy đủ xác định rằng một số tiêu chí không
được đáp ứng. Từ đó làm tang khối lượng công việc trong quá trình xây dựng
đường dẫn. Nó cũng có thể nhân bản làm việc, từ đó nhiều kiểm tra tương tự
25
Nhóm 1 – AT9A – HV kỹ thuật mật mã