headers
Stephen Kent | 2 Jan 2004 22:47
Picon

Re: IDPKC


At 11:21 +0100 12/30/03, Anders Rundgren wrote:
>Steve,
>That was a truly brilliant analysis of IDPKC!

Thanks, but I had done this before when people first asked me about 
my views of the technology, so all I had to do was reconstruct the 
verbal analysis I did previously.

>It would however be nice to get a similarly educated analysis of
>PKI in the form you have more faith in.  Like how you actually can
>build shrink-wrapped, reliable, and user-friendly RP software based
>on standards having the following characteristics:

You have a very focused idea of what is the goal of PKI, not one that 
is universally shared. Moreover, I addressed limitations of IDPKC in 
a broad context, but the analysis you want will take a lot more 
effort. Unfortunately, the world is full of problems that require 
considerable effort to address. I work only on those for which I have 
clients willing to pay. Nobody is paying me to address precisely the 
problem you stated. So, I will not agree to take on the task.
>	<SNIP>
>
>Hoping for a better 2004 with more mutual understanding

One can always hope ...

Steve
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kaliski, Burt | 6 Jan 2004 22:24

RE: WG Last Call: Additional Algorithms for RSA cryptography


A few comments:

1. The sha224WithRSAEncryption OID has been defined. Please update the
definition on p. 13 to the following:

   sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 } 

2. Some typos:

* p. 6, definition of sha224Identifier: "id-sha256" --> "id-sha224"
* p. 11, Sec. 5, para 1: "SHA_224" --> "SHA-224"
* p. 12, para 3: "SHA-2224" --> "SHA-224"
* p. 18, ref. [SHA224]: "-00.txt" --> "-02.txt"

3. The [SHA224] document will not be stable until NIST finalizes its
definition of SHA-224, which is currently out for public comment.

-- Burt

-----Original Message-----
From: wpolk <at> nist.gov [mailto:wpolk <at> nist.gov]
Sent: Tuesday, December 16, 2003 2:31 PM
To: ietf-pkix <at> imc.org
Cc: 'Stephen Kent'; jimsch <at> exmsft.com; Jim Schaad; Russ Housley;
Kaliski, Burt
Subject: WG Last Call: Additional Algorithms for RSA cryptography

This message initiates working group Last Call for "Additional Algorithms
and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 7 Jan 2004 17:36

RE: WG Last Call: Additional Algorithms for RSA cryptography


Burt:

This is correct.  I have been coordinating with Tim Polk, and the document 
can proceed as soon as we are sure that the algorithm will not change.

Russ

At 04:24 PM 1/6/2004 -0500, Kaliski, Burt wrote:
>3. The [SHA224] document will not be stable until NIST finalizes its
>definition of SHA-224, which is currently out for public comment.
Permalink | Reply | 3 comments |
headers
The IESG | 8 Jan 2004 23:05
Picon
Favicon

Protocol Action: 'Internet X.509 Public Key Infrastructure Proxy Certificate Profile' to Proposed Standard


The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Proxy Certificate Profile '
   <draft-ietf-pkix-proxy-10.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document specifies the certificate profile for Proxy
  Certificates, based on X.509v3 certificate profile in RFC 3280.  The
  term Proxy Certificate is used to describe a certificate that is
  derived from, and signed by, a normal X.509v3 End Entity Public Key
  Certificate or by another Proxy Certificate.

Working Group Summary

  The PKIX Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.

RFC Editor Note

  On page 17, please correct the forward reference.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 8 Jan 2004 23:27

Fwd: Alert: certs with RSA public key exponent of 1


This will also be of interest to this list ...

Russ

>Date: Thu, 8 Jan 2004 14:08:34 -0800
>From: "Nelson Bolyard" <misterssl <at> aol.com>
>Subject: Alert: certs with RSA public key exponent of 1
>To: "IETF Transport Layer Security WG" <ietf-tls <at> lists.certicom.com>
>
>Some time ago, mozilla was modified to detect and reject RSA keys with
>public exponents equal to 1.  Presumably, the readers of this list
>need no explanation of the implications of such keys.
>
>Now, mozilla users are encountering web sites whose certs have such keys.
>At least one public CA has apparently issued one or more such certs.
>
>I'm reporting this here to alert the readers of this list who may wish
>to ensure that their implementations detect such keys, and to suggest
>that perhaps the TLS RFC should explicitly forbid the use of any public
>keys (RSA or otherwise) that facilitate such weak encryption and/or
>authentication by requiring implentations to detect and reject them.
>
>Nelson    (not speaking for my employer)
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 9 Jan 2004 22:28
Picon
Favicon

I-D ACTION:draft-ietf-pkix-certpathbuild-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure:       Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-03.txt
	Pages		: 74
	Date		: 2004-1-9
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certpathbuild-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masaki SHIMAOKA | 14 Jan 2004 11:51
Picon

Re: Revised I-D: Memorandum for multi-domain PKI Interoperability


All,

As I presented in 57th IETF meeting, I propose to make a consensus for
multi-domain PKI interoperability. To consider such consensus, I was
writing this I-D, and I finished it.
Please review the I-D and let me know your opinion.

You can obtain the I-D from:
http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.txt

Original presentation:
http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

Working Page:
http://www.jnsa.org/mpki/#id

At 56th IETF, I discussed with Tim how to standardize this I-D. As
result, PKIX WG seemed difficult to holding the ID as new WG draft. So I
am proposing this as personal draft.

shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
(Continue reading)

Permalink | Reply | 17 comments |
headers
Anders Rundgren | 14 Jan 2004 14:48
Picon

Re: Revised I-D: Memorandum for multi-domain PKI Interoperability


Shimaoka-San,

I enjoy "playing" with different approaches and I believe that there
is an entirely different approach that this and many existing PKI
architectures will have to compete with, and that is that relying
parties deploy a key-validation service using XKMS.  This eliminates
the need for CA cooperation, cross-certification etc.  Cross-
certification is probably not very realistic except for in-house
CAs used by governments as commercial entities, have no
reason to vouch for each others issuances.

Another scheme which I even more faith in, is that organizations
only "talk" to each other at the "organization-entity" level,
which reduces the PKI interoperability question by magnitudes.
Not to mention costs.  That is, each organizational unit (legal unit etc)
typically purchases a TTP-issued "business unit certificate", mounts
that inside a secure server, and that's it!

Finally I would like to mention how the Swedish e-government
are tackling PKI interoperability for their C2G activities:
As the outsourced CAs all have different business models, as
well as different signature solutions they are building a "PKI-central"
that does everything from signature validation to signature GUI/web
stuff.  Yucky?  It probably cant get worse.  Or maybe it can...
 I recently saw that the Austrian "Bürgercarte" requires that
each user have a local web-server(!) in order to sign due
to the fact that browsers have no such ability.

I believe your scheme does not address the business model issue,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Hesse | 14 Jan 2004 21:59

New version of GUIdumpASN available


All,

Since I know a number of you use the tool, I figured I'd let you know that a
new version of GUIdumpASN is available.  GUIdumpASN is a free Windows-ified
version of Peter Gutmann's dumpasn1.c program, and it allows
view/print/saving of human readable ASN.1.

The new version supports the use of external .CFG files.   Additional
changes include a send-to icon that works, and it will now remember its
settings when you call it via drag and drop.  Since we've changed installer
programs, you should uninstall your old version, and download the new one
from
http://www.geminisecurity.com/guidumpasn.html 

Enjoy.  Comments are always welcome.

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    pmhesse <at> geminisecurity.com     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius
Permalink | Reply | 0 comments |
headers
Stephen Kent | 14 Jan 2004 22:47
Picon

Re: Revised I-D: Memorandum for multi-domain PKI Interoperability


Anders,

As usual, your comments are provocative. My only comments are:

	- do not assume that a TTP CA is needed for ANY 
intra-enterprise PKI; it is not really essential

	- XKMS is not a panacea; it just moves the problems to a 
different place in the system. recent bad experiences with the 
VeriSign crl service should be a lesson about what can happen from 
undue reliance on a single, central CA

	- do not assume that whatever banks choose to do re PKI is 
the right answer for anyone other than banks

Steve
Permalink | Reply | 0 comments |

Gmane