Jan Pechanec | 2 May 11:44 2010
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)

Sean Turner | 7 May 04:23 2010

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)

Henry B. Hotz | 14 May 03:32 2010
Picon
Picon

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

Henry B. Hotz | 14 May 03:32 2010
Picon
Picon

Updates Needed for draft-hotz-kx509-00

I was able to circulate this draft privately before I had clearance to submit it.  Based on feedback from two
implementors of the protocol I can already say:

1) There should be a standards-track version of an update to the protocol which takes advantage of the
evolution of both Kerberos and PKI since the protocol was created.

2) The draft, though written to be standards-track, should instead be informational.

I welcome other feedback.  Comments I have so far are:

Should use the kerberos checksum instead of HMAC-SHA1 (IMO bumps protocol version).

Error codes should be standardized, allowing better client failover.

Public Key type needs more specification.  In particular some specification (or negotiation) of minimum
key size, and allowable key types.  (Existing client implementations seem to only generate 512-bit RSA
keys.  Needs updating, but that doesn't force a version change.)

Certificate encoding needs more specification.  In particular I'm told that the issued certificates
should include:

	• KCA  "1.3.6.1.4.1.250.42"
	• KCA AUTH REALM   "1.3.6.1.4.1.250.42.1"
	• Krb5 Principal Name "1.3.6.1.5.2.2"
	• 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.)

Add text to the security considerations noting that there is no proof the requester is in possession of the
corresponding private key, which opens up a number of issues.  Shouldn't use these certs for digital
(Continue reading)

Michael StJohns | 14 May 04:20 2010
Picon
Picon

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

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Michael StJohns | 14 May 04:20 2010
Picon
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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Alan Sill | 14 May 15:55 2010
Picon

Re: Draft KX509 Proposal

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

Douglas E. Engert | 14 May 17:43 2010

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)

Martin Rex | 14 May 19:09 2010
Picon

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

Michael StJohns wrote:
> 
> 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.

It seems that Microsoft has been shipping functionality to include
_some_ principal name ("UPN") in X.509v3 certificates, in a
subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3.

Unfortunately it shares the awkwardness with their APIs in that it
is not a valid Kerberos principal name.  The uppper/lowercasing
of the Realm part is definitely incorrect, and I wouldn't bet on
the correctness of the upper/lower-casing on the part before
the " <at> " either.  So that entry is a someone unusable unless oneself
happens to be the responsible Active Directory that is cabable to
correctly canonicalize that UPN into a correct Kerberos principal
name for use within Kerberos protocol exchanges.

-Martin
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

(Continue reading)

Kemp, David P. | 14 May 20:02 2010

Re: Updates Needed for draft-hotz-kx509-00

The X.509 GeneralName field used in the SubjectAltName extension is
called "rfc822Name" rather than "email address" because it can be used
to identify the subject without requiring a provisioned mailbox, as in
an XRI organization-based identifier:

   iauthority = [ iuserinfo " <at> " ] ihost [ ":" port ]

(Note that RFC 5280 says that an email address MUST be encoded as
rfc822Name, but it does not say that everything encoded as an rfc822Name
MUST be an email address.)

I'm not saying that pkinit-san should not be used, just that there is no
reason to remove or phase out rfc822name.

Dave

-----Original Message-----
From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
Michael StJohns
Sent: Thursday, May 13, 2010 10:20 PM
To: Henry B. Hotz; ietf-krb-wg <at> lists.anl.gov; pkix <at> ietf.org;
saag <at> ietf.org
Subject: 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.)

(Continue reading)


Gmane