headers
Jan Pechanec | 2 May 2010 11:44
Picon

I-D on PKCS#11 URI Scheme for naming objects


	hi,

	while working on a couple of projects in the OpenSolaris 
development we realized that a new PKCS#11 URI scheme would be very 
handy to universaly reference public and private keys as well as 
certificates that are stored in PKCS#11 tokens. For example, we already 
use the scheme in our OpenSSL PKCS#11 engine to access keys in tokens 
through the regular OpenSSL API, and SSH is one of another candidates.

	I was told recently that this working group has many people who 
care about PKCS#11. We would appreciate any feedback on the I-D.

	the draft is here:

	http://www.ietf.org/id/draft-pechanec-pkcs11uri-01.txt

	while we discussed the initial attribute-value pair idea on the 
Cryptoki mailing list, the I-D itself sent there raised no discussion, 
and we didn't get any feedback from the OpenSC mailing list either. So, 
I can't provide any link to any passed discussion on the I-D.

	best regards, Jan.

PS: please CC both Darren and me since we are not members of the mailing 
list. Thank you.

--

-- 
Jan Pechanec
http://blogs.sun.com/janp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 7 May 2010 04:23

Sean's 1st AD Notes for 2010-04

Here's my 1st attempt at continuing Pasi's much liked monthly AD 
notes.  It's a short status update about what things are going on from
my point-of-view. If you notice anything that doesn't look right, let
me know -- miscommunication and mix-ups do happen.

Pasi had a clock going on many of these.  I'm going to restart the 
clock.  Oh and the date format is YYYY-MM-DD.  Also these were written 
as of 2010-05-01 and things have happened since then.

Cheers,
spt

MISC NOTES

- Reviewed SAAG meeting minutes (Thanks Tero for the draft).

- IETF 78 planning with Tim: SAAG presentations.

- Arranged weekly call with Tim.

- Learning just how much I'm going to rely on SECDIR reviews.

- Reviewed draft-iab-auth-mech and provided lots of comments.

- ~100 errata received from Constantin Hagemeier on RFC 3447, RFC 4301
   RFC 4302, RFC 4306, and RFC 4880.  Will rely on authors to help
   resolve these.

- Errata 762, 1609, 1620, 1840, 2090, 2089, 2090, 2089, 2088, 2087,
   Held for Document Update (HFDU).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry B. Hotz | 14 May 2010 03:32
Picon
Picon
Favicon

Draft KX509 Proposal

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.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu
Permalink | Reply | 14 comments |
headers
Douglas E. Engert | 14 May 2010 17:43
Favicon

Re: Draft KX509 Proposal


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.
> 
> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sam Hartman | 14 May 2010 21:19
Picon
Favicon

Summary of Federated Authentication BOF at IETF 77


I'm told there were around 30 people in the room.  That seemed like a
good turn out for Thursday at 9 PM.

Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication  for non-web applications.
Two solutions were presented.  I presented work on Moonshot, a
technology that combines EAP, GSS-API, RADIUS and SAML to solve the
problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
that uses browser-based SAML and Open ID.

The sense of the room was that these solutions compliment each other.
Moonshot requires more infrastructure and client configuration but
provides several advantages.  The browser-based solutions are something
that requires fewer client changes.

Volunteers were collected from the EAP, GSS and RADIUS communities who
would be interested in working on these problems.  Some of the work
discussed, possibly especially including the Open ID and SAML
browser-based solutions may be able to progress in kitten.  I and I
believe several of the other Moonshot proponents would prefer to focus
the Moonshot work in one working group.  Other solutions could also be
progressed in that group, although we should be careful not to slow down
work that could progress quickly in kitten by moving it into an
as-yet-unchartered group.

There seemed to be strong support for going forward.  However, several
things to address in a BOF were raised with regard to the Moonshot work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 15 May 2010 04:03
Picon
Favicon

Re: Draft KX509 Proposal

--On Friday, May 14, 2010 04:55:24 PM -0700 "Henry B. Hotz" 
<hotz <at> jpl.nasa.gov> wrote:

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

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.

> Then, of course, there are all the capath validation questions.  Do you
> 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
(Continue reading)

Permalink | Reply | 28 comments |
headers
Sam Hartman | 15 May 2010 18:37
Picon
Favicon

Re: Draft KX509 Proposal

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.
Permalink | Reply | 20 comments |
headers
Henry B. Hotz | 18 May 2010 03:35
Picon
Picon
Favicon

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


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

> Jeffrey Altman <jaltman <at> secure-endpoints.com> 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
>>> 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.
> 
> While not ideal, this *can* be addressed operationally by telling
> implementors to not use the same root CA trust path for KCA-issued
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael StJohns | 14 May 2010 04:20
Picon

Re: [pkix] Updates Needed for draft-hotz-kx509-00

At 09:32 PM 5/13/2010, Henry B. Hotz wrote:
>        • Use of subject Alt e-mail field for principal name
>(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't
necessarily work as one.  If it's existing practice, then fine, but delete it in the new version.)

See RFC4456 - specifically the id-pkinit-san subject alternative name encoding which defines a kerberos
centric certificate name encoding.

Mike
Permalink | Reply | 0 comments |
headers
Henry B. Hotz | 18 May 2010 20:05
Picon
Picon
Favicon

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

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?

On May 18, 2010, at 9:13 AM, Jeffrey Hutzelman wrote:

> --On Tuesday, May 18, 2010 11:46:21 AM -0400 Jeffrey Altman 
> <jaltman <at> secure-endpoints.com> 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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu
(Continue reading)

Permalink | Reply | 0 comments |

Gmane