From db317124acec5d83b93485a0964b1b33ab33bb41 Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Sun, 12 Dec 2010 14:12:42 +0000 Subject: Updated the various RFC links to more relevant versions. --- trust-assertions.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/trust-assertions.xml b/trust-assertions.xml index 1e7754d..6a7e4a6 100644 --- a/trust-assertions.xml +++ b/trust-assertions.xml @@ -195,7 +195,7 @@ The CKA_X_PURPOSE attribute contains a string which represents the purpose of the trust assertion. These are generally OIDs. The following predefined values match those of the - Extended Key Usage X.509 extension. + Extended Key Usage X.509 extension. Other values may be used when interoperability of the trust assertion between multiple applications is not required. @@ -288,7 +288,7 @@ An anchored certificate is a trust assertion which is to be used with a certificate authority that has signed other trusted certificates. It is to be used as the anchor in a - certificate chain. + certificate chain. Because it is a positive trust assertion, the certificate is referenced by using the entire DER encoding of the certificate. @@ -430,7 +430,7 @@ Building a Certificate Chain During TLS or other certificate verification operations, a - certificate chain + certificate chain must be built. The certificate chain starts with a endpoint certificate for the peer, and usually ends with a certificate explicitly trusted in some way, such as a certificate authority trust anchor. The certificates in the @@ -552,7 +552,7 @@
Why refer to certificates in negative trust assertions by issuer and serial number? - Certificate revocation lists + Certificate revocation lists do not generally contain the full value of the certificate or a hash thereof. They simply contain serial numbers, which when combined with the issuer of the certificate revocation list, are meant to uniquely identify a given certificate. -- cgit v1.2.3