Skip to main content

Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-08

Revision differences

Document history

Date Rev. By Action
2019-07-16
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-07-09
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-06-21
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-06-05
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-06-05
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-06-04
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-05-28
08 (System) RFC Editor state changed to EDIT
2019-05-28
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-05-28
08 (System) Announcement was received by RFC Editor
2019-05-27
08 (System) IANA Action state changed to In Progress
2019-05-27
08 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2019-05-27
08 Cindy Morgan IESG has approved the document
2019-05-27
08 Cindy Morgan Closed "Approve" ballot
2019-05-27
08 Cindy Morgan Ballot approval text was generated
2019-04-20
08 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-08.txt
2019-04-20
08 (System) New version approved
2019-04-20
08 (System) Request for posting confirmation emailed to previous authors: Greg Hudson , Larry Zhu , Margaret Cullen , Love Astrand
2019-04-20
08 Greg Hudson Uploaded new revision
2019-04-18
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-04-18
07 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-07.txt
2019-04-18
07 (System) New version approved
2019-04-18
07 (System) Request for posting confirmation emailed to previous authors: Greg Hudson , Larry Zhu , Margaret Cullen , Love Astrand
2019-04-18
07 Greg Hudson Uploaded new revision
2019-03-14
06 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation - Defer
2019-03-13
06 Eric Rescorla
[Ballot comment]
IMPORTANT
I think this document would benefit greatly from describing the
downgrade properties of each of the axes on which algorithms
can be …
[Ballot comment]
IMPORTANT
I think this document would benefit greatly from describing the
downgrade properties of each of the axes on which algorithms
can be negotiated against various forms of compromise in the
digest function.

The relevant case is one in which the client and KDC both support
one weak and one strong algorithm. Can the attacker either

(1) force them to complete a handshake with a weak algorithm
or
(2) convince one side that the other side supports a weak algorithm
and then interpose itself as that side.

Specifically it would be useful to know which attacks are possible
with a collision attack versus a preimage attack (though this
can sometimes be hard to know).


Here is one case of a potential real downgrade attack (though not a
very powerful one).

The client sends a KRB-REQ signed with algorithm A, the attacker
forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
weaker algorithm. This causes the client to retry with that weaker
algorithm. Is this attack detectable? It's not clear to me how (though
it maybe could be if the message were folded into the transcript).

OTOH, I don't think that the equivalent attack on the cert signer
algorithms is necessarily very useful because presumably the certs are
public already. OTOH, it might force the client into using some weaker
key.


I'm having a little trouble following the point in S 3. Is the idea
that the paChecksum is always SHA-1 and you don't add a way to negotiate
it, so you are instead folding the information into the KDF? If so,
I think we need to work through the chain of logic here. As I understand
it, the paRequest is included in the AuthPack, which is signed. So
presumably the idea is that the AuthPack is signed with SHA-256
but because paChecksum is SHA-1, the binding is weak, right? But
can you safely send a SHA-256 signature to a KDC which you have
never talked to before? Can't you just get downgraded by the attack
I describe above? Can you help unpack this for me?


MINOR
I wish you were using HKDF, but I don't think this is a dealbreaker.
2019-03-13
06 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2019-03-13
06 Christer Holmberg Request for Telechat review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list.
2019-03-07
06 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2019-03-07
06 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2019-03-07
06 Eric Rescorla Telechat date has been changed to 2019-03-14 from 2019-03-07
2019-03-07
06 Eric Rescorla IESG state changed to IESG Evaluation - Defer from Waiting for Writeup
2019-03-07
06 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-03-06
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-03-06
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2019-03-06
06 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-03-06
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-03-06
06 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-06.txt
2019-03-06
06 (System) New version approved
2019-03-06
06 (System) Request for posting confirmation emailed to previous authors: Greg Hudson , kitten-chairs@ietf.org, Larry Zhu , Margaret Cullen , Love Astrand
2019-03-06
06 Greg Hudson Uploaded new revision
2019-03-06
05 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-03-06
05 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-03-06
05 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-03-06
05 Adam Roach
[Ballot comment]
Thanks to everyone who has worked on this over the past several years, and
thanks to the authors for a timely response to …
[Ballot comment]
Thanks to everyone who has worked on this over the past several years, and
thanks to the authors for a timely response to my earlier discuss concerns.
I am leaving the original text of my discuss below for historical reasons,
as it pertains to a larger problem that would ideally be addressed by future
work.

---------------------------------------------------------------------------

I can see in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26
that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a
reservation that appears to have been copied out of RFC 1700). I also see that
RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath
it. Try as I might, I can't find any plausibly authoritative registry that
tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1,
1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3.

This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6"
is free? How will future specifications know that "6" is no longer available?

This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2,
1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms.
Assuming this list continues to be added to, how will future specifications
avoid collisions?

I have a similar question about 1.3.6.1.5.2.4.5.1.

I think my confusion stems from the fact that I was under the impression that
everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of
RFC 1155.

To be clear: if I understand the situation correctly, I recognize that there
may be a bigger problem here that is beyond the remit of this document to
solve; however, I think it would be reasonable to not make the existing problem
worse. In particular -- and again, I may simply be confused here -- I would
expect this document to at least ask IANA to create a table at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps
track of the children of 1.3.6.1.5.2.3.6.

---------------------------------------------------------------------------

§4:

>  When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
>  as described in Section 3.2.2 of [RFC4556], implementations
>  conforming to this specification can OPTIONALLY send back a list of

The term "OPTIONALLY" is not defined in RFC 2119, although I believe the
intention of this passage is to make a normative statement consistent with the
RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an
auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to
use "OPTIONAL" or "MAY".

---------------------------------------------------------------------------

§5:

>  When the client's X.509 certificate is rejected and the
>  KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
>  described in Section 3.2.2 of [RFC4556], implementations conforming
>  to this specification can OPTIONALLY send a list of digest algorithms

Same comment as above.
2019-03-06
05 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2019-03-06
05 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-03-06
05 Adam Roach
[Ballot discuss]
Thanks to everyone who has worked on this over the past several years. I have
one "discuss DISCUSS" that I suspect may be …
[Ballot discuss]
Thanks to everyone who has worked on this over the past several years. I have
one "discuss DISCUSS" that I suspect may be a misunderstanding on my part
about how Kerberos deals with OIDs in general. If so, please bear with my
ignorance.  I just want to make sure something important isn't being
overlooked.

I can see in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26
that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a
reservation that appears to have been copied out of RFC 1700). I also see that
RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath
it. Try as I might, I can't find any plausibly authoritative registry that
tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1,
1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3.

This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6"
is free? How will future specifications know that "6" is no longer available?

This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2,
1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms.
Assuming this list continues to be added to, how will future specifications
avoid collisions?

I have a similar question about 1.3.6.1.5.2.4.5.1.

I think my confusion stems from the fact that I was under the impression that
everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of
RFC 1155.

To be clear: if I understand the situation correctly, I recognize that there
may be a bigger problem here that is beyond the remit of this document to
solve; however, I think it would be reasonable to not make the existing problem
worse. In particular -- and again, I may simply be confused here -- I would
expect this document to at least ask IANA to create a table at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps
track of the children of 1.3.6.1.5.2.3.6.
2019-03-06
05 Adam Roach
[Ballot comment]
§4:

>  When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
>  as described in Section 3.2.2 of [RFC4556], implementations
>  conforming to this …
[Ballot comment]
§4:

>  When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
>  as described in Section 3.2.2 of [RFC4556], implementations
>  conforming to this specification can OPTIONALLY send back a list of

The term "OPTIONALLY" is not defined in RFC 2119, although I believe the
intention of this passage is to make a normative statement consistent with the
RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an
auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to
use "OPTIONAL" or "MAY".

---------------------------------------------------------------------------

§5:

>  When the client's X.509 certificate is rejected and the
>  KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
>  described in Section 3.2.2 of [RFC4556], implementations conforming
>  to this specification can OPTIONALLY send a list of digest algorithms

Same comment as above.
2019-03-06
05 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2019-03-05
05 Ben Campbell
[Ballot comment]
Hi, thanks for this work. I only have a couple of editorial comments:

- Abstract and Introduction: Please expand PKINIT on first mention …
[Ballot comment]
Hi, thanks for this work. I only have a couple of editorial comments:

- Abstract and Introduction: Please expand PKINIT on first mention in both the abstract and body.

§4: "... implementations conforming to this specification can OPTIONALLY send back a list of supported CMS types ..."

OPTIONALLY is not a defined keywords. I suggest changing "... can OPTIONALLY ..." to "MAY"
Plural disagreement between "implementations" and "a list".
2019-03-05
05 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2019-03-05
05 Warren Kumari
[Ballot comment]
I reviewed this, but much of it is outside my area of expertise, so trusting the AD.
I did not validate any of …
[Ballot comment]
I reviewed this, but much of it is outside my area of expertise, so trusting the AD.
I did not validate any of the test vectors, etc.
2019-03-05
05 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-03-04
05 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-03-01
05 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Christer Holmberg. Sent review to list.
2019-02-28
05 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-02-26
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-02-26
05 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-05.txt
2019-02-26
05 (System) New version approved
2019-02-26
05 (System) Request for posting confirmation emailed to previous authors: Greg Hudson , Larry Zhu , Margaret Cullen , Love Astrand
2019-02-26
05 Greg Hudson Uploaded new revision
2019-02-17
04 Takeshi Takahashi Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi. Sent review to list.
2019-02-17
04 Cindy Morgan Placed on agenda for telechat - 2019-03-07
2019-02-17
04 Scott Bradner Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. Sent review to list.
2019-02-17
04 Benjamin Kaduk Ballot has been issued
2019-02-17
04 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2019-02-17
04 Benjamin Kaduk Created "Approve" ballot
2019-02-17
04 Benjamin Kaduk Ballot writeup was changed
2019-02-17
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-02-15
04 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-02-15
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-kitten-pkinit-alg-agility-04. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-kitten-pkinit-alg-agility-04. If any part of this review is inaccurate, please let us know.

In the Pre-authentication and Typed Data registry on the Kerberos Parameters registry page located at:

https://www.iana.org/assignments/kerberos-parameters

the two existing registrations

Type: 111
Value: TD-CMS-DIGEST-ALGORITHMS

Type: 112
Value: TD-CERT-DIGEST-ALGORITHMS

will have their references changed to [ RFC-to-be ].

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-07
04 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2019-02-07
04 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2019-02-07
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2019-02-07
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2019-02-05
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-02-05
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-02-03
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-02-03
04 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-02-17):

From: The IESG
To: IETF-Announce
CC: kitten-chairs@ietf.org, Robbie Harwood , rharwood@redhat.com, kitten@ietf.org, …
The following Last Call announcement was sent out (ends 2019-02-17):

From: The IESG
To: IETF-Announce
CC: kitten-chairs@ietf.org, Robbie Harwood , rharwood@redhat.com, kitten@ietf.org, kaduk@mit.edu, draft-ietf-kitten-pkinit-alg-agility@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PKINIT Algorithm Agility) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document: - 'PKINIT
Algorithm Agility'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document updates PKINIT, as defined in RFC 4556, to remove
  protocol structures tied to specific cryptographic algorithms.  The
  PKINIT key derivation function is made negotiable, and the digest
  algorithms for signing the pre-authentication data and the client's
  X.509 certificates are made discoverable.

  These changes provide preemptive protection against vulnerabilities
  discovered in the future against any specific cryptographic
  algorithm, and allow incremental deployment of newer algorithms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-02-03
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-02-03
04 Benjamin Kaduk Last call was requested
2019-02-03
04 Benjamin Kaduk Last call announcement was generated
2019-02-03
04 Benjamin Kaduk Ballot approval text was generated
2019-02-03
04 Benjamin Kaduk Ballot writeup was generated
2019-02-03
04 Benjamin Kaduk IESG state changed to Last Call Requested from Publication Requested
2019-02-03
04 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-04.txt
2019-02-03
04 (System) New version approved
2019-02-03
04 (System) Request for posting confirmation emailed to previous authors: Greg Hudson , Larry Zhu , Margaret Cullen , Love Astrand
2019-02-03
04 Greg Hudson Uploaded new revision
2018-11-05
03 Greg Hudson New version available: draft-ietf-kitten-pkinit-alg-agility-03.txt
2018-11-05
03 (System) New version approved
2018-11-05
03 (System) Request for posting confirmation emailed to previous authors: kitten-chairs@ietf.org, Benjamin Kaduk , Larry Zhu , Love Astrand
2018-11-05
03 Greg Hudson Uploaded new revision
2018-11-01
02 Benjamin Kaduk Shepherding AD changed to Benjamin Kaduk
2018-09-01
02 Benjamin Kaduk Shepherding AD changed to Eric Rescorla
2018-08-27
02 Robbie Harwood
1. Summary

    This document specifies an updated Public Key Cryptography for Initial
    Authentication in Kerberos (PKINIT, rfc4556) which is not …
1. Summary

    This document specifies an updated Public Key Cryptography for Initial
    Authentication in Kerberos (PKINIT, rfc4556) which is not dependent on
    SHA-1.  In particular, it describes negotiation for Key Derivation
    Functions, and includes test vectors for these schemes.

    This is a Standards Track document since its core goal is to update
    PKINIT, which is a standard part of Kerberos implementations.
    Accordingly, it updates rfc4556 (PKINIT), which is Standards Track.

    Robbie Harwood is the document shepherd.  Benjamin Kaduk is the
    responsible Area Director.

2. Review and Consensus

    There is consensus for this document, which improves Kerberos's ability to
    handle compromise of cryptographic algorithms.  Having options other than
    SHA-1 for PKINIT is noncontroversial within the working groups; this
    document defines SHA-256, SHA-512, and SHA-384 as additional
    possibilities, and assigns additional Object Identifiers for them.

    This document has been around for quite a long time, originally part of
    krb-wg before being taken up by kitten in the re-charter.  Implementations
    have existed in both MIT krb5 and Heimdal since 2011 and 2008,
    respectively.  Most shaping review happened under krb-wg, but those
    contributors are also participants in kitten.

    During drafting, there were concerns that using an unknown well-known
    principal name together with PKINIT agility would cause an error code
    overlap, despite there being no known shipped implementations.
    Conservatively, the error code was reassigned.  We also spent time on
    thinking through our ASN.1, and making sure the appendix module was
    all-inclusive.

    This document received review and/or implementation from a significant
    number of working group contributors.  Two implementations (which can
    reproduce test vectors) have proved stable and manageable in production
    environments, and no unaddressed issues have been reported from any others
    that might exist.  In an ideal world it would have been published much
    sooner, but has been repeatedly deprioritized in favor of other work.

3. Intellectual property

    There are no intellectual property disclosures against this document, and
    all three authors (and editor) have confirmed compliance with BCPs 78
    and 79.  Since this document contains contributions from before 2008, it
    may not be modified outside the IETF Standards Process.

4. Other information

    The IANA considerations are simple: rfc6113 previously created a registry
    with entries reserved for this document (hence the "missing reference"
    from idnits).  This document requests said entries be updated to point to
    this document.

    rfc6234 is cited normatively, which also flags idnits.  However, it is
    already present in the Downref Registry.
2018-08-27
02 Robbie Harwood Responsible AD changed to Benjamin Kaduk
2018-08-27
02 Robbie Harwood IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2018-08-27
02 Robbie Harwood IESG state changed to Publication Requested
2018-08-27
02 Robbie Harwood IESG process started in state Publication Requested
2018-08-27
02 Robbie Harwood Changed consensus to Yes from Unknown
2018-08-27
02 Robbie Harwood Intended Status changed to Proposed Standard from None
2018-08-27
02 Robbie Harwood Changed document writeup
2018-08-27
02 Robbie Harwood Notification list changed to Robbie Harwood <rharwood@redhat.com>
2018-08-27
02 Robbie Harwood Document shepherd changed to Robbie Harwood
2018-08-26
02 Benjamin Kaduk New version available: draft-ietf-kitten-pkinit-alg-agility-02.txt
2018-08-26
02 (System) New version approved
2018-08-26
02 (System) Request for posting confirmation emailed to previous authors: Benjamin Kaduk , Larry Zhu , Margaret Cullen , Love Astrand
2018-08-26
02 Benjamin Kaduk Uploaded new revision
2017-10-01
01 (System) Document has expired
2017-03-30
01 Benjamin Kaduk New version available: draft-ietf-kitten-pkinit-alg-agility-01.txt
2017-03-30
01 (System) New version approved
2017-03-30
01 (System) Request for posting confirmation emailed to previous authors: kitten-chairs@ietf.org, Love Astrand , William Mills , Margaret Wasserman , Larry Zhu
2017-03-30
01 Benjamin Kaduk Uploaded new revision
2015-10-04
00 Benjamin Kaduk We believe all outstanding issues are resolved, but need action from the chairs to verify.
2015-10-04
00 Benjamin Kaduk IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2015-09-30
00 Benjamin Kaduk IETF WG state changed to In WG Last Call from WG Document
2015-04-02
00 Benjamin Kaduk krb-wg is closed, so we are picking this document up in kitten.
2015-04-02
00 Benjamin Kaduk This document now replaces draft-ietf-krb-wg-pkinit-alg-agility instead of None
2015-04-02
00 William Mills New version available: draft-ietf-kitten-pkinit-alg-agility-00.txt