Subject: [Ietf-krb-wg] 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]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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: "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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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

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: 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: Jeffrey Altman <[email-masked]>
Date: Mon, 17 May 2010 13:28:22 -0400

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

---

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.

--

---

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

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

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

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>
_______________________________________________
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

> 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 Altman <[email-masked]>
Date: Tue, 18 May 2010 00:43:11 -0400

> 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 approac…

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

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

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.

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

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.

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.

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

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.

>> used by some implementations is out of scope.

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.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 08:56:44 -0400

>>>>> "Miller," == Miller, Timothy J <[email-masked]> writes:

    Miller,> PKINIT requires additional EKUs (unless the KDC isn't
    Miller,> enforcing this), so a profile with a Kerberos principal
    Miller,> name SAN isn't sufficient by itself.  

No, not really. RFC 4556 does not require a KDC to require the pkinit
EKU.
A KDC MAY require this keyPurposeID.
The KDC MUST process the EKU extensions.
So, if KX509  were to issue a certificate  with an EKU extension
including neither the any key usage ID nor the pkinit ID, then the
certificate will not work for pkinit.

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:

1) Don't have a certification path leading from the KCA's certificate to
a trust anchor for pkinit.

2) Use certificate policy to restrict what is permitted.

3) Explicitly blacklist the KCA as an issuer in pkinit

4) Require the pkinit keyPurposeId 

5) Issue certificates  with keyPurposeIDs inconsistent with pkinit

6) Include some extension in the cert indicating it is a KX509
certificate and disallow such certs in pkinit.

Note that using KCA for pkinit should not be an absolute prohibition; it
is normally not what you want and I think is rarely a good idea within
the same local realm.  That's not the same as saying you might not want
it in some site security policies.

Also, the risk can be managed by:

1) Restricting the validity of the KCA certificate to the validity of
the Kerberos ticket

2) Restricting the lifetime of issued tickets from pkinit to the
validity of the cert.  We probably don't implement that now and it's
probably a bug.

I've been thinking about Jeff Hutzelman's comments.  I agree with him
that a name form should semantically be the name of an entity and should
not inherently carry authorization information.  However, I disagree
that we went beyond that in RFC 4556.  It seems like establishing that a
particular public key speaks for a given name in the opinion of a
trusted issuer is an entirely reasonable local authorization policy for
a credential translation service like pkinit.  RFC 4556 permits this
policy; I see nothing wrong with that.  I've enumerated several ways
that we can address any potential conflict between this policy and KCA
interactions.  Most of these mechanisms take advantage of existing PKIX
mechanisms for their intended purposes.  In addition, ultimately if an
authorization policy doesn't work for your site, choose a different
policy.

In conclusion, I definitely think the KX509 protocol spec should discuss
this in detail.  I think that we may want to require support for some of
the mechanisms above either in KX509 or in pkinit implementations that
run along side KX509 implementations.  However, after reflecting on this
issue, I see no huge problem here.

--Sam

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 18 May 2010 09:47:33 -0500

Miller, Timothy J. wrote:

> 
> IMHO, if you've a CA issuing certs for PKINIT, why you're bothering to go through the rigmarole of KX509 is beyond me.  The integration costs associated with doing KX509 right without interfering with the non-KX509 portion of your PKI are going to eat all the perceived savings of not using the simple X.509 infrastructure to begin with.
> 

An example, Grid computing:
  User gets Kerberos ticket using password or pkinit at home site.

  User get kx509 from home KCA.

  The kx509 certificate is used with Grid GSI and proxy certificates
  to authenticate job across multiple sites, some of which have Kerberos
  and require Kerberos ticket to access resources.

  The proxy certificate with the kx509 in is chain is used to get
  kerberos ticket via pkinit. One site may be the user's home site.

http://www.globus.org/grid_software/security/kx509-and-kca.php
http://www.globus.org/grid_software/security/pkinit.php

--

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 18 May 2010 10:03:50 -0400

>No, not really. RFC 4556 does not require a KDC to require the pkinit

Point.  I was thinking about the common implementations, but that's optional now in all of them at this point.

>a trust anchor for pkinit.

Because two in-house PKIs are clearly better than one!  :)

>2) Use certificate policy to restrict what is permitted.

I'd hate to have to fall back on policy processing because it's infrequently supported.  This would be a change to PKINIT.

>3) Explicitly blacklist the KCA as an issuer in pkinit

I'm OK with trust lists, and most of the PKINIT implementations support them for at least *some* PKINIT processing paths.  But not all do.  E.g., Windows 2008 KDC requires a PKINIT certificate to chain through the CAs listed in the NTAuthCA trust list, but *only* for certain methods the KDC uses to associate a cert with an account.  Others methods need only satisfy simple system trust.

This is a new requirement on PKINIT.

>4) Require the pkinit keyPurposeId

Probably the best of a bad lot, but it's also a change in PKINIT.

>5) Issue certificates  with keyPurposeIDs inconsistent with pkinit

Hard to do; IIRC PKINIT only needs digitalSignature.

>certificate and disallow such certs in pkinit.

Ugly hack, as it's a new requirement on PKINIT.  See above.

Of the lot above, only the separation of trust and limited keyUsage for KX509 are viable methods that can be specified *in* KX509 (and limited keyUsage is unlikely to be practical).  Ideally you don't want to have one RFC mandate changes in another RFC, so levying new PKINIT implementations in KX509 can't work.  The rest are potentially workable ideas, but require taking up PKINIT for update.

-- Tim

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 10:48:57 -0400

> trusted by the KDC's pkinit CA to issue any certificates.

I mostly agree.  The requirements we've placed in PKINIT, and the behavior 
of existing KCA's, possibly other issuers, and probably other relying 
parties result in the unfortunate possibility that a certificate issued by 
a KCA or another issuer not aware of PKINIT could, if one considers only 
the certificate itself, be accepted by a PKINIT KDC.

However, the operator of a PKINIT KDC which depends solely on certificate 
validation and direct use/conversion of the subject name(s) found in 
certificates must be exceptionally careful about what authorities he 
trusts.  He also must have a good understanding of whta policies are used 
by those authorities to determine subject names in certificates issued by 
them.  And, it is also highly likely (though by no means required) that a 
KCA issuing certificates in a heirarchy trusted by the KDC for PKINIT will 
be operated in close concert with the KDC itself.

So, the problem is certainly not insurmountable.  It simply requires a 
certain level of care in configuration, particularly when deploying a KDC 
which supports PKINIT.

> certificate and disallow such certs in pkinit.

In fact, it might be interesting to define such an extension, if we take on 
the work of revising KX509 for publication on the standards track.  This 
would presumably also provide an opportunity to carry over additional 
information from Kerberos, such as the cross-realm capath list or any 
authorization data.

> 1) Restricting the validity of the KCA certificate to the validity of

IMHO this should be at least RECOMMENDED.

> validity of the cert.  We probably don't implement that now and it's

Yes, that would be a bug; this behavior is REQUIRED by PKINIT.  See 
RFC4556, in the last paragraph before section 3.2.3.1.

-- Jeff

---

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:

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

Agree.

> to accept certificate chains if they are provided.  The existing clients

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.

> in the certificate/key store provided by the OS and used by the majority

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.

> properly binding to the correct Kerberos principal and credential cache.

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

> not automatically fetched when contacting a service and neither should a

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.

> 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: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 11:31:24 -0400

>>>>> "Miller," == Miller, Timothy J <[email-masked]> writes:

    Miller,> Of the lot above, only the separation of trust and limited
    Miller,> keyUsage for KX509 are viable methods that can be specified
    Miller,> *in* KX509 (and limited keyUsage is unlikely to be
    Miller,> practical).  Ideally you don't want to have one RFC mandate
    Miller,> changes in another RFC, so levying new PKINIT
    Miller,> implementations in KX509 can't work.  The rest are
    Miller,> potentially workable ideas, but require taking up PKINIT
    Miller,> for update.

I disagree with your reasoning here.  The requirement is simply that in
a given deployment, the trust objectives of that deployment need to be
met.  It's entirely reasonable for the KX509 spec to make requirements
for KDCs implementing KX509, including requiring support for optional or
even new features in the pkinit implementations of those KDCs.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 18 May 2010 10:35:01 -0500

Miller, Timothy J. wrote:
> Alternatively, you could sign the proxy cert(s) directly with the PKINIT certificate (or any other digitalSignature certificate issued to the user), without the KX509 infrastructure, for grid resources that are proxy-cert enabled, and use Kerberos for grid services that are Kerberized.
> 
> This would be conceptually simpler (though not necessarily technically simpler :) and eliminates the risk of misplaced trust in the KX509 issued certificate.
> 

True, but those simple trust path may not be there for many reasons.
For example Grid applications may run across the world, and the trust
of a KCA at a site may have been established for use with the Grid.
But the user, for example here in U.S. has PIV card signed by OMB.
It is trusted at the user's home site for PKINIT, but not across the
world for use with the grid. There is also no cross realm trust between
many of these sites (or even Kerberos at some sites), so a Kerberos
only solution would not work either.

>> From: Douglas E. Engert [mailto:[email-masked]]
>> Sent: Tuesday, May 18, 2010 9:48 AM
>> To: Miller, Timothy J.
>> Cc: 'Sam Hartman'; [email-masked]; [email-masked]; Jeffrey
>> Hutzelman
>>> IMHO, if you've a CA issuing certs for PKINIT, why you're bothering to
>> go through the rigmarole of KX509 is beyond me.  The integration costs
>> associated with doing KX509 right without interfering with the non-KX509
>> portion of your PKI are going to eat all the perceived savings of not
>> using the simple X.509 infrastructure to begin with.

--

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 18 May 2010 11:14:53 -0400

-- Tim

---

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

On 5/18/2010 11:09 AM, Jeffrey Hutzelman wrote:
> 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: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 12:13:14 -0400

> protocol and as such (in my opinion) should not be a part of an

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

> 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: Tue, 18 May 2010 11:11:11 -0700

On May 18, 2010, at 7:03 AM, Miller, Timothy J. wrote:

> IMHO, if you've a CA issuing certs for PKINIT, why you're bothering to go through the rigmarole of KX509 is beyond me.

Without getting into the religious aspects of Kerberos vs PKI, can I just say that there are everyday usability issues which were not addressed by current PKI design.  

I have a legitimate need to support the Kerberos usability model in conjunction with non-password initial authentication mechanisms.  That means I need to support both client PKI certs and Kerberos tickets from the same identity infrastructure because some off-the-shelf software understands one and some the other.  I don't need any authentication loops, but supporting both PKINIT and KX509 is the only way I see to do that.

I would have agreed with you about the complexity issue until Heimdal built a KCA into their KDC.  Now the server side is "free" except for all the lawyers, accountants and auditors we need to hire if we want the certs publicly recognized.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 18 May 2010 17:53:39 -0700

> using the simple X.509 infrastructure to begin with.

Here's an example use case.

I only want to manage one piece of secure data per application service,
and I already have excellent tools for handling Kerberos keytabs.  KX509
lets me continue to use my existing key management procedures for
application service keys, while allowing those applications to obtain
short-lived certificates if they need to authenticate to something like a
web service where the Kerberos options are difficult to deploy or
unavailable.

I separately want to enable PKINIT for hardware authentication tokens,
which will be issued through a formal issuance process managed by
Microsoft Forefront Identity Manager.

The two uses of X.509 really have nothing to do with each other.  The
PKINIT issuance process is not going to be helpful or useful for getting
application certificates, nor would I want to replace the (much easier to
manage in general) persistent keytabs with persistent certs.

> Because two in-house PKIs are clearly better than one!  :)

Multiple PKIs *are* better than one if those PKIs have drastically
different policies, target audiences, use cases, and identity management
infrastructures behind them.  At that point, it is conceptually cleaner
and, I think, more secure to separate the PKIs.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 May 2010 15:56:01 +0200

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

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 20 May 2010 11:22:31 -0500

> and I would be happy if you could help un-confuse me.

The original kx509 http://www.citi.umich.edu/projects/kerb_pki/ the Readme
file says Kx509 has been around with Kerberos V5 since at least 6/26/2000.
I started working with this in August 1999. It has had wide use but no standards.
Henry is attempting to do this. Thanks Henry.

Agreed.

Agreed.

> certificate to the lifetime of the ticket.

Similar to the Windows Auto Enroll certificates, The Kx509 certificates
where originally meant to be short term and disposable where the key is not
protected by a passphrase, but stored in temp protected bu the OS, accessible
only to the user and deleted at logoff. The user could always get another one,
and could have multiple Kx509 certificates one per session and could have them
on multiple machines. Each certificate would have the same subject name derived
from the principal name. Thus a web server would accept these as coming from
the user. Since they are short term, the KCA may not produce CRLs.

> Compare if I use an ID-card to
> would be avoided if an existing request format was used

The draft is attempting to document the current protocol. I agree that
any new version should use PKIX request forms.

> a certificate or an error. What if the request is pending for some reason?

The original KCA would issue or not issue a certificate. There was no way
to hold a request. But in a new version, maybe that would be a good idea,
especially if you want to issue longer term certificates.

> even why you need to specify the use of UDP in the first place.

Again that was how the original code worked. The Kerberos tickets and
certificates were small, so UDP worked well. If the next version adds larger
tickets, certificate chains some other  protocol might be better.

--

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 May 2010 23:47:21 +0200

Thanks for the explanations Douglas.

That certainty brings a lot of clarity. If this is documenting an existing
protocol, then that should be clearly stated. Perhaps it is and I just
missed it?

> the user. Since they are short term, the KCA may not produce CRLs.

This to me is not an argument why this need to be a general rule. This is
just explaining one out of many possible use cases.
Microsoft auto-enrollment is not limited to short lived certificates. It is
equally useful for managing issuance and renewal of long lived certificates.

If the specification doesn't limit the scope of issued certificates, then I
don't think it is appropriate to limit the validity either. The appropriate
lifetime of a certificate is much more dependent on the protection of the
private key and the stability of identification attributes, than it is
dependent on the quality of authentication. That aspect does not degrade
over time. IT either was, or was not good enough at the time of issuance.

/Stefan

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 20 May 2010 22:15:02 -0700

What Doug said.  ;-)

> and I would be happy if you could help un-confuse me.

I think a lot of the comments are from people who already have some familiarity with the protocol.

> accept this form of request supported by Kerberos authentication.

While there are serious issues to point out in the security considerations section, that's fundamentally true.  Nothing is technically out of scope or explicitly prohibited (or impossible even if it were prohibited).  Like everything else, you can shoot yourself in the foot, hand, head, or anywhere else if you so choose.

> (Kerberos principal name).

I wouldn't deploy something that didn't include part of the Kerberos principal name in the cert's Subject name.  I could imagine someone wanting to use a KCA to provide a kind of anonymous authentication though.

> database trusted by the KCA.

Correct, though as a practical matter a UDP protocol with a fixed timeout doesn't work well when the reply is dependent on other services' replies.  Kerberos services typically have shorter timeouts than LDAP services for instance.

> only thing is that my ID-card is valid when it is used.

If the expiration of your ID card actually represents an expiration of the identity it represents, then it would be foolish to issue a passport with a later expiration date.  What you describe is done because the date is usually the expiration of some authorization (e.g. to drive a car) rather than of the identity itself.  An expired passport is still valid as identification (I just used a 2-year-expired one to get a new passport).  It just doesn't authorize you to travel.

If you replicate the original expiration time, then that's "safe" from a policy standpoint.  It's also short enough you probably don't need an OCSP server, etc.  If you want to extend the lifetime, then you should know why your particular infrastructure makes that reasonable.

> would be avoided if an existing request format was used.

I think that's a perfectly valid criticism, which may be addressed in a future revision of the protocol.  In the mean time we have what's already out in the wild.

> a certificate or an error. What if the request is pending for some reason?

I think that's a perfectly. . . (see above)

As noted in Appendix B, I don't fully specify timeout/retry behavior.  I confess the concept of a "wait" response is foreign to me.  Could you elaborate?

> even why you need to specify the use of UDP in the first place.

I think that's a perfectly. . . (see above)

If I don't specify *some* transport mechanism then I haven't specified enough for someone to build an interoperable implementation.

> /Stefan

As Doug noted, this protocol is actually fairly old.  It was originally implemented and documented with Kerberos 4, for instance.

---

From: "Henry B.Hotz" <[email-masked]>
Date: Thu, 20 May 2010 22:35:33 -0700

What Doug said.  ;-)

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 21 May 2010 12:26:11 +0200

In line;

On 10-05-21 7:15 AM, "Henry B. Hotz" <[email-masked]> wrote:

> While there are serious issues to point out in the security considerations
> section, that's fundamentally true.  Nothing is technically out of scope or
> explicitly prohibited (or impossible even if it were prohibited).  Like
> everything else, you can shoot yourself in the foot, hand, head, or anywhere
> else if you so choose.
> 
> I wouldn't deploy something that didn't include part of the Kerberos principal
> name in the cert's Subject name.  I could imagine someone wanting to use a KCA
> to provide a kind of anonymous authentication though.
> 
> Correct, though as a practical matter a UDP protocol with a fixed timeout
> doesn't work well when the reply is dependent on other services' replies.
> Kerberos services typically have shorter timeouts than LDAP services for
> instance.
> 
> If the expiration of your ID card actually represents an expiration of the
> identity it represents, then it would be foolish to issue a passport with a
> later expiration date.

Exactly. And since the it is not clear from the draft that the certificate
will carry an identity that expires at the same time as the ticket, I don't
see why the general rule is that the certificate should not survive past the
ticket used for user authentication.

> What you describe is done because the date is usually
> the expiration of some authorization (e.g. to drive a car) rather than of the
> identity itself.

No. The expiry date of my drivers license is not a date when my license to
drive expires. It is just a date when I have to renew the license, probably
so that I can include a more recent photo and prevent it from falling apart.

>  An expired passport is still valid as identification (I just
> used a 2-year-expired one to get a new passport).  It just doesn't authorize
> you to travel.
> 
> If you replicate the original expiration time, then that's "safe" from a
> policy standpoint.  It's also short enough you probably don't need an OCSP
> server, etc.  If you want to extend the lifetime, then you should know why
> your particular infrastructure makes that reasonable.
> 
> I think that's a perfectly valid criticism, which may be addressed in a future
> revision of the protocol.  In the mean time we have what's already out in the
> wild.
> 
> As noted in Appendix B, I don't fully specify timeout/retry behavior.  I
> confess the concept of a "wait" response is foreign to me.  Could you
> elaborate?

If for example the request is pending. E.g. Because the KCA is waiting for a
response from user identity repository to retrieve user identity attributes
that are going into the certificate, then it would be useful if the KCA
could say like: "Certificate request is pending, ask again later", or "....
Ask again in xx seconds" or whatever is relevant for this case.

> If I don't specify *some* transport mechanism then I haven't specified enough
> for someone to build an interoperable implementation.
> 

Many request/response protocols are agnostic about transport, and other
defines transport in an independent document to make it easy to define how
to add/use other transport protocols over time.

For example RFC 5272 (CMC) and RFC 5273 (CMC Transport protocols)

/Stefan

>> /Stefan
> 
> As Doug noted, this protocol is actually fairly old.  It was originally
> implemented and documented with Kerberos 4, for instance.
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 21 May 2010 09:41:26 -0400

>That certainty brings a lot of clarity. If this is documenting an
>existing protocol, then that should be clearly stated. Perhaps it is and I just
>missed it?

Also, if it's only documenting only the existing protocol, shouldn't it be on the info track instead?

-- Tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 21 May 2010 08:31:23 -0700

If you look at my first post, I said I already had some private feedback.  Changing this draft to informational and creating a new version with incompatible fixes was the biggest thing I got (which I've already agreed with).

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 20 May 2010 16:06:29 -0700

What Doug said.  ;-)

---

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.