Skip to main content

IETF conflict review for draft-turner-additional-methods-4kis
conflict-review-turner-additional-methods-4kis-00

Document history

Date Rev. By Action
2013-10-28
00 Amy Vezza
The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-turner-additional-methods-4kis@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for …
The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-turner-additional-methods-4kis@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-turner-additional-methods-4kis-11

The IESG has completed a review of
draft-turner-additional-methods-4kis-11 consistent with RFC5742.


The IESG has no problem with the publication of 'Additional Methods for
Generating Subject Key Identifiers'
as an Informational RFC.


The IESG has concluded that there is no conflict between this document
and IETF work.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-turner-additional-methods-4kis/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary



2013-10-28
00 Amy Vezza IESG has approved the conflict review response
2013-10-28
00 Amy Vezza Closed "Approve" ballot
2013-10-28
00 Amy Vezza State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent
2013-10-24
00 Cindy Morgan State changed to Approved No Problem - announcement to be sent from IESG Evaluation
2013-10-24
00 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-10-24
00 Richard Barnes
[Ballot comment]
I've cleared my DISCUSS, but it still makes me kind of sad that there's not a way to distinguish between these classes of …
[Ballot comment]
I've cleared my DISCUSS, but it still makes me kind of sad that there's not a way to distinguish between these classes of key identifiers just by looking at them.
2013-10-24
00 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2013-10-24
00 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2013-10-24
00 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-23
00 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-10-23
00 Richard Barnes
[Ballot discuss]
Maybe I'm missing something here, but doesn't this create interop issues for PKIX?  The SKI/AKI fields don't have any sort of indicator for …
[Ballot discuss]
Maybe I'm missing something here, but doesn't this create interop issues for PKIX?  The SKI/AKI fields don't have any sort of indicator for how the SKI/AKI was constructed, so a verifier just has to know from context somehow which algorithm is being used.  This hasn't been an issue in the past because there was essentially only one algorithm.  It seems like expanding the set raises at least two concerns:

For new verifiers: Are verifiers using SKI/AKI to match (e.g., for path construction) just supposed to compute candidate IDs for a key using all possible algorithms and see if anything matches?  Are there risks arising from collision?

For old verifiers: Suppose a cert uses an AKI with generated one of these new algorithms, and an old verifier library sees it.  Then it might not be able to locate the proper parent certificate.  One could in principle include two AKIs computed with different algorithms, but that seems like it would add combinatorial complexity to the search, and new error cases (what if two different certs match the different AKIs?).

I suspect that what I'm missing in the above is that in practice, verifiers aren't computing AKIs/SKIs themselves, they're just comparing a pre-computed SKI in one cert to an AKI in another (so it's just the CA's job to be consistent).  But it seems like there could still be impacts on other protocols, say ones that might want to identify a cert by subject key ID without having to require that certificates contain that extension.
2013-10-23
00 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2013-10-23
00 Sean Turner [Ballot Position Update] New position, Recuse, has been recorded for Sean Turner
2013-10-23
00 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-10-23
00 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-10-23
00 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-23
00 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-22
00 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-10-22
00 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-10-22
00 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-10-22
00 Barry Leiba New version available: conflict-review-turner-additional-methods-4kis-00.txt
2013-10-22
00 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2013-10-22
00 Barry Leiba Created "Approve" ballot
2013-10-22
00 Barry Leiba State changed to IESG Evaluation from Needs Shepherd
2013-10-22
00 Barry Leiba Shepherding AD changed to Barry Leiba
2013-10-22
00 Amy Vezza
The draft draft-turner-additional-methods-4kis-11.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The …
The draft draft-turner-additional-methods-4kis-11.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its title is:
Additional Methods for Generating Subject Key Identifiers

Its abstract says:
"This document specifies additional example methods for generating Key
Identifier values for use in the AKI (Authority Key Identifier) and
SKI (Subject Key Identifier).":

It was reviewed for me by Stephen Farrell and Jim Schaad;
Jim had quite a few issues with it, the authors have worked with
him to address the issues raised.
2013-10-22
00 Amy Vezza Placed on agenda for telechat - 2013-10-24
2013-10-22
00 Amy Vezza IETF conflict review requested