Subject: [saag] Draft KX509 Proposal

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 13 May 2010 18:32:13 -0700

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]

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 14 May 2010 10:43:36 -0500

> What interest is there in handling work on this?

A related question. The draft appears to be documenting the existing
protocol. If so then it should state so. Should Appendix B be split
up into know problems in the current implementations, and ideas for
Protocol version 3?

Known issues:

   Use of UDP can be a problem if the Kerberos ticket is large,
   for example if it contains a Microsoft PAC. A returned certificate
   could also be large.

   What are the cross realm issues?

   Multiple (replicated) KCA servers should create at lease different
   serial numbers.

Ideas for version 3:

   Use the KRB_SAFE, KRB_PRIV and KRB_ERROR. This would address
   Appendix B items: 1, 2, 3.

   Or should it use gssapi to make this more general.

   Could a certificate chain be returned?

   Allow TCP.

Other comments:
  Section 2.2 uses e-text and error-message. I assume they are the same.

  Appendix A says: "a widely used solution to this problem is to
  implement the KX509 client within a PKCS#11 library." I have seen
  a PKCS#11 library that access the kx509 certificate and key
  previously obtained by running a kx509 command, but not obtained from
  within the PKCS#11 lib. Is there such an implementation?

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
> 

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 14 May 2010 16:55:24 -0700

On May 14, 2010, at 8:43 AM, Douglas E. Engert wrote:

> protocol. If so then it should state so.

See other email.  This draft should become informational and document the existing protocol.  Need a new one.

> Should Appendix B be split

Forgot to include a recommendation I got that the PAC should be prohibited in tickets for this service for just that reason.

>   What are the cross realm issues?

That's a really good question.  Note that the original identity should be recorded in an id-pkinit-san attribute (per comments in email, not the current draft).  I think that's necessary, but not sufficient for cross realm issues.  

Probably part of the right solution is to say something about how subject names should be constructed, based on the principal name and realm.  I currently say nothing about that, and it now seems like an oversight.  

Then, of course, there are all the capath validation questions.  Do you have any recommendations?

>   Multiple (replicated) KCA servers should create at lease different

That's probably implied by the other PKIX standards already, but it wouldn't hurt to mention it.  (As an implementation point, I don't think the Heimdal KCA will do that.)

>   Appendix B items: 1, 2, 3.

Already have related comments.  Sounds reasonable.

>   Or should it use gssapi to make this more general.

Offhand, no, because that no longer seems like a simple update.  OTOH, if there is interest and a real use case, perhaps so.

>   Could a certificate chain be returned?

I'm neutral.  Seems unnecessary, but easy to do (at least over TCP).

>   Allow TCP.

I'm actually happy with UDP, but I seem to have more confidence in my ability to get firewalls to behave than most.  Sure, why not?

Would you then argue for allowing the Microsoft PAC back in as a consequence?

>  Section 2.2 uses e-text and error-message. I assume they are the same.

Yes.

>  within the PKCS#11 lib. Is there such an implementation?

You're quite right.  The version of the UMICH code I have has a build option to make the command into a library, but the pkcs11 library does not call it.  IMO what I said is how it should work, but I don't believe that's what's actually in the wild.

Should this standard say anything about how the cert should be cached in a Kerberos credential cache?  I see advantages to having UMICH/MIT code share an already-feched certificate with Heimdal code, but I had considered that to be out of scope for this work.  I think I still do.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 May 2010 22:03:16 -0400

--On Friday, May 14, 2010 04:55:24 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> That's a really good question.  Note that the original identity should be
> recorded in an id-pkinit-san attribute (per comments in email, not the
> current draft).  I think that's necessary, but not sufficient for cross
> realm issues.

It's certainly necessary, since otherwise you don't know what to what 
principal the certificate belongs.

> Probably part of the right solution is to say something about how subject
> names should be constructed, based on the principal name and realm.  I
> currently say nothing about that, and it now seems like an oversight.

You may want to say something about how to construct a subject DN.  In 
practice, it might be better to leave it unspecified.  The answer is likely 
to be heavily influenced by local policy and might be based in part on the 
result of a directory lookup done by the KCA.

> have any recommendations?

IMHO the only sane thing to do is for the KCA to apply whatever cross-realm 
path validation policy it has and then either issue the certificate or not 
based on whether it believes the request is sufficiently well 
authenticated.  Any attempt to push Kerberos cross-realm path information 
into the certificate is almost certainly going to be ignored by any relying 
party.

> That's probably implied by the other PKIX standards already, but it
> wouldn't hurt to mention it.  (As an implementation point, I don't think
> the Heimdal KCA will do that.)

Yeah; any given CA should not ever issue multiple certificates with the 
same serial number.  One way to achieve this therough deployment 
configuration is to give each KCA a separate name, private key, and CA 
certificate, making them in effect independent CA's with separate serial 
number spaces.

> I'm neutral.  Seems unnecessary, but easy to do (at least over TCP).

I could see this being useful.  In security-sensitive deployments the root 
CA will be carefully controlled, and its private key will likely be kept 
offline.  As a result, the KCA itself will not be a root, and this there 
will be at least one intermediate CA certificate.  It therefore becomes 
useful to be able to provide a client with the set of intermediates 
required to get from the root to the newly-issued certificate.

> You're quite right.  The version of the UMICH code I have has a build
> option to make the command into a library, but the pkcs11 library does
> not call it.  IMO what I said is how it should work, but I don't believe
> that's what's actually in the wild.

I'm not sure how that would work.  Is enrollment even in scope for PKCS#11?

> Should this standard say anything about how the cert should be cached in
> a Kerberos credential cache?  I see advantages to having UMICH/MIT code
> share an already-feched certificate with Heimdal code, but I had
> considered that to be out of scope for this work.  I think I still do.

I agree that specifying the details of the file credential cache format 
used by some implementations is out of scope.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Sat, 15 May 2010 12:37:46 -0400

What are the implications of using the pkinit SAN on being able to turn
around and use a KCA certificate with pkinit?  I'd assume that you
really do not want to permit that usage under normal circumstances, at
least not with the AS that issued the cert.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 May 2010 13:22:51 -0400

> least not with the AS that issued the cert.

Good question.  I think we mostly intended that the KRB5PrincipalName SAN 
be usable in certificates for a variety of purposes, and not only when the 
certificate was intended for use with PKINIT.  In fact, while the form is 
formalle specified in RFC4556, IIRC we borrowed it from another document 
that was not going to be advancing as quickly.

Unfortunately, while RFC4556 defines an extended key usage OID for use with 
PKINIT client certificates, it does not require this EKU to be present. 
So, a KDC which accepts any certificate containing a KRB5PrincipalName SAN 
as authenticating that principal for PKINIT is compliant.  That makes it 
dangerous to specify use of that SAN or issue certificates containing it, 
except when the issuer either intends the certificate to be usable with 
PKINIT or includes an ExtendedKeyUsage extension which precludes such use. 
And, I wouldn't really count on the latter, given the trouble we had with 
PKINIT and later documents in getting people to understand how EKU's were 
intended to work.

FWIW, the present issue is exactly why I and others have been so agressive 
in making the point that presence of a particular name type does not and 
should not imply that a certificate is acceptable for a particular use.  By 
allowing PKINIT implementations to infer such an implication, we've 
essentially destroyed the usefulness of the KRB5PrincipalName SAN for other 
usages.

This is going to suck, but I think I'm going to propose the specification 
of a new name type which has the form of KRB5PrincipalName but an OID 
distinct from that of id-pkinit-san.  The new type would be usable any time 
an issuer wishes to identify a certificate as belonging to a particular 
principal, and would explicitly _not_ imply usability for PKINIT or any 
other application.  In fact, I think I'd go so far as to specify that 
PKINIT implementations MUST NOT accept certificates on the basis of the new 
name type unless the id-pkinit-KPClientAuth EKU is present.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 17 May 2010 10:41:12 -0700

I'm pretty sure I don't levy any requirements in this area.  I also don't believe I should, though I could easily be convinced to put in a "SHOULD NOT" statement.

I do try to say the right things in the Security Considerations Section.  Please review that and make any suggestions you think appropriate.  I agree there's a lot of opportunity for problems (even if you don't allow authentication loops).

Also note, from other email, that I will be adding something to deal with the possibility of someone stealing just a public key and using this service to get a "duplicate" certificate.

On May 17, 2010, at 7:22 AM, Miller, Timothy J. wrote:

> PKINIT requires additional EKUs (unless the KDC isn't enforcing this), so a profile with a Kerberos principal name SAN isn't sufficient by itself.
> 
> However I agree with the general sentiment.  KX509 can act like a credential elevator, which makes me uncomfortable, but I haven't made up my mind re: further work on the protocol.
> 
> -- Tim
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Sam Hartman
>> Sent: Saturday, May 15, 2010 11:38 AM
>> To: Jeffrey Hutzelman
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [pkix] [saag] Draft KX509 Proposal
>>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 17 May 2010 12:13:30 -0700

Leaving PKINIT and authentication loop issues for another thread. . .

On May 14, 2010, at 7:03 PM, Jeffrey Hutzelman wrote:

> practice, it might be better to leave it unspecified.  

I tried to come up with some "SHOULD" wordage, but couldn't think of anything that didn't seem meaningless.  I'm open to suggestions, but will leave it unspecified in their absence.

> The answer is likely 

Yep.  Need to conform to local X.509 naming conventions first.  The mapping between that and the Kerberos name isn't something I can generalize to a requirement.  Most I could possibly say is there ought to be some kind of relationship, except in exceptional cases.

> into the certificate is almost certainly going to be ignored by any relying 

So I should put in a cross-reference to the right section of 4120, with a "SHOULD enforce" clause?

> certificate, making them in effect independent CA's with separate serial 

That's probably the right technical solution.  Since I'm in the middle of trying to figure out how to get a JPL CA certified, I'd expect some non-trivial auditing costs associated with that approach.  Maybe easier to just give each one a unique serial number prefix.

That's all implementation though.  I think the requirement is just that KCA's MUST issue certificates with globally unique serial numbers (somehow or other).

> required to get from the root to the newly-issued certificate.

Have to see if the UMICH KCA supports that.  This draft is supposed to document existing practice.

For the next version, I'd say the KCA MAY return the chain and define a place in the ASN1.

> I'm not sure how that would work.  Is enrollment even in scope for PKCS#11?

IMO the way it ought to work (as opposed to how it works now) is when you open the PKCS#11 library it should look for a an existing (unexpired) cert in the Kerberos ccache.  If there is, use it.  If there isn't one, then it goes and gets one (via KX509) and saves it to the ccache.

In other words, the use profile ought to be the same as any other Kerberized service.

> used by some implementations is out of scope.

OK.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 17 May 2010 14:58:10 -0500

> I tried to come up with some "SHOULD" wordage, but couldn't think of anything that didn't seem meaningless.  I'm open to suggestions, but will leave it unspecified in their absence.

Most likely the it is determined by the local policy of the KCA, just like any
other CA. Depending on how you want to look at how kx509 is being used. Is it
more like the Windows auto enroll certificates intended for a short time, usable
only at the local site, where the KCA cert is signed by the local CA or is kx509
being used as a source of a Grid certificate to be used at many sites.

> So I should put in a cross-reference to the right section of 4120, with a "SHOULD enforce" clause?

Yes. It could also be a policy of the KCA to not issue certificates
if cross realm is used!  A lot of these questions come down how will
the certificates issued by the KCA be used, and how much of the original
Kerberos authentication info need to be passed along in the certificate.

>> certificate, making them in effect independent CA's with separate serial 

The original UMich had a sn_increment=n parameter in the kca.cnf to
to make sure the serial numbers are different. (and setting the
starting serial numbers accordingly, like n=2 and even, odd.)

> In other words, the use profile ought to be the same as any other Kerberized service.

Depends on how PKCS#11 is used. For example, if I am running FireFox, that can have
multiple Security Modules i.e. PKCS#11s, I don't know if I would want it getting my a
key can cert under the covers.

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 17 May 2010 15:30:17 -0500

> Also note, from other email, that I will be adding something to deal with the possibility of someone stealing just a public key and using this service to get a "duplicate" certificate.

Good catch. This is an issue with the current protocol, that the client only send the
pub key, without demonstrating that it holds the private key.

In the Considerations, maybe it should be sending a PKCS#10 request - RFC2986. The request is
would not be saved, but if its still sent unencrtypted, as the key is in the current
protocol, it could be replayed. So it needs to be sent encrypted or used in some way
to prove to the KCA that the request is current.
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 

--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 17 May 2010 18:35:46 -0700

On May 17, 2010, at 5:52 PM, Russ Allbery wrote:

> Jeffrey Altman <[email-masked]> writes:
>> On 5/17/2010 1:22 PM, Jeffrey Hutzelman wrote:
> 
>>> FWIW, the present issue is exactly why I and others have been so
>>> aggressive in making the point that presence of a particular name type
>>> does not and should not imply that a certificate is acceptable for a
>>> particular use.  By allowing PKINIT implementations to infer such an
>>> implication, we've essentially destroyed the usefulness of the
>>> KRB5PrincipalName SAN for other usages.
> 
>>> This is going to suck, but I think I'm going to propose the
>>> specification of a new name type which has the form of
>>> KRB5PrincipalName but an OID distinct from that of id-pkinit-san.  The
>>> new type would be usable any time an issuer wishes to identify a
>>> certificate as belonging to a particular principal, and would
>>> explicitly _not_ imply usability for PKINIT or any other application.
>>> In fact, I think I'd go so far as to specify that PKINIT
>>> implementations MUST NOT accept certificates on the basis of the new
>> It is then unfortunate that deployed KCA implementations have been using
>> the KRB5PrincipalName type for many many years now.  The KCA developers
>> lifted the name type from the same place that PKINIT did.  It is too
>> late to put the genie back in the bottle.
> 
> While not ideal, this *can* be addressed operationally by telling
> implementors to not use the same root CA trust path for KCA-issued
> certificates as for PKINIT client authentication, yes?

Yes.  I expect there are lots ways to "break" the potential loop.  What's important is that deployers know they need to avoid the pothole.

This is off-topic, but the Microsoft UPN and the id-pkinit-san value in the certificate are put there by the certificate issuer.  In the case of smart cards the issuer frequently (mostly?) is a different organization from the one running the KDC and supporting PKINIT.  That makes those attributes problematic at best and dangerous at worst.

What I'm doing in my deployment is set a PKINIT ACL on the Kerberos identity matching the Subject the issuer put in the card's cert.  (Those attributes are given no authority, and all the client-side stuff that tries to use them is just an annoying waste of time.)  Then I made sure any KCA-issued certs have a completely different form for the Subject.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 11:01:18 -0400

--On Monday, May 17, 2010 06:35:46 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> This is off-topic, but the Microsoft UPN and the id-pkinit-san value in
> the certificate are put there by the certificate issuer.  In the case of
> smart cards the issuer frequently (mostly?) is a different organization
> from the one running the KDC and supporting PKINIT.  That makes those
> attributes problematic at best and dangerous at worst.

Only if you blindly trust them.  If you're going to trust an issuer for 
PKINIT, you'd better make sure you understand their naming policy.

> What I'm doing in my deployment is set a PKINIT ACL on the Kerberos
> identity matching the Subject the issuer put in the card's cert.

Right, so the mapping between certificate subjects and Kerberos principals 
is done by lookup in your KDB, rather than by an algorithmic translation. 
PKINIT permits this, because it was anticipated that it would be common for 
KDC operators to want such a policy.  It also permits the KDC to ignore the 
PKI entirely and record direct mappings between principals and individual 
certificates or public keys.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 11:09:00 -0400

--On Tuesday, May 18, 2010 12:43:11 AM -0400 Jeffrey Altman 
<[email-masked]> wrote:

> On 5/17/2010 3:13 PM, Henry B. Hotz wrote:
>> That's probably the right technical solution.  Since I'm in the middle
>> of trying to figure out how to get a JPL CA certified, I'd expect some
>> non-trivial auditing costs associated with that approach.  Maybe easier
>> to just give each one a unique serial number prefix.
>
> There are multiple ways to handle this.  The draft does not have to
> indicate what approach should be taken as long as the requirement is met.

Agree.

> The existing deployed versions do not support delivering certificate
> chains.
>
> I believe what you need to say is that the KCA clients must be prepared
> to accept certificate chains if they are provided.  The existing clients
> do not.

Well, you'd also have to define a way to do so.  This is clearly a protocol 
change, and my comments, at least, were in the context of a potential 
revision _after_ the informational document.

> The fact that some UMich code stores an X.509 client certificate and
> private key within a Kerberos v5 FILE: credential cache is very much a
> hack.  If a certificate/key is going to be stored somewhere it should be
> in the certificate/key store provided by the OS and used by the majority
> of applications.

It's a hack, but it's a useful hack, on some platforms.  It is also widely 
supported in existing KX509 implementations, and so IMHO is worth 
documenting to the extent that the present document does so.  Whether we 
continue to include that information in a revised protocol document is 
another question entirely.

> Several people over the years have recommended that a PKCS#11 library
> should automatically fetch a client certificate on behalf of a user at
> the time the certificate is required.  Given the way that most if not
> all TLS libraries work, that would require the PKCS#11 module be aware
> of all of the potential KCA certs that could be requested along with the
> properly binding to the correct Kerberos principal and credential cache.

Yes, there's an identity management problem here.
There's nothing new about that.

> I believe that the X.509 KCA cert is the equivalent to a TGT.  A TGT is
> not automatically fetched when contacting a service and neither should a
> KCA cert be.

On the contrary, a KCA cert is the equivalent of a _cross-realm_ TGT, which 
most definitely is fetched automatically when appropriate.  I see no 
problem with automatically fetching a KCA cert when contacting a service 
that would accept such a cert.  Of course, the difficulty is that the 
primary means of automatic identity selection among PKCS#11 users is to 
compare issuers of certificates one has with those the service claims to 
trust, and one cannot do that until one actually _has_ the certificate.

> 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

---

From: Alan Sill <[email-masked]>
Date: Fri, 14 May 2010 08:55:11 -0500

In this context, I recommend study of the IGTF's relevant  
authentication profiles.  There are at least two (SLCS and MICS) that  
are relevant here.

Both are linked from the home page
http://igtf.net

SLCS covers kx509 and similar services to turn internally held secure  
directories into X.509 short-term certs.  SLCS is oriented toward this  
"non-exhaustive list" of sources for issuing short-lived certs.

1. Kerberos-based authentication service
2. Windows Domain
3. One Time password service
4. Another PKI with long term certificates
5. LDAP User Account service
6. Shibboleth-based federation

MICS is a generalization and variation of the SLCS profile aimed at  
similar situations, but can in some cases issue long-lived certs.

While these are not per se PKIX topics, in that the structure of the  
cert is governed more by GFD.125 (the grid certificate profile of  
OGF), it shows that there are no specific reasons that we cannot  
already handle kx509 acceptably in the extensive existing range of  
existing profiles.

What specific problem would you want to solve in the context of PKIX  
with respect to kx509 that is not already solved by the above?  (Not a  
hostile question, I'm just curious.)

On May 13, 2010, at 8:32 PM, Henry B. Hotz 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.
>
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 17 May 2010 13:28:22 -0400

On 5/17/2010 1:22 PM, Jeffrey Hutzelman wrote:

> specification of a new name type which has the form of KRB5PrincipalName
> but an OID distinct from that of id-pkinit-san.  The new type would be
> usable any time an issuer wishes to identify a certificate as belonging
> to a particular principal, and would explicitly _not_ imply usability
> for PKINIT or any other application.  In fact, I think I'd go so far as
> to specify that PKINIT implementations MUST NOT accept certificates on
> the basis of the new name type unless the id-pkinit-KPClientAuth EKU is
> present.

It is then unfortunate that deployed KCA implementations have been using
the KRB5PrincipalName type for many many years now.  The KCA developers
lifted the name type from the same place that PKINIT did.
It is too late to put the genie back in the bottle.

Jeffrey Altman

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 17 May 2010 10:22:42 -0400

-- Tim

---

From: Russ Allbery <[email-masked]>
Date: Mon, 17 May 2010 17:52:31 -0700

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 May 2010 00:43:11 -0400

> That's all implementation though.  I think the requirement is just that KCA's MUST issue certificates with globally unique serial numbers (somehow or other).

Agreed.

> Have to see if the UMICH KCA supports that.  This draft is supposed to document existing practice.

The existing deployed versions do not support delivering certificate chains.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 12:13:14 -0400

--On Tuesday, May 18, 2010 11:46:21 AM -0400 Jeffrey Altman 
<[email-masked]> wrote:

> 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.

Ordinarily, I'd agree.  It certainly has no place in normative text.  But 
for an informational draft describing the existing KX509, I think it's 
worth documenting that this is being done, as Henry has done in the 
existing appendix.

I suggest leaving the appendix as-is in the current, without adding more 
detail but also not removing it.  If/when the standards track document 
happens, we can remove it entirely from there.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 18 May 2010 11:05:40 -0700

I was going to write a response to Jeffrey A's email myself, but I agree with Jeffrey H says (except I'll correct my factual error re existing client behavior).  Is Jeffrey A comfortable with postponing the rest of the discussion until we have a revised protocol on the table?

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 18 May 2010 11:07:17 -0700

> PKINIT, you'd better make sure you understand their naming policy.

The ringer here is I've hit an awful lot of client card infrastructure that thinks you should fill in the username at login based on the UPN (and I don't just mean on Microsoft clients).  Figuring out how to disable that behavior everywhere has been a royal PITA.

I've been complaining about that a lot lately.  Sorry if this off-topic tangent is a repeat for people.

> certificates or public keys.

Well, I do verify the cert against a known CA, but skipping that's not what you meant by "ignore", I'm sure.

I anticipate needing to support PKINIT clients using certs from many different issuers.  This direct mapping approach is way more straightforward  and flexible (as long as I don't get multiple issuers with overlapping subject name hierarchies).  (It also adds fuel to my flame concerning how clients handle the UPN and/or the id-kinit-san attribute.)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 18 May 2010 11:09:23 -0700

On May 18, 2010, at 5:56 AM, Sam Hartman wrote:

> Honestly, though, the more I think about this, this seems a classic
> problem of trust: under most circumstances, the KCA should not be
> trusted by the KDC's pkinit CA to issue any certificates.
> 
> It seems like  there are many ways to accomplish this:

And you didn't even cover the one I actually implemented.  ;-)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 23 May 2010 22:26:44 -0700

To keep the record straight, I'm not the one who caught the problem (though I feel like I should have).  Jeffrey Altman told me about it.  I don't know if anyone else told him about it.