Subject: I-D ACTION:draft-ietf-pkix-prqp-00.txt

From: [email-masked]
Date: Fri, 18 Jul 2008 13:45:02 -0700 (PDT)

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		: PKI Resource Query Protocol (PRQP)
	Author(s)	: M. Pala
	Filename	: draft-ietf-pkix-prqp-00.txt
	Pages		: 24
	Date		: 2008-7-2
	
 One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tom Gindin <[email-masked]>
Date: Mon, 21 Jul 2008 19:33:05 -0400

Section 2.1 of this draft gives an overview of existing solutions 
and their limitations.  It does not appear that any consideration was 
given to adding a new AccessDescription (to the SIA and/or AIA extensions) 
for SRV record access.  The argument against the use of SRV records given 
in 2.1.2 is that there is not generally a fixed mapping between the 
certificate and a DNS space, which does not apply to a DNSName within an 
AIA or SIA extension.

                Tom Gindin

[email-masked] 
Sent by: [email-masked]
07/18/2008 04:45 PM

To
[email-masked]
cc
[email-masked]
Subject
I-D ACTION:draft-ietf-pkix-prqp-00.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                           : PKI Resource Query 
Protocol (PRQP)
                 Author(s)               : M. Pala
                 Filename                : draft-ietf-pkix-prqp-00.txt
                 Pages                           : 24
                 Date                            : 2008-7-2

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-ietf-pkix-prqp-00.txt

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 29 Jul 2008 15:48:11 +0100

Hi Tom,

I do not understand how this actually applies. The dnsName is just one type
of GeneralNames (if I do remember correctly), therefore considerations about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the certificate
so that we know which DNS domain we shall query for DNS SRV records related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can update
the document properly.

Later,
Max

---

From: Tom Gindin <[email-masked]>
Date: Tue, 29 Jul 2008 19:36:41 -0400

Max:

        The DNS Name has to go into a specific extension to be used.  I 
don't think that putting a DNS Name into IssuerAltName means "look here 
for SRV records associated with PKI management", and its most common 
meaning in SubjectAltName is "expect to see this certificate when you 
connect to this DNS Name", but an AccessDescription could easily be 
assigned to mean that it's a pointer to SRV records.  There are General 
Names associated with AKI, CRL Distribution Point, and Name Constraint as 
well, but they clearly are not appropriate for such purposes.
        An argument that "DNS is not the right mechanism for this, and 
it's worth a new protocol to avoid using DNS" is different than the one 
you made in the first version of your draft.  It looks to me like the 
argument against DNS usage would rely heavily on the perception that DNS 
isn't secure enough, especially for revocation information.  Is that 
really a strong enough reason to expect typical relying parties to 
implement a new client protocol?

                Tom Gindin

Massimiliano Pala <[email-masked]> 
07/29/2008 10:48 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
[email-masked]
Subject
Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt

Hi Tom,

I do not understand how this actually applies. The dnsName is just one 
type
of GeneralNames (if I do remember correctly), therefore considerations 
about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the 
certificate
so that we know which DNS domain we shall query for DNS SRV records 
related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do 
have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., 
within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and 
server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier 
to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can 
update
the document properly.

Later,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 30 Jul 2008 10:10:04 +0100

Hi Tom,

In section 2.1.1. only a brief descriptions we list only some of the reasons
for adopting a PRQP and it is not intended to be exhaustive. The argument
in 2.1.2. still holds, in the sense that currently there is no mapping in
the certificates between DNS domains and certificates - as you pointed out
there is no field that could carry such information.

I will probably need to add some more deep considerations in this section
thus listing the benefits coming from the usage of a dynamic protocol. The
intent of defining a protocol for PKI resource query that is transport
independent allows for more flexibility than using a specific service like
DNS. I would not say that the DNS is not secure enough - it could be possible
to distribute signed records via DNS; it can be difficult from a management
point of view: it is my opinion that integrating that type of support in
current DNS is harder and takes longer than defining a new protocol which
is easy and can be implemented really fast.

Last, but not least, at the last IETF my presentation on extending PRQP to
a Peer-to-peer environment that would allow the implementation of a real
service discovery system for PKIs strongly suggest that the overhead introduced
by the definition of a specific protocol is rewarded with a wide range of
possibilities for PKI management and would allow for better usability of PKIs.
See section A.2 of the I-D for more information.

These are just some of the reasons I can come up with. The current status
of the draft is, AFAIK, on experimental track just because of this: we need
to know if this protocol would allow for an efficient and interoperable
method for PKI resource discovery or not. So far the DNS has not provided
such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV
record to locate a local RQA (if available), though.

As I am going to explain in my presentation later today, we are moving
forward from this point of view as an RQA will be setup for all of the
CAs within the TACAR repository (http://www.tacar.org). When we will have
a deployed environment and, eventually, support for client applications
we will be able to evaluate more what the results are and if it will be
worth to move the I-D to standard track or not.

I will a concise version of these considerations to the 2.1.2 section of
the I-D in order to make it more clear why we propose the usage of PRQP
instead of DNS SRV records - although I do not want this section to become
too long.

Thanks for the comments and, if you have more, please let me know :D

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 31 Jul 2008 01:55:13 +0200

I'm less concerned about details regarding this protocol than how to use the information it provides.
Security GUI have shown to be very difficult to design since they either [try to] hide the gory stuff or assumes a level of
education that isn't generally available.  I wouldn't be surprised if Microsoft with their CardSpace scheme will [eventually] make
two-factor authentication as easy to use as credit cards; it even looks like credit cards!

Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 30, 2008 11:10
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt

Hi Tom,

Later,
Max

-- 

Best Regards,

Massimiliano Pala