One document matched: draft-hotz-kx509-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC4211 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4211.xml">
<!ENTITY RFC4556 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-hotz-kx509-06.txt" ipr="trust200902">
<front>
<title abbrev="KX509">KX509 Kerberized Certificate Issuance Protocol in
Use in 2012</title>
<author fullname="Henry B. Hotz" initials="H. B." surname="Hotz">
<organization>Jet Propulsion Laboratory, California Institute of
Technology</organization>
<address>
<postal>
<street>4800 Oak Grove Dr.</street>
<!-- Reorder these if your country does things differently -->
<city>Pasadena</city>
<region>CA</region>
<code>91109</code>
<country>US</country>
</postal>
<phone>+01 818 354-4880</phone>
<email>hotz@jpl.nasa.gov</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Russ Allbery" initials="R." surname="Allbery">
<organization>Stanford University</organization>
<address>
<postal>
<street>P.O. Box 20066</street>
<city>Stanford</city>
<region>CA</region>
<code>94309</code>
<country>US</country>
</postal>
<email>rra@stanford.edu</email>
<uri>http://www.eyrie.org/~eagle/</uri>
</address>
</author>
<date month="July" year="2012" />
<area>General</area>
<!---->
<keyword>protocol</keyword>
<abstract>
<t>This document describes a protocol, called kx509, for using Kerberos
tickets to acquire X.509 certificates. These certificates may be used
for many of the same purposes as X.509 certificates acquired by other
means, but if a Kerberos infrastructure already exists then the overhead
of using kx509 may be much less.</t>
<t>While not standardized, this protocol is already in use at several
large organizations, and certificates issued with this protocol are
recognized by the International Grid Trust Federation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The two primary ways of providing cryptographically secure
identification on the Internet are Kerberos tickets <xref
target="RFC4120"></xref>, and X.509 <xref target="RFC5280"></xref> and
<xref target="X.509"></xref> certificates.</t>
<t>In practical IT infrastructure where both are in use, it's highly
desirable to deploy their support in a way which guarantees they both
authoritatively refer to the same entities. There is already a
widely-adopted standard for using X.509 certificates to acquire
corresponding Kerberos tickets called PKINIT <xref
target="RFC4556"></xref>. This document describes the kx509 protocol for
supporting the symmetric operation of acquiring X.509 certificates using
Kerberos tickets.</t>
<t>Preparing and reviewing this document exposed a number of issues
which are discussed in the security considerations. Unfortunately, some
of them can only be addressed with an incompatible upgrade to this
protocol. The IETF's Kerberos working group has an expected work item to
address these issues.</t>
<t>The International Grid Trust Federation <xref target="IGTF"></xref>
supports the use of Short Lived Credential Services <xref
target="SLCS"></xref> as a means to authenticate for resource usage
based on other, native identity stores which an organization maintains.
X.509 certificates issued using the kx509 protocol based on a Kerberos
identity is one of the recognized Credential Services. The certificate
profile for that use is outside the scope of this RFC, but is described
in <xref target="GRID-prof"></xref>.</t>
<t>In normal operation kx509 can be used after a Kerberos
ticket-granting-ticket (TGT) is acquired, which is most likely during
user login. First, the client generates a RSA public/private key-pair.
Next, using the Kerberos ticket-granting-ticket, it acquires a Kerberos
service ticket for the KCA (Kerberized Certificate Authority), and uses
this to send the public half of its key-pair. The KCA will decrypt the
service ticket, verify the integrity of the incoming packet, determine
the identity of the user, and use the session key to send back a
corresponding X.509 certificate.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Protocol Data">
<t>The protocol consists of a single request/reply exchange using
UDP.</t>
<t>Both the request and the reply packet begin with four bytes of
version ID information, followed by a DER encoded ASN.1 message. The
first two bytes of the version ID are reserved. They MUST be set to zero
when sent, and SHOULD be ignored when received. The third and fourth
bytes are the major and minor version numbers, respectively. The version
of the protocol described in this document is designated 2.0, so the
first four bytes of the packet are 0, 0, 2, 0.</t>
<t>Incompatible variations of this protocol MUST use a different major
version number.</t>
<section title="Request Packet">
<t>The request consists of a version ID, followed by a DER encoded
ASN.1 message containing a Kerberos AP_REQ, integrity check data on
the request, and public key generated by the client. The ASN.1
encoding is:</t>
<t></t>
<figure>
<artwork type="ASN.1"><![CDATA[KX509Request ::= SEQUENCE {
ap-req OCTET STRING,
pk-hash OCTET STRING,
pk-key OCTET STRING
}]]></artwork>
</figure>
<t>The ap-req is as described in <xref target="RFC4120"></xref>
Section 5.5.1.</t>
<t>The pk-hash is HMAC using SHA-1 as the underlying hash. All 160
bits are sent. The key used is the Kerberos session key. The data to
be hashed is the concatenation of <list style="symbols">
<t>4-byte version ID at the beginning of the packet.</t>
<t>OCTET STRING of the ap-req.</t>
<t>OCTET STRING of the pk-key.</t>
</list></t>
<t>The pk-key contains a public key. This key and its corresponding
private key are generated by the client before contacting the server.
Implementations of this protocol MUST support RSA keys, in which case
the key is a DER encoded RSAPublicKey as defined in <xref
target="RFC3447"></xref>, section A.1.1, and then stored in this octet
string in the request. Its encoding as an OCTET STRING starts with the
0x30 byte sequence at the beginning of a DER encoded RSAPublicKey. Use
of other public-key types is not defined.</t>
<t>Appendix C shows an example request packet.</t>
</section>
<section title="Reply Packet">
<t>The reply consists of a version ID, followed by a DER encoded ASN.1
message containing an error code, and an optional authentication hash,
optional certificate, and optional error text. The service SHOULD
return replies of the same version as the request where possible.</t>
<t></t>
<figure>
<artwork type="ASN.1"><![CDATA[KX509Response ::= SEQUENCE {
error-code[0] INTEGER DEFAULT 0,
hash[1] OCTET STRING OPTIONAL,
certificate[2] OCTET STRING OPTIONAL,
e-text[3] VisibleString OPTIONAL
}]]></artwork>
</figure>
<t>Although the format of the reply contains independently optional
objects, the server MUST only generate replies with one of the
following allowed combinations.</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<ttcol></ttcol>
<ttcol></ttcol>
<c></c>
<c>hash</c>
<c>certificate</c>
<c></c>
<c>error-code</c>
<c>hash</c>
<c></c>
<c>e-text</c>
<c>error-code</c>
<c></c>
<c></c>
<c>e-text</c>
</texttable>
<t>The first case is returned when the server successfully generates a
certificate for the user. The certificate is a DER encoded Certificate
as defined in <xref target="RFC5280"></xref> Section A, page 116. Its
encoding as an OCTET STRING starts with the 0x30 byte sequence that is
at the beginning of a DER encoded Certificate.</t>
<t>The second case is returned when the server successfully
authenticates the user and their key, but is unable for some other
reason to generate a certificate.</t>
<t>The third case MAY be returned if the server is unable to
successfully authenticate the user and intends to return some
unauthenticated information to the client.</t>
<t>The hash on a response is computed using SHA-1 HMAC as for the
request.</t>
<t>The data that is hashed is the concatenation of the following
things:</t>
<t><list style="symbols">
<t>4-byte version ID at the beginning of the packet.</t>
<t>DER representation of the error-code exclusive of the tag and
length, if it is present.</t>
<t>OCTET STRING of the certificate, if it is present.</t>
<t>VisibleString representation of the e-text exclusive of the tag
and length, if it is present.</t>
</list>In other words, the hash is computed on the data in the
fields which are present exclusive of the overall ASN.1 wrapping.</t>
<t>The e-text MAY be translated into other character sets for display
purposes, but the hash is computed on the e-text in its VisibleString
representation. If the e-text contains NUL characters, the client MAY
ignore any part of the error message after the first NUL character for
display purposes.</t>
<t>As implied by the above table, if the reply does not contain a
certificate it MUST contain an error message and a non-zero error
code. Conversely, if a certificate is returned then the error code
MUST be zero. The server SHOULD use the DEFAULT encoding for a zero
error-code value by omitting any explicit error-code from the
reply.</t>
<t>The defined error codes are as follows:</t>
<texttable>
<ttcol>error-code</ttcol>
<ttcol>Condition</ttcol>
<ttcol>Example</ttcol>
<c>1</c>
<c>Permanent problem with client request</c>
<c>Incompatible version</c>
<c>2</c>
<c>Solvable problem with client request</c>
<c>Expired Kerberos credentials</c>
<c>3</c>
<c>Temporary problem with client request</c>
<c>Packet loss</c>
<c>4</c>
<c>Permanent problem with the server</c>
<c>Internal misconfiguration</c>
<c>5</c>
<c>Temporary problem with the server</c>
<c>Server overloaded</c>
</texttable>
<t>If a client error is returned, the client SHOULD NOT retry the
request unless some remedial action is first taken, although if
error-code 3 is returned, the client MAY retry with other servers
before giving up.</t>
<t>If a server error is returned, it is RECOMMENDED that the client
retry the request with a different server if one is known.</t>
<t>Since all KCAs serving a Kerberos realm are intended to be
equivalent, in accordance with <xref target="RFC5280"></xref> Section
4.1.2.2, the certificates returned from different KCAs serving the
same Kerberos realm MUST NOT contain duplicate serial numbers.</t>
<t>This protocol and document do not address certificate verification
or path construction. There are no provisions for returning any
additional certificates which might be needed. Any application using a
returned certificate must be configured independently to address these
issues. An incompatible upgrade to this protocol will provide options
to address this issue.</t>
<t>The returned certificate MUST identify the Kerberos client
principal from the ap-req in the original KX509Request in the subject
of the cert, or in a subjectAltName extension. The identification MUST
be unique within the organization's deployed infrastructure. It is
RECOMMENDED that a subjectAltName extension be included of type
id-pkinit-san as described in <xref target="RFC4556"></xref> Section
3.2.2. Note that the id-pkinit-san is simply a standard representation
of a Kerberos principal, and has no other implications with respect to
PKINIT.</t>
<t>Other extensions MAY be added according to local policy.</t>
<t>Appendix C shows an example reply packet.</t>
</section>
</section>
<section title="Protocol Operation">
<t>Absent errors, the protocol consists of a single request, sent via
UDP, and a single reply, also sent via UDP.</t>
<t>There is no special provision for requests or replies which exceed
the allowable size of a UDP packet. Also some implementations have
imposed hard size limits which are smaller than a typical UDP MTU, and
will limit the use of extensions and the supportable key size. Even
without hard limits, if the request or reply exceeds the MTU size of a
UDP packet for the infrastructure in use, then the reliability of the
exchange will decrease significantly.</t>
<t>For “normal” Kerberos ap-req structures, and
“normal” X.509 certificates, this is unlikely unless the
Kerberos service ticket contains large amounts of authorization data.
For this reason, it is RECOMMENDED that service tickets for the KCA be
issued without authorization data. If the KCA performs authorization, it
should do so by other means.</t>
<t>Before constructing the request, the client must know the canonical
name(s) and port(s) of the server(s) to contact. It MAY determine them
by looking up the service's SRV record as described in<xref
target="RFC2782"></xref>. The entry to be used is _kca._udp.<spanx
style="emph">realm</spanx>, where <spanx style="emph">realm</spanx> is
the Kerberos realm, used as part of the DNS name.</t>
<t>The client has to acquire a service ticket in order to construct the
ap-req for the service. Conventionally, the Kerberos service principal
name to use for this service has a first component of "kca_service".
Absent local configuration or other external knowledge of the correct
principal to use, the second and final component is conventionally the
canonical name of the KCA server being contacted, and the realm of the
principal is determined following normal Kerberos domain to realm
mapping conventions, as discussed in <xref target="RFC4120"></xref>
Section 1.3.</t>
<t>When the server receives a request, it MUST verify the following
properties of the request before issuing a certificate:</t>
<t><list style="symbols">
<t>The AP-REQ can be decoded and is not expired.</t>
<t>If the request uses cross-realm authentication, then it satisfies
the requirements of local policy and <xref target="RFC4120"></xref>
Sections 1.2 and 2.7.</t>
<t>The request's hash is valid.</t>
</list>The server SHOULD make other sanity checks, such as a minimum
public key length, to the extent feasible.</t>
<t>The server MAY decline to respond to an erroneous request. If it does
not receive a response a client MAY retry its request, but the client
SHOULD wait at least one second before doing so.</t>
<t>The client MUST verify any hash in the reply, and MUST NOT use any
certificate in a reply whose hash does not verify. The client MAY
display the e-text if the hash is absent or does not verify, but SHOULD
indicate the message is not authenticated.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The original version of kx509 was implemented using Kerberos 4 at the
University of Michigan, and was nicely documented in <xref
target="KX509"></xref>. Many thanks to them for their original work, as
well as the subsequent updates.</t>
<t>While developing this document important corrections and comments
were provided by Jeffrey Altman, and Love Hornquist Astrand. The
following people also provided many helpful comments and corrections:
Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller, Chaskiel
Grundman, and Jim Schaad. Alan Sill provided the references to the
International Grid Trust Federation and its acceptable credential
services. Example network traffic was provided by Doug Engert, Marcus
Watts, Matt Crawford, and Chaskiel Grundman from their deployments, and
was extremely useful for verifying the reality of this
specification.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This service is conventionally run on UDP port 9878. IANA is
requested to register that port in the Service Name and Transport Port
Number Registry as follows:</t>
<t>RFC Editor Note: Change RFC XXXX to the assigned RFC number on
publication and remove this note.</t>
<figure>
<artwork><![CDATA[
Service Name: kca-service
Transport Protocol: UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: The KX509 Kerberized Certificate Issuance
Protocol in Use in 2012
Reference: RFC XXXX
Port Number: 9878
Assignment Notes: Historically, this service has been referred to
as "kca_service", but this service name does
not meet the registry requirements.
]]></artwork>
</figure>
<t>The GSSAPI/Kerberos/SASL service name currently in use for this
protocol is "kca_service". This does not meet the naming requirements
for IANA's GSSAPI/Kerberos/SASL service name registry, so no
registration is requested. The conflict between the conventional service
name and the registry rules is expected to be addressed in a future
version of this protocol. Appropriate registrations will be requested at
that time.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The only encrypted information in the protocol is that used by
Kerberos itself. The considerations for any Kerberized service apply
here.</t>
<t>The public key in the request is sent in the clear, and without any
guarantees that the requester actually possesses the corresponding
private key. Therefore the only appropriate uses of the returned
certificate are those where the identity of the requester is
unimportant, or the subsequent use independently guarantees that the
user possesses the private key. This issue is expected to be addressed
in a future version of this protocol.</t>
<t>For example, if the kx509-issued certificate is used for a digital
signature in a way which does not independently demonstrate
proof-of-possession of the private key, then an eavesdropper could
request their own valid certificate via kx509 and claim to have
originated material signed by the legitimate, original requester. <xref
target="RFC4211"></xref>, Appendix C contains a more detailed discussion
of why proof-of-possession is important.</t>
<t>An example which should be safe is initial client authentication with
TLS <xref target="RFC5246"></xref> connections. If a client certificate
is used then a Certificate Verify message (Section 7.4.8 of that RFC) is
added to the handshake exchange. It includes a signature of the
handshake messages to that point. Those messages depend on data known
only to the client and server ends of the specific connection, so
computing the signature proves possession of the private key. This
application was the original intended use case for kx509.</t>
<t>Some information, such as the public key and certificate, is
transmitted in the clear but (as the name implies) were generally
intended to be publicly available. However their visibility could still
raise privacy concerns. The hash is used to protect their integrity.</t>
<t>The policies for issuing Kerberos tickets and X.509 certificates are
usually expressed very differently. An implementation of this protocol
should not provide a mechanism for bypassing ticket or certificate
policies.</t>
<t>In particular, if the issued certificate can be used with PKINIT,
this authentication loop SHOULD NOT bypass policy limits for either
X.509 certificates or Kerberos tickets.</t>
<t>X.509 certificates are usually issued with considerably longer
validity times than Kerberos tickets. Care should be taken that the
issued certificate is not valid for longer than the intended policy
should allow. Note that <xref target="RFC4556"></xref> Section 3.2.3.1
REQUIRES that the lifetime of an issued ticket not exceed the lifetime
of the predecessor certificate. By analogy it is RECOMMENDED that the
lifetime of an issued certificate not exceed the lifetime of the
predecessor Kerberos ticket unless the implications with respect to
local policy and supporting infrastructure are clearly understood and
allow it.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3447;
&RFC4120;
&RFC5280;
</references>
<references title="Informative References">
&RFC2782;
&RFC4211;
&RFC4556;
&RFC5246;
<reference anchor="X.509">
<front>
<title>Recommendation X.509: The Directory: Public-key and attribute
certificate framework</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="November" year="2008" />
</front>
<format type="TXT" />
</reference>
<reference anchor="KX509"
target="http://www.citi.umich.edu/techreports/reports/citi-tr-01-2.pdf">
<front>
<title>The KX509 Protocol</title>
<author fullname="William Doster" initials="W." surname="Doster">
<organization abbrev="UMICH">University of Michigan</organization>
</author>
<author fullname="Marcus Watts" initials="M." surname="Watts">
<organization abbrev="UMICH">University of Michigan</organization>
</author>
<author fullname="Dan Hyde" initials="D." surname="Hyde">
<organization abbrev="UMICH">University of Michigan</organization>
</author>
<date month="September" year="2001" />
</front>
<format type="TXT" />
</reference>
<reference anchor="IGTF" target="http://www.igtf.net/">
<front>
<title>The International Grid Trust Federation</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="SLCS" target="http://tagpma.org/authn_profiles/slcs">
<front>
<title>Short Lived Credential Services</title>
<author></author>
<date day="3" month="February" year="2009" />
</front>
</reference>
<reference anchor="GRID-prof"
target="http://www.ogf.org/documents/GFD.125.pdf">
<front>
<title>GRID Certificate Profile</title>
<author></author>
<date day="31" month="March" year="2008" />
</front>
</reference>
</references>
<section anchor="app-additional"
title="Certificate Cacheing and Deployment Considerations">
<t>As noted in the Security Considerations section, the functional
lifetime of the acquired X.509 certificate should usually match the
lifetime of its predecessor Kerberos ticket. Therefore, it is likely
that X.509 certificates issued with this protocol should be deleted when
the supporting Kerberos tickets are deleted. That makes the Kerberos
ticket cache a reasonable location to store the certificate (and its
private key).</t>
<t>On the other hand applications, such as web browsers, probably expect
certificates in different stores.</t>
<t>A widely used solution to this dichotomy is to implement a PKCS11
library which supports the KX509-acquired credentials. The credentials
remain stored in the Kerberos credentials cache, but full PKI
functionality is still available via a standard interface for PKI
credentials.</t>
</section>
<section title="Historic Extensions">
<t>This appendix documents extensions to the kx509 protocol which are
either no longer in use, or are expected to be dropped.</t>
<t>A subjectAltName othername extension of type kcaAuthRealm (OID value
1.3.6.1.4.1.250.42.1) is frequently used to include the client's realm
as an ASN.1 octet string.</t>
<t>The Microsoft-defined userPrincipalName has frequently been used for
the same purpose as the id-pkinit-san.</t>
<t>The historic implementations of this protocol included provisions for
DSA keys in place of RSA. DSA does not appear to be in use. A future
version of this protocol will use a standard certificate request
structure which will provide algorithm agility.</t>
<t>The historic implementations of this protocol allowed an optional
client-version field (at the end of the request) of type VisibleString.
If present, the KCA copied it into the issued certificate as an
extension with the OID 1.3.6.1.4.1.250.42.2. This feature does not
appear to be in use.</t>
</section>
<section title="Example Exchange">
<t>The request and reply are from the same exchange. The Ethernet, IP,
and UDP headers, and the 4-byte version string at the beginning of the
request and reply packets are all omitted. Only the ASN.1-encoded
portions are shown.</t>
<t></t>
<figure title="Request Packet ASN.1 Decode">
<artwork><![CDATA[ 0:d=0 hl=4 l= 678 cons: SEQUENCE
4:d=1 hl=4 l= 509 prim: OCTET STRING
[HEX DUMP]:6E8201F9308201F5A003... (ap-req)
517:d=1 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash)
539:d=1 hl=3 l= 140 prim: OCTET STRING
[HEX DUMP]:30818902818100B70F46... (pk-key)]]></artwork>
</figure>
<t></t>
<figure title="Reply Packet ASN.1 Decode">
<artwork><![CDATA[ 0:d=0 hl=4 l= 870 cons: SEQUENCE
4:d=1 hl=2 l= 22 cons: cont [ 1 ]
6:d=2 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:F3A844834C26D843B6FD... (hash)
28:d=1 hl=4 l= 842 cons: cont [ 2 ]
32:d=2 hl=4 l= 838 prim: OCTET STRING
[HEX DUMP]:308203423082022AA003... (certificate)]]></artwork>
</figure>
</section>
<section title="Change History">
<t>RFC Editor Note: Delete this appendix before final publication.</t>
<t>Changes from Draft -04 to Draft -05:</t>
<t><list style="numbers">
<t>The title, a word in the abstract, and the reference to the IETF
Kerberos working group were changed to make it clearer that this is
not a standards-track document.</t>
<t>Added Appendix C, to clarify the ASN.1 encoding, and specify the
byte string that begins the ASN.1 OCTET STRING encoding of
certificates.</t>
<t>Removed the request for IANA registration of the
GSSAPI/Kerberos/SASL name, since the service name registry does not
allow the form of name actually in use. Add an IANA registration
request for the conventional port number.</t>
</list>Changes from Draft -03 to Draft -04:</t>
<t><list style="numbers">
<t>The list of possible issues was deleted. Either appropriate
comments have been added to the text, or the issue is mentioned as
something to be addressed in an incompatible future version of this
protocol.</t>
<t>Clarified the hash computations in sections 2.1 and 2.2.</t>
<t>Clarified the procedure for determining the Kerberos principal of
the KCA in section 3.</t>
<t>Clarified the discussion of the "proof-of-possession" issue in
the Security Considerations with appropriate references.</t>
</list></t>
<t>Changes from Draft -02 to Draft -03:</t>
<t><list style="numbers">
<t>The abstract was expanded.</t>
<t>Additional information was provided on traditional UDP size
restrictions and their effect on reliability and key sizes in
section 3.</t>
<t>The updates to the security considerations for digital signature
usage were incomplete, and have been rewritten.</t>
<t>Information on an optional client version feature (which does not
appear to be actually in use) was added to the request ASN.1, and
Appendix B, and the title of the appendix changed.</t>
<t>As before some minor changes to wording were made for clarity,
but are not believed to have changed the meaning.</t>
</list>Changes from Draft -01 to Draft -02:</t>
<t><list style="numbers">
<t>The retry behavior was made slightly less specific.</t>
<t>The traditionally used SAN extensions were moved to a new
appendix, leaving only the id-pkinit-san as the RECOMMENDED SAN.</t>
<t>The absolute prohibition against digital signatures in the
Security Considerations section was relaxed since there are
legitimate situations where a signature based on the KX509
certificate is still useful. (E.g. integrity protection where the
actual signing identity is not important.)</t>
<t>Reference to TAGPMA in the abstract was replaced with a reference
to its parent, the International Grid Trust Federation, and more
detailed informative references were expanded in the
Introduction.</t>
<t>Assorted other wording changes were made for clarity, but are not
believed to have changed the meaning.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:56:42 |