DR 314 - New Defect report and DTC on Name Constraints

RFC for Certificate Store

Hello,

On the PKIX page it is declared that on Jun 2005 Certificate Store is
approved as Informational RFC. Unfortunately I couldn't find any documents
related to this RFC. Is it going to be released soon? Or better can
someone post a copy of it? We plan to implement a certificate store and I
would prefer to read a related RFC before starting our design.

Thanks.

Ersin Gulacti

Re: RFC for Certificate Store

Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

Please take a look at draft-ietf-dnsext-rfc2538bis-08.  It is on the agenda 
for the IESG telechat this Thursday.  If anyone has any concerns, please 
notify me by Wednesday.

Russ

Oops Re: Hash Workshop Program Ready and Posted

Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

        Russ:

        Are there any guidelines for CRL owner names, since they're 
covered in the draft although DNS distribution points aren't detailed in 
RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if 
any sequence member of the distribution point name is a domain name (not a 
URI), that should be used.  Also (and lower in precedence), if any 
sequence member of the distribution point name is an RFC 822 address, its 
standard translation should be used.  I doubt if URI's will work without 
conflicts.
        I don't know if these count as "concerns". 

                Tom Gindin
P.S.    The opinions above are mine, and not necessarily those of my 
employer.

RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

While storing certificates in the DNS makes sense in some applications I
would be concerned if this proposal was intended to make DNS the
recommended storage mechanism.

The problem is that the original DNS protocol has a hard wired limit of
512 bytes for a UDP packet after which it falls back to TCPIP. This
limitation has been eased in part by the DNSEXT work but the maximum UDP
packet size is still effectively limited by the Ethernet MTA in most
real world applications. If the application falls back to TCP it is much
simpler, cleaner and more effective to simply use HTTP which is designed
as a TCPIP protocol.

In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
practice is very different. The DNSEXT group has a habbit of faith based
deployment, i.e. if they declare the protocol deployed it is deployed.

There are certainly cases where storing a cert in the DNS is useful but
it is important that the limitations of this approach be understood and
that it does not become another architectural fiat from the DNSEXT
group.

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Tom Gindin
> Sent: Wednesday, October 12, 2005 6:39 PM
> To: Russ Housley
> Cc: ietf-pkix <at> imc.org; simon <at> josefsson.org
> Subject: Re: Storing Certificates in the DNS 
> (draft-ietf-dnsext-rfc2538bis-08)
> 
> 
>         Russ:
> 
>         Are there any guidelines for CRL owner names, since 
> they're covered in the draft although DNS distribution points 
> aren't detailed in RFC 3280?  If there aren't any, IMHO a 
> reasonable rule would be that if any sequence member of the 
> distribution point name is a domain name (not a URI), that 
> should be used.  Also (and lower in precedence), if any 
> sequence member of the distribution point name is an RFC 822 
> address, its standard translation should be used.  I doubt if 
> URI's will work without conflicts.
>         I don't know if these count as "concerns". 
> 
>                 Tom Gindin
> P.S.    The opinions above are mine, and not necessarily those of my 
> employer.
> 
> 
> 

RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

phb - NO ONE in their right mind would use DNS as the only repository for storing certificates and this
initiative and the conversations in re of this idea are demonstrative of how little PKIX has a grip on
reality IMHO. Clearly storing certs for DNS in DNS and possibly in some limited scope might work, but the
reality is why bother - the issue is in the trust and use models - something which this group refuses to do...

T.
 -------------- Original message ----------------------
From: "Hallam-Baker, Phillip" <pbaker <at> verisign.com>
> 
> While storing certificates in the DNS makes sense in some applications I
> would be concerned if this proposal was intended to make DNS the
> recommended storage mechanism.
> 
> The problem is that the original DNS protocol has a hard wired limit of
> 512 bytes for a UDP packet after which it falls back to TCPIP. This
> limitation has been eased in part by the DNSEXT work but the maximum UDP
> packet size is still effectively limited by the Ethernet MTA in most
> real world applications. If the application falls back to TCP it is much
> simpler, cleaner and more effective to simply use HTTP which is designed
> as a TCPIP protocol.
> 
> In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
> practice is very different. The DNSEXT group has a habbit of faith based
> deployment, i.e. if they declare the protocol deployed it is deployed.
> 
> There are certainly cases where storing a cert in the DNS is useful but
> it is important that the limitations of this approach be understood and
> that it does not become another architectural fiat from the DNSEXT
> group.
>  
> 
> > -----Original Message-----
> > From: owner-ietf-pkix <at> mail.imc.org 
> > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Tom Gindin
> > Sent: Wednesday, October 12, 2005 6:39 PM
> > To: Russ Housley
> > Cc: ietf-pkix <at> imc.org; simon <at> josefsson.org
> > Subject: Re: Storing Certificates in the DNS 
> > (draft-ietf-dnsext-rfc2538bis-08)
> > 
> > 
> >         Russ:
> > 
> >         Are there any guidelines for CRL owner names, since 
> > they're covered in the draft although DNS distribution points 
> > aren't detailed in RFC 3280?  If there aren't any, IMHO a 
> > reasonable rule would be that if any sequence member of the 
> > distribution point name is a domain name (not a URI), that 
> > should be used.  Also (and lower in precedence), if any 
> > sequence member of the distribution point name is an RFC 822 
> > address, its standard translation should be used.  I doubt if 
> > URI's will work without conflicts.
> >         I don't know if these count as "concerns". 
> > 
> >                 Tom Gindin
> > P.S.    The opinions above are mine, and not necessarily those of my 
> > employer.
> > 
> > 
> > 
> 

Re: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

Tom:

Thanks for the review.  I do not think that this kind of guidance belongs 
in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis.

Russ

At 06:38 PM 10/12/2005, Tom Gindin wrote:

>         Russ:
>
>         Are there any guidelines for CRL owner names, since they're
>covered in the draft although DNS distribution points aren't detailed in
>RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if
>any sequence member of the distribution point name is a domain name (not a
>URI), that should be used.  Also (and lower in precedence), if any
>sequence member of the distribution point name is an RFC 822 address, its
>standard translation should be used.  I doubt if URI's will work without
>conflicts.
>         I don't know if these count as "concerns".
>
>                 Tom Gindin
>P.S.    The opinions above are mine, and not necessarily those of my
>employer.

RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)

Todd:

This is not a PKIX work product, so you comments are directed at the wrong 
audience.

Russ

At 10:43 AM 10/13/2005, todd.glassey <at> att.net wrote:
>phb - NO ONE in their right mind would use DNS as the only repository for 
>storing certificates and this initiative and the conversations in re of 
>this idea are demonstrative of how little PKIX has a grip on reality IMHO. 
>Clearly storing certs for DNS in DNS and possibly in some limited scope 
>might work, but the reality is why bother - the issue is in the trust and 
>use models - something which this group refuses to do...
>
>T.
>  -------------- Original message ----------------------
>From: "Hallam-Baker, Phillip" <pbaker <at> verisign.com>
> >
> > While storing certificates in the DNS makes sense in some applications I
> > would be concerned if this proposal was intended to make DNS the
> > recommended storage mechanism.
> >
> > The problem is that the original DNS protocol has a hard wired limit of
> > 512 bytes for a UDP packet after which it falls back to TCPIP. This
> > limitation has been eased in part by the DNSEXT work but the maximum UDP
> > packet size is still effectively limited by the Ethernet MTA in most
> > real world applications. If the application falls back to TCP it is much
> > simpler, cleaner and more effective to simply use HTTP which is designed
> > as a TCPIP protocol.
> >
> > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
> > practice is very different. The DNSEXT group has a habbit of faith based
> > deployment, i.e. if they declare the protocol deployed it is deployed.
> >
> > There are certainly cases where storing a cert in the DNS is useful but
> > it is important that the limitations of this approach be understood and
> > that it does not become another architectural fiat from the DNSEXT
> > group.
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-pkix <at> mail.imc.org
> > > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Tom Gindin
> > > Sent: Wednesday, October 12, 2005 6:39 PM
> > > To: Russ Housley
> > > Cc: ietf-pkix <at> imc.org; simon <at> josefsson.org
> > > Subject: Re: Storing Certificates in the DNS
> > > (draft-ietf-dnsext-rfc2538bis-08)
> > >
> > >
> > >         Russ:
> > >
> > >         Are there any guidelines for CRL owner names, since
> > > they're covered in the draft although DNS distribution points
> > > aren't detailed in RFC 3280?  If there aren't any, IMHO a
> > > reasonable rule would be that if any sequence member of the
> > > distribution point name is a domain name (not a URI), that
> > > should be used.  Also (and lower in precedence), if any
> > > sequence member of the distribution point name is an RFC 822
> > > address, its standard translation should be used.  I doubt if
> > > URI's will work without conflicts.
> > >         I don't know if these count as "concerns".
> > >
> > >                 Tom Gindin
> > > P.S.    The opinions above are mine, and not necessarily those of my
> > > employer.
> > >
> > >
> > >
> >