I-D ACTION:draft-ietf-sacred-pkienrollinfo-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Securely Available Credentials Working Group of the IETF.

	Title		: PKI Enrollment Information
	Author(s)	: N. Kapidzic
	Filename	: draft-ietf-sacred-pkienrollinfo-00.txt
	Pages		: 
	Date		: 31-May-01
	
This document describes the format of PKI enrollment information,
which may be used by an RA/CA to enable automated end entity
certification. The PKI enrollment information contains PKI
parameters describing RA/CA certification policy requirements put on
end entities during their enrollment for a public key certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sacred-pkienrollinfo-00.txt

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-sacred-pkienrollinfo-00.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:

Re: I-D ACTION:draft-ietf-sacred-pkienrollinfo-00.txt

As agreed in Minneapolis, I have produced a draft describing a PSE part - 
PKI Enrollment Information.

Please give me any comments that you might have.
Note that I will not be able to respond to them in mid/end of June.

Regards,

Nada

At 06:48 AM 6/1/01 -0400, Internet-Drafts <at> ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Securely Available Credentials Working 
>Group of the IETF.
>
>         Title           : PKI Enrollment Information
>         Author(s)       : N. Kapidzic
>         Filename        : draft-ietf-sacred-pkienrollinfo-00.txt
>         Pages           :
>         Date            : 31-May-01
>
>This document describes the format of PKI enrollment information,
>which may be used by an RA/CA to enable automated end entity
>certification. The PKI enrollment information contains PKI
>parameters describing RA/CA certification policy requirements put on
>end entities during their enrollment for a public key certificate.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sacred-pkienrollinfo-00.txt

Re: I-D ACTION:draft-ietf-sacred-pkienrollinfo-00.txt

This I-D describes a method to store, transport, and utilize
enrollment information, and mentions the possibility of storing this
information in an end-user's PSE. This PSE could be a PKCS #15 token,
a PKCS #12 PFX PDU, or something similar.

It might be that this work item is outside the scope of SACRED's
charter, as it is not concerned with the access and transport of user
credentials themselves. However, it is an important topic to
solve in a scenario where the credentials are downloaded to an
environment without any prior knowledge about preferred RA's, etc.

The group's feedback on the draft, as well as whether the work
rightfully belongs here or should be pursued elsewhere (e.g. in the
PKCS context or in pkix) is welcome and solicited.

-- Magnus
Magnus Nystrom
RSA Security

few queries in understanding the SACRED framework

Re: few queries in understanding the SACRED framework

Hi Vikram,

Comments inline.

Best Regards,

Dale Gustafson
PKI/Security Consultant
Future Foundation, Inc.
+1 651-452-9033

Vikram Sareen wrote:

> hi all , i have just started reading the drafts wrt SACRED .following are the
> queries which i could not understand-
> query 1 -
>
>            protocol 1
> client ------------------> credential server.
> |                                  |
> |                                  | protocol 2
> |                                  v
> +-----------------------> credential store
>        protocol 3
>
> Client after authentication to credential
> server using protocol 1 .Client MAY / MAY NOT communicate(via credential
server)
> with credential store for their credential access using protocol 3.I think ,
> always the communication should be through the credential server , the details

> of the storage should be opaque to the client . Why so ?ie there should not
any
> protocol 3 used .Only protocol 1 and protocol 2 should be used.

SACRED is protocol 1, above.  The ASCII-art diagram is shown to explain the
larger context in which protocol 1 is operating.  Also to note that 2 and 3 are
out of scope for the framework document but related to 1.

Several list members have, at one time or another, expressed  interest in /
would like to ensure that clients can update (upload) secured credentials
directly to a credential store.  Others have indicated there may be a need to
download credentials directly from the credential store.  The inclusion of
protocol 3 in the diagram is merely to acknowledge that direct client exchanges
with a credential store are also possible.

A clarification note has been added to the next revision of the framework
document. Due out soon.

>  2. Can i have one or more credential ( like public key or mysecret message )
> inside two or more credential files associated tothe same user . or separate
> copy of it will be maintained inthe credential files.
>
Supported Credential formats such as PKCS-15 and PKCS-12 can be used to create
simple or  complex secured credentials containing one or more public/private key
pairs, x.509 ID certificates, attribute certificates, secret values, application
data, etc.  A typical credential used with a web browser today might contain a
key pair and the corresponding public key certificate. Security objects that go
together would be carried within a single credential. It is expected that each
user will have at least one server account which is accessed using a specific
"strong password" protocol such as PDM, SPEKE, or SRP3.  Each account may have
one or more different credentials associated with it.

> thanks , vikram< vikram <at> elock.co.in >

drafts coming

Folks,

There are two drafts on the way:

- draft-ietf-sacred-reqs-03.txt just fixes some typos pointed out
by Nada; we'll be forwarding this for IETF wide last call soon
as its out
- draft-ietf-sacred-protocol-beep-pdm-00.txt is our (somewhat 
delayed) first protocol attempting to meet those requirements

Stephen.

--

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell <at> baltimore.ie
Ireland                             http://www.baltimore.com

I-D ACTION:draft-ietf-sacred-reqs-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Securely Available Credentials Working Group of the IETF.

	Title		: Securely Available Credentials - Requirements
	Author(s)	: A. Arsenault, S. Farrell
	Filename	: draft-ietf-sacred-reqs-03.txt
	Pages		: 17
	Date		: 27-Jun-01
	
This document describes requirements to be placed on Securely
Available Credentials (SACRED) protocols.

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

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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sacred-reqs-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

I-D ACTION:draft-ietf-sacred-protocol-beep-pdm-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Securely Available Credentials Working Group of the IETF.

	Title		: Securely Available Credentials - The PDM Protocol
	Author(s)	: S. Farrell et al.
	Filename	: draft-ietf-sacred-protocol-beep-pdm-00.txt
	Pages		: 25
	Date		: 27-Jun-01
	
This document describes a PDM-based protocol for securely available
credentials.
Discussion of this draft is taking place on the SACRED mailing list
of the IETF SACRED working group (see http://www.imc.org/ietf-sacred
for subscription information).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-beep-pdm-00.txt

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-sacred-protocol-beep-pdm-00.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sacred-protocol-beep-pdm-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: I-D ACTION:draft-ietf-sacred-protocol-beep-pdm-00.txt

As a minor editorial nit, at the very bottom of page 3 you have a reference
to [PDM], but it is not listed in the References section.

-DMC
David Chizmadia
Senior Software Security Architect
Promia, Inc
dchizmadia <at> promia.com

----- Original Message -----
From: <Internet-Drafts <at> ietf.org>
To: <IETF-Announce: ;>
Cc: <ietf-sacred <at> imc.org>
Sent: Thursday, June 28, 2001 7:15 AM
Subject: I-D ACTION:draft-ietf-sacred-protocol-beep-pdm-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Securely Available Credentials Working
Group of the IETF.
>
> Title : Securely Available Credentials - The PDM Protocol
> Author(s) : S. Farrell et al.
> Filename : draft-ietf-sacred-protocol-beep-pdm-00.txt
> Pages : 25
> Date : 27-Jun-01
>
> This document describes a PDM-based protocol for securely available
> credentials.

Re: I-D ACTION:draft-ietf-sacred-protocol-beep-pdm-00.txt

David Chizmadia wrote:
> 
> As a minor editorial nit, at the very bottom of page 3 you have a reference
> to [PDM], but it is not listed in the References section.

Oops - should refer to draft-perlman-strong-cred-00.txt (which is
expired). OTOH, the details you need to implement are in this draft 
anyway, so not too big a deal.

Stephen.

--

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell <at> baltimore.ie
Ireland                             http://www.baltimore.com