-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC 2026. Internet-Drafts are
-working documents of the Internet Engineering Task Force (IETF), its
-areas, and its working groups. Note that other groups may also
-distribute working documents as Internet-Drafts.
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
2.3 Attribute Data Types ...................................... 4
2.4 Attribute Payload ......................................... 4
2.5 Attributes ................................................ 5
2.3 Attribute Data Types ...................................... 4
2.4 Attribute Payload ......................................... 4
2.5 Attributes ................................................ 5
4 References .................................................... 12
5 Author's Address .............................................. 13
6 Full Copyright Statement ...................................... 13
4 References .................................................... 12
5 Author's Address .............................................. 13
6 Full Copyright Statement ...................................... 13
-The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
MAY, and OPTIONAL, when they appear in this document, are to be
interpreted as described in [RFC2119].
MAY, and OPTIONAL, when they appear in this document, are to be
interpreted as described in [RFC2119].
information, or with the required precision that may be desired in
some applications. It is therefore RECOMMENDED that this attribute
would be used to provide only basic and constant user information,
information, or with the required precision that may be desired in
some applications. It is therefore RECOMMENDED that this attribute
would be used to provide only basic and constant user information,
Note that these public keys are intended for signing. Some
certificates may have a key usage restrictions and same key cannot
be used for both encryption and signing. Therefore, the name
Note that these public keys are intended for signing. Some
certificates may have a key usage restrictions and same key cannot
be used for both encryption and signing. Therefore, the name
This attribute includes a third party server or authority public
key or CA certificate and MUST be present if the attribute
ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
This attribute includes a third party server or authority public
key or CA certificate and MUST be present if the attribute
ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
the digital signature SHOULD be verifiable with the first set public
attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
the digital signature SHOULD be verifiable with the first set public
This attribute value includes digital signature of all Attribute
Payloads except this attribute. This signature can be provided by
This attribute value includes digital signature of all Attribute
Payloads except this attribute. This signature can be provided by
- the user. This attribute SHOULD be last attribute provided in the
- reply so that it is easier for the receiver to compute the signature
+ the user. This attribute SHOULD be last attribute provided in the
+ reply so that it is easier for the receiver to compute the signature
data to be verified. The format and encoding of this attribute
depends on the public key or certificate used to produce the
signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
data to be verified. The format and encoding of this attribute
depends on the public key or certificate used to produce the
signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
information provided by the user. How it verifies this information
is out of scope of this document, however it may base its
information to a previous registration information and current
information provided by the user. How it verifies this information
is out of scope of this document, however it may base its
information to a previous registration information and current
last when provided, so that it is easier for the receiver to
compute the signature data to be verified. The format for this
attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
last when provided, so that it is easier for the receiver to
compute the signature data to be verified. The format for this
attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2426, September 1998.
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
RFC 2426, September 1998.
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
[RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
November 1998.
[RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
November 1998.
-[RFC2459] Housley, R., et al, "Internet X.509 Public Key
+[RFC2459] Housley, R., et al, "Internet X.509 Public Key
Infrastructure, Certificate and CRL Profile", RFC 2459,
January 1999.
Infrastructure, Certificate and CRL Profile", RFC 2459,
January 1999.
-[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
Internet Draft.
[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
Internet Draft.
[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.