One document matched: draft-ietf-cat-pim-01.txt
Differences from draft-ietf-cat-pim-00.txt
Internet Draft C. Adams
draft-ietf-cat-pim-01.txt Bell-Northern Research
Expires: August 15, 1996 Feb. 15, 1996
PEM-Based IDUP Mechanism (PIM)
STATUS OF THIS MEMO
This document is an Internet-Draft. 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."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (West Coast), or munnari.oz.au (Pacific Rim).
Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.
ABSTRACT
The Independent Data Unit Protection Generic Security Service
Application Program Interface (IDUP-GSS-API) extends the GSS-API
[RFC-1508] for applications requiring protection of a generic data
unit (such as a file or message) in a way which is independent of the
protection of any other data unit and independent of any concurrent
contact with designated "receivers" of the data unit. Thus, it is
suitable for applications such as secure electronic mail where data
needs to be protected without any on-line connection with the
intended recipient(s) of that data. Subsequent to being protected,
the independent data unit can be transferred to the recipient(s) - or
to an archive - perhaps to be processed only days or years later.
This document is a companion document to IDUP-GSS-API [IDUP] and
IDUP: C-bindings [IDUP-C]. It provides a PEM-based [RFC-1421]
mechanism for IDUP (analogous to [Kerb5] or [SPKM] which provide
underlying mechanisms for [GSS]). This mechanism specifies both
encapsulation and non-encapsulation procedures for creating PEM
messages. If encapsulation is chosen by the calling application,
then the PIM implementation creates true PEM messages. On the other
hand, if encapsulation is not chosen, then the PIM implementation
performs the canonicalization, security, and encoding (see
[RFC-1421]) aspects of PEM, returning to the caller a true PEM header
and transportable data; applications wishing to build PEM messages
must then concatenate the header and the encoded IDU with the
necessary delimiters and CRLFs to complete PEM message construction.
Adams Document Expiration: 15 Aug. 1996 1
1. INTRODUCTION
The Independent Data Unit Protection Generic Security Service
Application Program Interface (IDUP-GSS-API) [IDUP] provides security
services to calling applications in a local environment. This
PEM-Based IDUP Mechanism (PIM) allows an application to "protect" an
independent data unit (IDU) for future use and to "unprotect" a
protected IDU, applying security services such as confidentiality,
integrity and data origin authentication on a per-data-unit basis.
There are four stages to using the IDUP-GSS-API:
(a) The application acquires a set of credentials with which it may
bind its identity to a data unit. The application's credentials
vouch for its global identity, which may or may not be related to
the local username under which it is running.
(b) The application establishes a security environment using its
credentials. The security environment contains whatever
information is necessary in order to provide per-IDU security
services.
(c) Per-IDU calls are invoked to provide one or both of the
following for PEM-based IDU protection:
- data origin authentication with data integrity;
- data confidentiality.
The application wishing to "protect" an IDU will call the
protection set of IDUP-GSS-API routines, specifying the
appropriate security environment. The recipient (wishing to
"unprotect" the data") will pass the protected IDU (P-IDU) to
the unprotection set of routines to remove the protection and/or
to validate the data.
(d) At the completion of a security environment (which may extend
across several protection and unprotection operations), the
application calls an IDUP-GSS-API routine to abolish the security
environment.
2. INDEPENDENT DATA UNIT PROTECTION MECHANISM
2.1. Protection Token
A P-IDU is a caller-opaque data structure that PIM uses to store
protection information regarding an IDU. It is an OCTET STRING
generated during the protection set of calls for use by PIM or by
another mechanism during the unprotection set of calls. If
encapsulation is requested by the calling application, then the P-IDU
consists entirely of the contents of the pidu_buffer, output_buffer,
and final_pidu_buffer parameters used in the IDUP protection set of
calls. If encapsulation is not used, the P-IDU consists of the
logical concatenation of the unencapsulated_token parameter in each
Prot_Service parameter bundle, the contents of the midu_buffer,
output_buffer, and final_midu_buffer parameters, and other
PEM-specific delimiter values (see Section 4.1 below).
Adams Document Expiration: 15 Aug. 1996 2
2.2. Security Services
PIM makes use of the security services given in Section 1(c) above.
The security services "proof of origin" and "service solicitation"
(such as a request for "proof of delivery"), as defined in [IDUP],
are not included in this PEM-based IDUP mechanism. Receipt
generation and processing are beyond the scope of [RFC-1421] and
other types of non-repudiable evidence generation and processing are
not addressed in this version of PIM but may be included in future
versions of this specification.
2.3. IDUP Parameter Bundle Uses and Defaults
The following parameter bundle uses and defaults are specified.
Mech_Specific_Info
- NOT USED (the only acceptable input, therefore, is NULL)
Idu_Sensitivity
- NOT USED (the only acceptable input, therefore, is NULL)
Service_Creation_Info
- NOT USED (the only acceptable input, therefore, is NULL)
Service_Verification_Info
- NOT USED (the only acceptable input, therefore, is NULL)
Quality
- the qop_algs parameter is supported. For PIM implementation and
interoperability purposes, the following qop_algs values are
defined.
* For the Confidentiality MA field: 0001 (1) = DES-CBC
(this is also defined to be the TS "DEFAULT" conf. alg.).
* For the Integrity MA field: 0001 (1) = RSA-MD5
(this is also defined to be the TS "DEFAULT" int. alg.).
- the parameters validity, policy_id, and allow_policy_mapping
are NOT USED (NULLs are therefore the only acceptable input)
Idu_Information
- the idu_type parameter must have a value representing "RFC822"
or any other valid PEM "Content-Domain" (the DEFAULT value is
specified to be "RFC822");
- the idu_title parameter is NOT USED (the only acceptable input,
therefore, is NULL)
Adams Document Expiration: 15 Aug. 1996 3
Prot_Information
- the originator_name and idu_type (in Idu_Information) parameters
are read from the PEM header information and are output by
IDUP_Start_Unprotect. The originator_name parameter shall be
formatted as follows (specified in the descriptive grammar BNF;
see [RFC-822] and Section 4.1 below):
<originator-name> ::=
[<entity-id>] CRLF
[<issuing-auth>] CRLF
[<version-expiration>] CRLF
<entity-id> ::= 1*(<ia-char> / ",")
<issuing-auth> ::= 1*(<ia-char> / ",")
<version-expiration> ::= 1*(<ia-char> / ",")
The actual values for <originator-name> may be read directly
from the P-IDU (if <origid-symm> or <origid-asymm> are present)
or may be extracted from the originator's certificate (if <cert>
is present).
- all other parameters are NOT USED (and therefore NULL)
Special_Conditions
- NOT USED (the only acceptable input, therefore, is NULL)
Target_Info
- this bundle is used as described in IDUP; no DEFAULT values are
specified
General_Service_Data
- the unencapsulated_token parameter is used if
encapsulation_request is FALSE;
- the minor_status parameter is used to return minor status values
as specified in Section 5 below.
Prot_Service
- the prot_service_type parameter may have a value of "1"
("perform unsolicited service") or NULL (which specifies the
DEFAULT value of "1");
- the service_id parameter must have a value representing
"PER_CONF" or "PER_DOA";
- the parameters Service_Creation_Info, service_to,
Service_Verification_Info, and service_verification_info_id are
NOT USED (and therefore NULL)
Unprot_Service
- the unprot_service_type parameter will always have a value of
"1" ("receive unsolicited service");
- the service_id parameter will have a value representing
"REC_CONF" or "REC_DOA";
- the parameters service_verification_info_id,
Service_Verification_Info, service_to, and
Service_Creation_Info, are NOT USED (and therefore NULL)
Adams Document Expiration: 15 Aug. 1996 4
3. SUMMARY OF TRANSFORMATIONS
If confidentiality is applied during the IDUP protection set of
calls, then the following composition of transformations is applied
to the IDU for full PEM compliance; see [RFC-1421] for definitions of
"encode" and "canonicalize":
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order, to
unprotect the IDU:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form))).
If confidentiality is not applied (i.e., data origin authentication
with data integrity alone is applied), then the IDU goes through the
following operation:
Transmit_Form = Canonicalize(Local_Form)
Again, this needs to be inverted by the receiver:
Local_Form = DeCanonicalize(Transmit_Form).
It is the responsibility of the underlying PIM implementation to
perform all transformations given in this section (regardless of
whether or not encapsulation is requested by the calling application)
unless the transformation is unnecessary (e.g., the input data is
already in canonical form).
Note that the Local_Form and the functions to transform messages to
and from Canonical_Form may vary between the protector and
unprotector systems provided there is no loss of information.
4. TOKEN FORMAT
This section discusses protocol-visible characteristics of PIM; it
defines elements of protocol for interoperability and is independent
of any IDUP language bindings.
The PIM IDUP-GSS-API mechanism will be identified by an Object
Identifier representing "PIM" , having the value:
{ iso(1) org(3) dod(5) internet(1) security(5) PIM(xx) }
The token transferred between IDUP-GSS-API peers (for IDU protection
and unprotection purposes) is defined.
Adams Document Expiration: 15 Aug. 1996 5
4.1. The Protected-IDU (P-IDU) Token
The OCTET STRING "protpart" conforms to the Privacy Enhanced Mail
header format described in [RFC-1421]. The Protected-IDU (P-IDU) is
the concatenation of protpart and the "idupart" (which may be the
canonicalized, encoded version of the original IDU or, if
confidentiality was applied, the encrypted IDU). If encapsulation
is requested by the calling application, this concatenation is
handled entirely by the PIM implementation and the application
needs to deal only with the resulting pidu_buffer output parameters
from the protection set of calls.
If encapsulation is not requested, the calling application (not the
PIM implementation) is responsible for the creation of the P-IDU from
the protpart and the idupart. In this case, the protpart is supplied
by PIM in the unencapsulated_token parameter of one of the
Prot_Service parameter bundles (either bundle can be chosen if both
PER_CONF and PER_DOA are requested) and idupart is supplied in the
midu_buffer parameters. For example, to create a true PEM message,
the application would concatenate the pre-Encapsulation-Boundary
delimiter ("-----BEGIN PRIVACY-ENHANCED MESSAGE-----"), CRLF,
protpart, CRLF, idupart, the post-Encapsulation-Boundary delimiter
("-----END PRIVACY-ENHANCED MESSAGE-----"), and a final CRLF. (Note
that the PIM implementation must perform canonicalization and message
encoding (as per [RFC-1421], Section 4.3.2.4), as required, as part
of the protection process.)
In this section both idupart and protpart are specified in the
descriptive grammar BNF.
; PIM BNF representation, using RFC-822 notation [RFC-822].
; Imports field meta-syntax (field, field-name, field-body,
; field-body-contents) from RFC-822.
; Imports DIGIT, ALPHA, text, CRLF from RFC-822.
<idupart> ::= 1*<binchar> ; for ENCRYPTED msgs (enc. IDU)
/ 1*(<text> CRLF) ; for MIC-CLEAR msgs (orig. IDU)
<binchar> = <any binary character> ; (0-377 (octal), 0-255 (decimal))
<protpart> ::= <normalhdr>
<normalhdr> ::=
<proctype>
<contentdomain>
[<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case
; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case
; recipflds included for ENCRYPTED proc type
<origflds> ::=
<asymmorig> [<keyinfo>] *(<issuercert>) <micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric
<recipflds> ::= <recipid> <keyinfo>
<asymmorig> ::= <origid-asymm> / <cert>
Adams Document Expiration: 15 Aug. 1996 6
; definitions for PEM header fields
<proctype> ::= "Proc-Type" ":" "4" "," <pimtypes> CRLF
<pimtypes> ::= "ENCRYPTED" / "MIC-CLEAR"
<contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
<contentdescrip> ::= "RFC822"
; This specification defines one value ("RFC822") for
; <contentdescrip>: other values may be defined in future in
; separate or successor documents
<dekinfo> ::=
"DEK-Info" ":" <dekalgid> ["," <dekparameters>] CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<cert> ::= "Originator-Certificate" ":" <encbin> CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld>
<IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<encbin> ::= 1*<encbingrp>
<encbingrp> ::= 4*4<encbinchar>
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<recipid> ::= <recipid-symm> / <recipid-asymm>
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
<symencdek> "," <symencmic> CRLF ; symmetric case
/ "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF ; asymmetric case
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
; The following items are defined in [RFC-1423] and are meant to
; serve as RECOMMENDED algorithms for PIM implementation
; interoperability purposes. It is recognized that this list may
; be altered in future versions of this specification and may grow
; over time.
Adams Document Expiration: 15 Aug. 1996 7
<dekalgid> ::= "DES-CBC"
<dekparameters> ::= <DESCBCparameters>
<DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16>
<hexchar16> ::= 16*16<hexchar>
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
<micalgid> ::= "RSA-MD2" / "RSA-MD5"
<ikalgid> ::= "DES-EDE" / "DES-ECB" / "RSA"
<symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
<DESECBencDESCBC> ::= <hexchar16>
<DESEDEencDESCBC> ::= <hexchar16>
<symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>
<DESECBencRSAMD2> ::= 2*2<hexchar16>
<DESECBencRSAMD5> ::= 2*2<hexchar16>
<asymencdek> ::= <RSAencdek>
<RSAencdek> ::= <encbin>
<asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin>
4.2. Examples of Protection Tokens
4.2.1 Integrity Only (Example)
protpart = {
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
EtE7K2QDeVMCyXsdJlA8fA==
}
idupart = {
This is the (canonicalized) plaintext message part.
}
Adams Document Expiration: 15 Aug. 1996 8
4.2.2 Confidentiality-Only (Example)
protpart = {
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: john.doe@abc.com,,
Recipient-ID-Symmetric: john.smith@xyz.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: rpm@ghi.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
}
idupart = {
[This would contain canonicalized, encrypted, PEM-encoded data.]
}
4.2.3. Integrity And Confidentiality (Example)
protpart = {
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,93652FD82C1A4202
Originator-Certificate:
MIIBXDCCAQwCBAUSVXQwBwYFKw4DAgMwGzELMAkGA1UEBhMCQ0ExDDAKBgNVBAoT
A0JOUjAmFxE5NTAyMjAxMzM2MjYrMDUwMBcROTcwMjIwMTMzNjI2KzA1MDAwXDEL
MAkGA1UEBhMCQ0ExDDAKBgNVBAoTA0JOUjEPMA0GA1UEBxMGT3R0YXdhMS4wDgYD
VQQFEwcxNjUxNjIzMBwGA1UEAxMVQ2FybGlzbGUgKEMuTS4pIEFkYW1zMFgwCwYJ
KoZIhvcNAQEBA0kAMEYCQNkfTpKJ7ifDsYcHVqP3fNEVVUiyUPTNzssZza4lsHoL
bIOJ2D1kBDDD951ZK2hGxcRni4YSvAM9nCZqXz+sVZECAgADMAcGBSsOAwIDA0EA
PqCnzJw7Nfuhngf293b3bR56YzdTnkmFi9giB84maOGGPwArTaMpGCo8Y9kv2HJP
0ADCPNI2/aNXSOw5btR7Fg==
Key-Info: RSA,
pHavGvGlKboUVnokdrmIxO2IlgWjAWFAZFigLiZzd8gugjHFkUCMSFk7/IiT7tl7
v/hpcCbTZy/e5MoQIGwaMA==
Originator-Certificate:
MIIBXDCCAQwCBAUSVXMwBwYFKw4DAgMwGzELMAkGA1UEBhMCQ0ExDDAKBgNVBAoT
A0JOUjAmFxE5NTAyMjAxMzM2MTkrMDUwMBcROTcwODIwMTMzNjE5KzA1MDAwXDEL
MAkGA1UEBhMCQ0ExDDAKBgNVBAoTA0JOUjEPMA0GA1UEBxMGT3R0YXdhMS4wDgYD
VQQFEwcxNjUxNjIzMBwGA1UEAxMVQ2FybGlzbGUgKEMuTS4pIEFkYW1zMFgwCwYJ
KoZIhvcNAQEBA0kAMEYCQNSWNlYC7p+nNpdSHNYN7ZM46J5Oijmg0G5kUhs3Q1Ow
9+RNz9T3+8q1aE90k3ypt6Zp6HSWsaIjqCzP+1n0oTECAgADMAcGBSsOAwIDA0EA
QcJjIOd1lain8Uk1d+VNDsCiWVp2z1CsFLi+ce5yGExm0b2Xp2FVz4ilelbmQxLc
WrRu2VKIrCLfnI/tS34Xwg==
MIC-Info: RSA-MD5, RSA,
QZrlTrHIW7x464VXqVNm2ftGge7O0fva05xAXuD1c4tQIMBITWy8I1y3NGkOqF5F
mGf+b8GZ+4RsBN8H4WmOnzlE2h5Ncr4p
Recipient-ID-Asymmetric:
MBsxCzAJBgNVBAYTAkNBMQwwCgYDVQQKEwNCTlI=,792860365
Key-Info:
ijfTFl6oj0h/W0iwgtBNsHoEGHAdYQ9fPY/Y2IVgT5GxDoZNq0Qg+JOEPZvgZF5A
gvXpi41DG7ZS7X7IS+z9Ww==
}
idupart = {
[This would contain canonicalized, encrypted, PEM-encoded data.]
}
Adams Document Expiration: 15 Aug. 1996 9
5. MINOR STATUS CODES
No minor status codes have yet been defined for PIM.
6. SECURITY CONSIDERATIONS
Security issues are discussed throughout this memo.
7. REFERENCES
[IDUP] C. Adams, "Independent Data Unit Protection Generic Security
Service Application Program Interface (IDUP-GSS-API)",
Internet Draft draft-ietf-cat-idup-gss.0x.txt (work in
progress).
[IDUP-C] D. Thakkar, D. Grebovich, "Independent Data Unit Protection
Generic Security Service Application Program Interface:
C-bindigs", Internet Draft draft-ietf-cat-idup-cbind-0x.txt
(work in progress).
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC-1421] J. Linn, "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures",
RFC 1421.
[RFC-1423] D. Balenson, "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423.
[RFC-1508] J. Linn, "Generic Security Service Application Program
Interface", RFC 1508.
[KRB5] J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
Internet Draft draft-ietf-cat-kerb5gss-0x.txt (work in
progress).
[SPKM] C. Adams, "The Simple Public-Key GSS-API Mechanism
(SPKM)", Internet Draft draft-ietf-cat-spkmgss-0x.txt (work
in progress).
8. AUTHOR'S ADDRESS
Carlisle Adams
Bell-Northern Research, Ltd.
P.O.Box 3511, Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 (613) 763-9008
E-mail: cadams@bnr.ca
Adams Document Expiration: 15 Aug. 1996 10
| PAFTECH AB 2003-2026 | 2026-04-23 10:47:05 |