Re: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs?

Hi,

Isn't the telephone solution an "online" solution? 

Antonio Maña.

> Peter - Tom - in addition to the really powerful set of verification rules
> that Tom came up with here (bravo TG!), there is another problem with making
> PKI acceptable to the real-world... and that problem is that this type of
> verification **mandates** online services and for any number of certificate
> based infrastructures.
> 
> The problem is that we as commercial users **would** really like to be able
> to use x509 PKI's offline, and that also can be done. To meet this need I
> would suggest that an OOB validation process using the Telephone (yes a
> standard Touch Tone POTS should work just fine)...
> 
> All you would have to do is to call the number and key in the finger print
> of the cert which the provider could tell you if its valid from them
> currently - or could the 'responder' issue a One-Time Token to satisfy some
> installer function with this certificate as part of OOB installer practice.
> 
> The way to do this is with a local OCSP or CRL responder applet that uses a
> soft-token as part of the verification process based on the certs
> fingerprint... or somesuch.
> 
> This simple addition to the technology base totally makes x509 certs capable
> of being used offline as well as the basis of a stand-alone process...
> 

A question about RFC-2560 (OCSP)

I-D ACTION:draft-ietf-pkix-scvp-12.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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-12.txt
	Pages		: 44
	Date		: 2003-6-30
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.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-scvp-12.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-pkix-scvp-12.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.

SCVP Questions

FW: A question about RFC-2560 (OCSP)

RE: SCVP Questions

I-D: multi-domain PKI Interoperability

Hi all,

As Ryu said in last IETF meeting, I am writing a Inetenet-Draft for
multi-domain PKI interoperability as a best current practice. This fruit is based on several
multi-domain PKI interoperability experiments and documents.
# This is an individual submission.

Here is an abstract of this I-D.

	Title		: Memorandum for multi-domain PKI Interoperability
	Author(s)	: M. Shimaoka
	Filename	: draft-shimaoka-multidomain-pki-00.txt
	Pages		: 16
	Date		: June 2003

===== Abstract =====
This memo is used to share the awareness necessary to deployment of
multi-domain PKI. Scope of this memo is to establish trust
relationship and interoperability between plural PKI domains.  Both
single-domain PKI and multi-domain PKI are established by the trust
relationships between Certification Authorities (CAs).  Typical and
primitive PKI models are specified as single-domain PKI.  Multi-
domain PKI established by plural single-domain PKI is categorized as
multi-trust point model and single-trust point model. Multi-trust
point model is based on trust list model, and single-trust point
model is based on cross-certification.
===== Abstract =====

The I-D has already published on IETF repository, but I revised several parts after that.
So, please refer the following URLs:
    http://www.jnsa.org/mpki/
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-00.txt

URL above invites you to our activity for multi-domain PKI
interoperability framework, as you know as what reported in past IETF
meetings.

If you are interested in this, please let me know.
Thanks in advance for any comments.

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8493 (ext.3551)
Fax: +81 422 45 0536
e-mail: shimaoka <at> secom.ne.jp

I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-01.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		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
	Pages		: 24
	Date		: 2003-7-2
	
This document defines two private X.509 v3 certificate extensions.
The first binds a list of IP address blocks, or prefixes, to the
subject of a certificate.  The second binds a list of Autonomous
System Identifiers to the subject of a certificate.  These extensions
may be used to convey the authorization of the subject to use the IP
addresses and Autonomous System identifiers contained in the
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.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-x509-ipaddr-as-extn-01.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-pkix-x509-ipaddr-as-extn-01.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.

IP addr: 01: use NULL instead of BOOLEAN for inherit

1.
Instead of a BOOLEAN type for which TRUE is required and FALSE is forbidden, simply use a NULL type.

Change the type of the inherit fields in IPAddressChoice (2.2.3) and ASIdentifierChoice (3.2.3) to the following:

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- Inherit from Issuer
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   ASIdentifierChoice ::= CHOICE {
      inherit             NULL, -- Inherit from Issuer
      asIdsOrRanges       SEQUENCE OF ASIdOrRange }

The associated text describing the inherit fields (2.2.3.5 & 3.2.3.3) can be simplified accordingly.

2.
It seems unnecessary to set these extensions to CRITICAL.  A relying party is not misled by ignoring these
extensions -- it simply learns nothing new about IP address and AS allocations.

Perhaps making it CRITICAL is supposed to indicate that the certificate is binding a public key to these
addresses instead of any other type of name so the subject (and subjectAltName) fields should be ignored. 
If this is the case, it may be better to formulate the extensions as OTHER-NAME types to be used in the
subjectAltName extension (in which case no other names needs to be included).

Perhaps making it CRITICAL is supposed to indicate that the certificate should only be used in, say, Secure
BGP and not for, say, secure e-mail.  If this is the case, defining a new purpose identifier for the
extendedKeyUsage extension may be more appropriate.

3.
Why does everything have to be sorted?  Does it really make it easy or faster for CAs and relying parties?

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Thursday, 3 July 2003 8:10 AM
Cc: ietf-pkix <at> imc.org
Subject: IP addr: 01: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

	Title		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
	Pages		: 24
	Date		: 2003-7-2
	
This document defines two private X.509 v3 certificate extensions.  The first binds a list of IP address
blocks, or prefixes, to the subject of a certificate.  The second binds a list of Autonomous System
Identifiers to the subject of a certificate.  These extensions may be used to convey the authorization of
the subject to use the IP addresses and Autonomous System identifiers contained in the extensions.

http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

RE: A question about RFC-2560 (OCSP)