/hvaonline/posts/list/8.html JForum - http://www.jforum.net X.509 version 1 Được định nghĩa vào năm 1988, X.509 version 1 giờ đây hầu như không còn được sử dụng nữa. Định dạng của loại chứng chỉ này được thể hiện như hình dưới đây:

Một chứng chỉ X.509 version 1 bao gồm các trường sau: Version: chứa giá trị cho biết đây là chứng chỉ X.509 version 1 Serial Number: cung cấp một mã số nhận dạng duy nhất cho mỗi chứng chỉ được phát hành bởi CA CA Signature Algorithm: tên của thuật toán mà CA sử dụng để ký lên nội dung của chứng chỉ số. Issuer Name: tên phân biệt (distinguished name) của CA phát hành chứng chỉ. Thường thì tên phân biệt này được biểu diễn theo chuẩn X.500 hoặc định dạng theo đặc tả của X.509 và RFC 3280. Validity Period: khoảng thời gian mà chứng chỉ được xem là còn hiệu lực, bao gồm 2 trường là: Valid From và Valid To. Subject Name: tên của máy tính, người dùng, thiết bị mạng sở hữu chứng chỉ. Thường thì tên chủ thể này được biểu diễn theo chuẩn X.500 hoặc định dạng theo đặc tả của X.509, nhưng cũng có thể bao gồm các định dạng tên khác như được mô tả trong RFC 822. Subject Public Key Info: khóa công khai của đối tượng nắm giữ chứng chỉ. Khóa công khai này được gửi tới CA trong một thông điệp yêu cầu cấp chứng chỉ (certificate request) và cũng được bao gồm trong nội dung của chứng chỉ được phát hành sau đó. Trường này cũng chứa nhận dạng của thuật toán được dùng để tạo cặp khóa công khai và khóa bí mật được liên kết với chứng chỉ. Signature Value: chứa giá trị của chữ ký. Các trường Issuer Name và Subject Name được cấu trúc để các chứng chỉ có thể được tổ chức thành một chuỗi các chứng chỉ mà bắt đầu bằng chứng chỉ được cấp cho người dùng, máy tính, thiết bị mạng, hoặc dịch vụ và kết thúc bằng chứng chỉ gốc của CA. X.509 version 2 Mặc dù chứng chỉ X.509 version 1 cung cấp khá đầy đủ những thông tin cơ bản về người nắm giữa chứng chỉ nhưng nó lại có ít thông tin về tổ chức cấp phát chứng chỉ khi chỉ bao gồm Issuer Name, CA Signature Algorithm và Signature Value. Điều này không giúp dự phòng trong trường hợp CA được thay mới. Khi chứng chỉ của CA được thay mới, trường Issuer Name trong cả 2 chứng chỉ mới và cũ đều như nhau. Tương tự, có thể có một tổ chức khác muốn tạo một CA có trường Issuer Name trong chứng chỉ giống như vậy. Giải quyết vấn đề này để có thể sử dụng lại Issuer Name thì chứng chỉ X.509 version 2 đã được giới thiệu vào năm 1993. Trong định dạng của nó có thêm 2 trường mới như được thể hiện trong hình dưới đây:

Hai trường mới được bổ sung là: Issuer Unique ID: là một trường không bắt buộc, chứa chuỗi giá trị ở hệ 16, mang tính duy nhất và dành để nhận dạng CA. Khi CA thay mới chứng chỉ của chính nó, một Issuer Unique ID mới được khởi tạo cho chứng chỉ đó. Subject Unique ID: là một trường không bắt buộc, chứa chuỗi giá trị ở hệ 16, mang tính duy nhất và dùng để nhận dạng chủ thể của chứng chỉ. Nếu chủ thể này cũng chính là CA thì trường này sẽ giống với Issuer Unique ID. Ngoài việc đưa vào 2 trường mới ở trên thì trường Version trong chứng chỉ X.509 version 2 có giá trị là 2 để chỉ ra phiên bản của chứng chỉ. Các trường Issuer Unique ID và Subject Unique ID đã cải tiến quá trình xâu chuỗi chứng chỉ. Giờ đây việc tìm kiếm chứng chỉ của của CA sẽ là so khớp Issuer Name trong chứng chỉ được cấp phát với Subject Name trong chứng chỉ của CA và thực hiện thêm một bước kiểm tra thứ hai là so khớp Issuer Unique ID trong chứng chỉ được cấp phát với Subject Unique ID trong chứng chỉ của CA. Bước so khớp thứ hai này cho phép phân biệt giữa các chứng chỉ của cùng một CA khi CA đó làm mới lại chứng chỉ của chính nó. Cách này cũng giúp phân biệt giữa các CA khác nhau nhưng trùng Subject Name. Mặc dù định dạng X.509 version có cải tiến hơn version 1 nhưng chuẩn này cũng không còn được áp dụng rộng rãi. Và thực tế thì trong RFC 3280 đã khuyến cáo là bỏ qua việc sử dụng 2 trường mới trên của X.509 version 2 do lo ngại có thể có sự xung đột xảy ra nếu như hai chứng chỉ có cùng Subject Name và Subject Unique ID. X.509 version 3 Được ra đời vào năm 1996, định dạng X.509 version 3 được bổ sung thêm các phần mở rộng (extension) để khắc phục các vấn đề liên quan tới việc so khớp Issuer Unique ID và Subject Unique ID cũng như là các vấn đề về xác thực chứng chỉ. Một chứng chỉ X.509 version 3 co thể chứa một hoặc nhiều extension, như được thể hiện trong hình dưới đây:

Mỗi extension trong chứng chỉ X.509 version 3 gồm 3 phần: Extension Identifier: là một mã nhận dạng đối tượng (Object Identifier – OID) cho biết kiểu định dạng và các định nghĩa của extension. Criticality Flag: là một dấu hiệu cho biết thông tin trong extension có quan trọng (critical) hay không. Nếu một ứng dụng không thể nhận diện được trạng thái critical của extension hoặc extension không hề chứa giá trị nào thì chứng chỉ đó không thể được chấp nhận hoặc được sử dụng. Nếu mục criticality flag này không được thiết lập thì một có thể sử dụng chứng chỉ ngay cả khi ứng dụng đó không nhận diện được extension. Extension Value: là giá trị được gán cho extension. Nó phụ thuộc vào từng extension cụ thể. Trong một chứng chỉ X.509 version 3, các extension sau có thể có là: Authority Key Identifier: extension này có thể chứa một hoặc hai giá trị, chúng có thể là: + Subject Name của CA và Serial Number của chứng chỉ của CA mà đã cấp phát chứng chỉ này. Giá trị băm của khóa công khai của chứng chỉ của CA mà đã cấp phát chứng chỉ này. + Subject Key Identifier: extension này chứa giá trị băm của khóa công khai của chứng chỉ. Key Usage: một CA, người dùng, máy tính, thiết bị mạng hoặc dịch vụ có thể sở hữu nhiều hơn một chứng chỉ. Extension này định nghĩa các dịch vụ bảo mật mà một chứng chỉ có thể cung cấp như: + Digital Signature: khóa công khai có thể được dùng để kiểm tra chữ ký. Khóa này cũng được sử dụng để xác thực máy khách và xác minh nguồn gốc của dữ liệu. + Non-Repudiation: khóa công khai có thể được dùng để xác minh nhận dạng của người ký, ngăn chặn người ký này từ chối rằng họ không hề ký lên thông điệp hoặc đối tượng nào đó. + Key Encipherment: khóa công khai có thể được dùng để trao đổi khóa, vú dụ như đối xứng (hoặc khóa phiên). Giá trị này được dùng khi một khóa RSA được dùng cho việc quản lý khóa. + Data Encipherment: khóa công khai có thể được dùng để mã hóa dữ liệu một cách trực tiếp thay vì phải trao đổi một khóa đối xứng (hay khóa phiên) để mã hóa dữ liệu. + Key Agreement: khóa công khai có thể được dùng để trao đổi khóa, ví dự như khóa đối xứng. Giá trị này được dùng khi một khóa Diffie-Hellman được dùng cho việc quản lý khóa. + Key Cert Sign: khóa công khai có thể được dùng để kiểm tra chữ ký của chứng chỉ số. CRL Sign: khóa công khai có thể được dùng để kiểm tra chữ ký của CRL (danh sách chứa các chứng chỉ bị thu hồi). + Encipher Only: giá trị này được dùng kết hợp với các extension Key Agreement và Key Usage. Kết quả là khóa đối xứng chỉ có thể được dùng để mã hóa dữ liệu. + Decipher Only: giá trị này được dùng kết hợp với các extension Key Agreement và Key Usage. Kết quả là khóa đối xứng chỉ có thể được dùng để mã hóa dữ liệu. Private Key Usage Period: extension này cho phép khóa bí mật có khoảng thời gian hiệu lực khác so với khoảng thời gian hiệu lực của chứng chỉ. Giá trị này có thể được đặt ngắn hơn so với khoảng thời gian hiệu lực của chứng chỉ. Điều này giúp khóa bí mật có thể được dùng để ký lên các tài liệu trong một khoảng thời gian ngắn (ví dụ, một năm) trong khi khóa công khai có thể được dùng để xác minh chữ ký trong khoảng thời gian hiệu lực của chứng chỉ là 5 năm. Certificate Policies: extension này mô tả các chính sách và thủ tục được dùng để xác minh chủ thể của chứng chỉ trước khi chứng chỉ được cấp phát. Các chính sách chứng chỉ được đại diện bởi các OID. Ngoài ra, một chính sách chứng chỉ có thể bao gồm một đường dẫn (URL) tới trang web mô tả nội dung của chính sách và thủ tục. Policy Mappings: extension này cho phép chuyển dịch thông tin về chính sách giữa hai tổ chức. Ví dụ, thử tưởng tượng rằng một tổ chức định nghĩa một chính sách chứng chỉ có tên là Management Signing mà trong đó các chứng chỉ được dùng để ký lên một lượng lớn các đơn đặt hàng. Một tổ chức khác có thể có một chính sách chứng chỉ tên là Large Orders mà cũng được dùng để ký lên một lượng lớn các đơn đặt hàng. Khi đó, Policy Mapping cho phép hai chính sách chứng chỉ này được đánh giá ngang nhau. Subject Alternative Name: extension này cung cấp một danh sách các tên thay thế cho chủ thể của chứng chỉ. Trong khi định dạng cho Subject Name thường tuân theo chuẩn X.500 thì Subject Alternative Name cho phép thể hiện theo các dạng khác như User Principal Name (UPN), địa chỉ email, địa chỉ IP hoặc tên miền (DNS). Issuer Alternative Name: extension này cung cấp một danh sách các tên thay thế cho CA. Mặc dù thường không được áp dụng nhưng extension này có thể chứa địa chỉ email của CA. Subject Dir Attribute: extension này có thể bao gồm bất kỳ thuộc tính nào từ danh mục LDAP hoặc X.500 của tổ chức, ví dụ, thuộc tính country. Extension này có thể chứa nhiều thuộc tinh và với mỗi thuộc tính phải gồm OID và giá trị tương ứng của nó. Basic Constraints: extension này cho biết chứng chỉ có phải của CA hay của các chủ thể như người dùng, máy tính, thiết bị, dịch vụ. Ngoài ra, extension này còn bao gồm một rằng buộc về độ dài của đường dẫn mà giới hạn số lượng các CA thứ cấp (subordinate CA) có thể tồn tại bên dưới CA mà cấp phát chứng chỉ này. Name Constraints: extension này cho phép một tổ chức chỉ định không gian tên (namespace) nào được phép hoặc không được phép sử dụng trong chứng chỉ. Policy Constraints: extension này có thể có trong các chứng chỉ của CA. Nó có thể ngăn cấm Policy Mapping giữa các CA hoặc yêu cầu mỗi chứng chỉ trong chuỗi chứng chỉ phải bao gồm một OID của chính sách chứng chỉ. Enhanced Key Usage: extension này cho biết khóa công khai của chứng chỉ có thể được sử dụng như thế nào. Những cái này không có trong extension Key Usage. Ví dụ, Client Authentication (có OID là 1.3.6.1.5.5.7.3.2), Server Authentication (có OID là 1.3.6.1.5.5.7.3.1), và Secure E-mail (có OID là 1.3.6.1.5.5.7.3.4). Khi ứng dụng nhận được một chứng chỉ, nó có thể yêu cầu sự có mặt của một OID trong các OID kể trên. CRL Distribution Points: extension này chứa một hoặc nhiều URL dẫn tới tập tin chứa danh sách các chứng chỉ đã bị thu hồi (CRL) được phát hành bởi CA. Nếu việc kiểm tra trạng thái thu hồi của chứng chỉ được cho phép thì một ứng dụng sẽ sử dụng các URL này để tải về phiên bản cập nhật của CRL. Các URL có thể sử dụng một trong các giao thức như HTTP, LDAP, FTP, File. Authority Information Access: extension này có thể chứa một hoặc nhiều URL dẫn tới chứng chỉ của CA. Một ứng dụng sử dụng URL này để tải về chứng chỉ của CA khi xây dựng chuỗi chứng chỉ nếu như nó không có sẵn trong bộ nhớ đệm của ứng dụng. Freshest CRL: extension này chứa một hoặc nhiều URL dẫn tới delta CRL do CA phát hành. Delta CRL chỉ chứa các chứng chỉ bị thu hồi kể từ lần cuối base CRl được phát hành. Nếu việc kiểm tra trạng thái thu hồi của chứng chỉ được cho phép thì một ứng dụng sẽ sử dụng các URL này để tải về phiên bản cập nhật của delta CRL. Các URL có thể sử dụng một trong các giao thức như HTTP, LDAP, FTP, File. Subject Information Access: extension này chứa thông tin cho biết cách thức để truy cập tới các các chi tiết khác về chủ thể của chứng chỉ. Nếu đây là chứng chỉ của CA thì thông tin này có thể bao gồm các chi tiết về các dịch vụ xác minh chứng chỉ hay chính sách của CA. Nếu chứng chỉ được cấp cho người dùng, máy tính, thiết bị mạng, hoặc dịch vụ thì extension này có thể chứa thông tin về các dịch vụ được các chủ thể này cung cấp và cách thức để truy cập tới các dịch vụ đó. Ngoài việc giới thiệu thêm các extension như đã nêu ở trên thì trường Version của chứng chỉ X.509 version 3 sẽ có giá trị là 3 để cho biết phiên bản của chứng chỉ. –manthang]]> /hvaonline/posts/list/42937.html#267147 /hvaonline/posts/list/42937.html#267147 GMT