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 |