Subject: [Ietf-krb-wg] A way forward for starttls?

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Oct 2009 10:51:34 -0400

So, I'm brainstorming here how to make startls go forward faster.

If we have a strong consensus that is is important to stop delaying
starttls then perhaps there is a way forward.

As I understand it, Jeff and nico would like to change away from a new
SAN to a new EKU.  They don't believe the current approach is so
technically flawed that it can't be published--they just believe that
EKU is better and would like an opportunity to build a consensus
around that.
(I agree with them that EKU is better, although I think I feel less strongly than Jeff.)

The WG could decide to publish the document as-is and for Jeff to
explicitly call this issue out in his writeup.  We could propose that
if the issue still exists after AD review, that Tim include it as an
area we'd like to get input on in IETF last call.

Jeff, Nico and I would of course be free to make IETF last call
comments if we wish, and Tim would be free to judge consensus.

My assumption here is that there seems to be a lot of apathy in the WG
about this issue--possibly about every issue--and that we're not
really building an informed consensus here.  My goal is to provide a
process where all sides can be heard and where someone other than Jeff
can make the call if needed.

If people would rather just resolve this within krb-wg that's OK too.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Oct 2009 12:31:17 -0400

> (I agree with them that EKU is better, although I think I feel less

I dislike defining a new SAN when we already have a mechanism defined in 
PKINIT for naming the KDC for a realm.  However, I don't feel strongly 
about it.  So in that respect, I think your analysis is correct.  But see 
below.

> area we'd like to get input on in IETF last call.

I have no objections to that approach, and in fact, if the WG chooses to 
proceed with the current document, this is an issue I'll raise in my 
writeup in any event.

Note that I believe if we're going to define an EKU, we must do it now; 
that is, before this document is published as an RFC.  Once the document is 
published, defining an EKU would be a backward-incompatible change to the 
protocol, because certificates carrying the new EKU would be rejected by 
clients which do not recognize it as belonging to krb5starttls (or at 
least, by clients which actually conform to RFC5280).

Note also that I have just started a WGLC on this document, which will run 
for two weeks and covers the -07 version but leaves the EKU/SAN issue open. 
That gives us two weeks in which to resolve this issue before the document 
is sent along to Tim.

-- Jeff