headers
Kurt Stammberger | 2 Dec 1996 03:38
Picon

ANNOUNCEMENT: 1997 RSA Data Security Conference

28-31 January, 1997
NOB HILL, SAN FRANCISCO

1997 marks RSA's fifteenth anniversary and our sixth annual conference.
Two days of general sessions and two days of classes will provide over
100 different  classes to choose from, with separate tracks for
mathematicians and cryptographers, developers, industry analysts and
business people.

We invite you to join us.  Find out more information, view the class
syllabi and register online at http://www.rsa.com

Thanks

Kurt Stammberger
RSADSI
>
Permalink | Reply | 0 comments |
headers
Petra Gloeckner | 2 Dec 1996 10:32
Picon

Re: Displaying an X.509 certificate

pgut001 <at> cs.auckland.ac.nz wrote:
> 
> >Does anyone know where I can find a program that, given an X.509 certificate,
> >will display its fields and their values in some human-readable form?
> 

We have just released our new version SECUDE-5.0 beta for several plattforms !
Have a look at
	
		http://www/secude

to register and download the security toolkit. It also contains a SECUDE command 
shell which provides the functionality for example to dump or show ASN.1 code.
		
Best regards,
Petra Gloeckner
Permalink | Reply | 0 comments |
headers
Petra Gloeckner | 2 Dec 1996 14:15
Picon

Re: Displaying an X.509 certificate

Ingmar Camphausen wrote:
> 
> Hallo,
> 
> on Mon, 02 Dec 1996, Petra Gloeckner <gloeckne <at> darmstadt.gmd.de> wrote:
> 
> > We have just released our new version SECUDE-5.0 beta for several
> > plattforms ! Have a look at
> >
> > http://www/secude
>          ~~~~~~~~~~
> 
> Das ist etwas knapp geraten, oder? ;-)
> 
> Gruß,
>         Ingmar
> 

I'm sorry. That was the address I'm using internally. The correct address is:

		http://www.darmstadt.gmd.de/secude

Regards, Petra
Permalink | Reply | 7 comments |
headers
Yoshito | 3 Dec 1996 06:03
Picon

(unknown)

subscribe
Permalink | Reply | 0 comments |
headers
Edward Russell | 3 Dec 1996 15:29

Conversion of PEM certificates?

Is it possible to convert PEM formatted certificates from/to PKCS formatted certificates?

If you go to http://cms.cost.se/cgi-bin/iceuca you can fetch someone's certificate in PEM
format.

If you go to http://cms.cost.se/cgi-bin/icepca?-c you can fetch a CA's CRL in PEM format.

These sites are part of the ICE-TEL project in europe.  If I would like my product to interoperate
with these certificates, I would need to import and export that format.

If I converted them and imported them to PKCS format, could I then do authentication of a remote user 
if I had imported his cert and CA chain and trusted his root.

Or am I off-base and these PEM certs are completely incompatible with the type of certs from
Verisign, etc.

Edward Russell
erussell <at> ftp.com
Permalink | Reply | 1 comment |
headers
David Rudder | 3 Dec 1996 18:33

Re: Conversion of PEM certificates?

On Tue, 3 Dec 1996, Edward Russell wrote:

> Is it possible to convert PEM formatted certificates from/to PKCS 
> formatted certificates? 

Actually, for the most part, they are the same thing.  PKCS uses the 
Extended Certificates, but they are backwards compatible.

> 
> If you go to http://cms.cost.se/cgi-bin/iceuca you can fetch someone's 
> certificate in PEM 
> format.

Okay, done that.  Then, I clipped out the section under "Originator 
Certificate", base64decoded it, and was left with a valid x509 cert.
I'm clipping a bunch of stuff here because I can answer all your 
questions here.  They are the same certificates.  X509 works well, so 
S/MIME (PKCS-7) saw no reason to change them, above adding a couple 
extensions.  The X509 certs in PKCS-6 is the Extended cert, so according 
the the PKCS spec, the PEM certs are valid.  I'd check out the PEM RFC's 
(1421 through 1424) for how to split up a PEM file, but it's all just 
messing with text.

			-Dave
		   drig <at> magicweb.com

I got a coffee mug from Cray Research when they moved out.  Now I can 
drink my coffee while doing 63 other, unrelated tasks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Polk | 3 Dec 1996 20:58

NIST PKI Specs


NIST has just released the "Minimum Interoperability Specifications for
PKI Components (draft Version 1)" for a 90 day review period.  NIST
developed this document with the assistance of ten CRADA partners -
AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorols, Nortel, Spyrus,
and Verisign. This specification is intended to provide the basis for
interoperable PKI components (CAs, ORAs, and clients) from different vendors.

This specification addresses certificate generation, renewal, and
revocation. It includes a certificate and CRL profile, and defines
transactions between PKI components for requesting, renewing, revoking,
and retrieving certificates.

Version 1 is focused on interoperability for a large scale PKI that
issues, revokes and manages digital signature public key certificates.
This specification does not preclude support for key management
certificates; there is simply no direct support.  (A sound digital
signature PKI should provide the basis for issuing any kind of
certificate. This specification could be enhanced to address key
managment in a later version.)

The URL for this document is

	http://csrc.nist.gov/pki/welcome.html#mispc

The document is available in Microsoft Word and PostScript.

It is NIST's goal that the MISPC align closely with the PKIX documents.
The functionality of the MISPC is akin to Parts 1 and 3, and shares many
features, but it is not a proper subset at the moment.  Close alignment
(Continue reading)

Permalink | Reply | 0 comments |
headers
carlisle (c.m.) adams | 4 Dec 1996 18:33
Picon

New PKIX-3 Draft...

Hi,

Some of you may have noticed that a new draft of PKIX Part-III (Certificate
Management Protocols) has been submitted.  The changes from the previous
version are outlined on page 1 of the new draft, so I won't go over them
here.  However, it would be helpful if people attending the San Jose meeting
have a chance to look over the draft by the time of the meeting (that way,
discussion is likely to be more focused and fruitful).

Stephen did a lot of good work on trying to profile a number of the management 
protocols (i.e., say exactly what fields were mandatory and what they should
contain, etc.).  Unfortunately, however, I was unable to get the tables he
sent me into a readable text format so they ended up being excluded from this
draft.  Such tables will certainly be included in the document at some point
but there wasn't enough time to get them in this document AND meet the IETF
deadline for submissions.

What I am doing, therefore, is including a postscript version of the profile
in this message.  Again, it would be helpful if people take a look at these
tables in time for discussion in San Jose.  Since the purpose of the profile
is to specify exactly what every PKIX-3-compliant implementation must support,
we all need to look carefully at this and come to some sort of agreement
(hopefully in San Jose!).  What is included in these tables is our first pass
at such a profile; there is certainly still lots of room for input...

Carlisle.
Attachment: application/octet-stream, 113 KiB
Permalink | Reply | 501 comments |
headers
Fred Ou | 4 Dec 1996 20:37
Picon
Favicon

Certificate and CRL chains

   Does anyone know where I can find chains of certificates and CRLs
for certificate validation testing ?

Thanks

-Fred
Permalink | Reply | 1 comment |
headers
Bob Briscoe | 5 Dec 1996 12:57
Picon

Security hole: Digital Signing + Downloadable fonts

Digital Signature Working Group,

I'm not subscribed to either of the lists I have posted this to, so please
CC: any replies to me explicitly.

Should this be posted anywhere else too?

It occurred to me (at the recent W3C Internationalisation symposium) that a
digital signature signs the characters in a message, however, the user
believes they are signing what they see, which is viewed through the glyphs
with which the font represents the characters.

Downloadable fonts have been added to the Web infrastructure, particularly
to support internationalisation. Indeed it is very common and now enabled
for, say an E. Asian document to specify downloading a sub-set of a Latin
font to display a Latin fragment (e.g. a quote).

Same technique could be used to specify that a message of any charset
should download a font for the numeric digits with, say, all the digits
mapped to glyphs looking like either <SPACE> 0, 1, 2 or 3 .

You sign an order that appears to be for UKP  112.30, but you have actually
signed a message that commits you to pay UKP96324.75

In practice you might successfully argue that because the document you
signed included a downloadable font, your signature is worthless. However,
where downloadable fonts are necessary this makes any signing worthless.

Same principle applies to any linked in resource "within" a signed message
(e.g. picture of item ordered which is what you would expect to get under
(Continue reading)

Permalink | Reply | 0 comments |

Gmane