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

[Massimiliano Pala <[e-mail]>]

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


Tom Gindin wrote:
>         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


-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 063                        Work Phone: [phone]
--o------------------------------------------------------------------------