Oops, I didn't actually implement the spec when implementing anonymous pkinit

Sam Hartman hartmans-ietf at MIT.EDU
Mon Feb 14 21:45:48 EST 2011



Anonymous is in auth48.
Reading it one last time, I realized that section 4.1.1 doesn't say what
I thought it did when implementing anonymous pkinit for MIT Kerberos.

It says that an implementation should generate SignedData with no
signerInfos.  I thought (entirely out of my own delusions apparently)
that rather than generating a SignedData, the implementation should use
the Data content type.


Both would be legal things to do.

I think it's worth discussing with the WG what to do at this point.

First, if there's someone who is actually interoperable with the current
spec, I think it's fairly clear that we should stick with the current
spec.  (If you have such an implementation and don't feel comfortable
saying so on the list, please write to one of the authors of anonymous,
one of the WG chairs, or our AD).

I'm aware of two implementations MIT, which is not interoperable in the
way I described above.  Heimdal, which at least the last time I checked
didn't implement section 7 of the spec.  I don't know if anyone else has
shipped an implementation.

I don't think there is really any technical reason to prefer either what
the spec does or what MIT shipped. I think both are legal, and I can
make arguments that both are superior (which generally means neither
is.)

Obviously, with my implementor hat on, I'd prefer that we changed the
spec to do what our implementation does.

Assuming no one has shipped something interoperable with the spec, I
think it would be reasonable to do that, but  there are a few reasons we
might not want to:

1) It would favor MIT Kerberos. I can understand why the Heimdal folks
could be frustrated by this: at the time they implemented anonymous
PKINIT section 7 didn't exist.

2) There might be some implementation out there tracking the drafts but
not participating in the WG.

I'll admit that I find reason 2 kind of uncompelling.
I would find it quite compelling if someone stepped forward in response
to this message and said they had an implementation they believed met
the spec. It's the fear of breaking non-participants prior to RFC
publication I find problematic.

3) If we do not change the spec, are we willing to make things easier
for MIT in terms of transition? For example we could have the RFC
require advertizing explicit support for anonymous pkinit.

Anyway, I'm quite embarrassed about this and would appreciate any
comments people have.



More information about the krbdev mailing list