Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 May 2010 15:46:59 -0000

On 5/18/2010 11:09 AM, Jeffrey Hutzelman wrote:
>
>> Not only do I believe it is out of scope but that it should actively be
>> avoided.  The Kerberos v5 credential cache does not have the appropriate
>> infrastructure to manage non-Kerberos tickets.
>
> You appear to be saying "it won't work", but that is demonstrably
> untrue. If you think we should actively discourage this feature, you
> need a stronger argument than that.
>
> -- Jeff

It works with a particular implementation of a FILE: credential cache.  
That is all.  I have over the years proposed several modifications to
the MIT credential cache apis to permit the storage of object types
other than Kerberos v4 and Kerberos v5 tickets.  There was always very
strong objection to the notion that the credential cache API should
become a mechanism for storing PGP keys, Cert/key pairs, and other
credential forms. 

While it is entirely possible to lie to the credential cache API and
tell it that you are storing a Kerberos v5 ticket when you aren't, doing
so has a negative impact on the usability of klist and other tools. 

Besides which, where a cert is stored has nothing to do with the
protocol and as such (in my opinion) should not be a part of an
Internet-Draft.

Jeffrey Altman

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 May 2010 13:56:16 -0000

I'm replying to the initial message, having read the whole thread (at least
the part that has been sent to the PKIX list).

There are many things with this draft and the discussion which confuses me
and I would be happy if you could help un-confuse me.

Firstly I don't see the relevance of the discussion at large in relation to
the draft. A lot of things discussed refers to use of name forms, trust
policies and the potential use of a KCA certificates for PKINIT. Even though
that is very interesting, I don't see anything in the draft that states that
a KCA issues certificates for any particular purpose. Strictly reading the
draft I see a CA that calls itself KCA only based on the fact that it can
accept this form of request supported by Kerberos authentication.

If that is true, then the issued certificate could be any type of
certificate used for any purpose. The Kerberos ticket is then reduced to a
means of authentication and optionally a source of subject name information
(Kerberos principal name).

However, I see nothing that prevents the KCA to map the authenticated
Kerberos ticket to any other identity data based on a local identity
database trusted by the KCA.

If so, then I don't understand why you would limit the lifetime of the
certificate to the lifetime of the ticket. Compare if I use an ID-card to
authenticate my identity to the passport issuance service, that does not
mean that my passport will be limited to the validity of my id-card. The
only thing is that my ID-card is valid when it is used.

I don't understand why we need to invent a new certificate request format.
PKIX have already gone through the pain to develop certificate request
formats that are widely deployed. An obvious flaw in the current draft is
the lack of proof-of-possession of the corresponding private key, which
would be avoided if an existing request format was used.

Maybe small issue. The protocol has no wait message. It only delivers either
a certificate or an error. What if the request is pending for some reason?

Finally I don't understand why you need to limit the protocol to UDP, or
even why you need to specify the use of UDP in the first place.

/Stefan

On 10-05-14 3:32 AM, "Henry B. Hotz" <[email-masked]> wrote:

> I have just submitted the KX509 draft which I discussed in the Kerberos
> working group in Anaheim.  It's available at
> https://datatracker.ietf.org/doc/draft-hotz-kx509/.
> 
> The immediate question is where (if anywhere) should work on this draft take
> place.  Since it's function is to translate Kerberos tickets into X.509
> certificates, it might equally be handled by the krb-wg, or pkix.  Since I
> understand it's outside the precise charter of both, perhaps saag should step
> in.
> 
> What interest is there in handling work on this?
> 
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [email-masked], or [email-masked]
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix