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

[Tom Gindin <[e-mail]>]

        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 <[e-mail]> 
07/29/2008 10:48 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
[e-mail]
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


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