[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)
Yes Russ it is - there is so little difference between these WG's and their products, that its almost silly. Any use through the IETF of one groups' standards needs to be codified under the 'no repeating work or work related to another standard effort' rule that the IETF's bylaws clearly define.
So - what can I say - this is yet another instance where someone wants to enable an enduser use model without bothering to actually document how that end-use model will work and under what constraints it will work -
as to the separation issues between the WG's - when there were no standards, and there were no processes already in place - the IETF's shotgun approach was possibly warranted - but not anymore.
And since this will likely really tee you off as a response, its my final one on the subject except to say that for some uses there are really good justifications for looking up certs through DNS services - just like there is with the e.64 phone numbers in DNS. Its just that DNS as a whole is not what it could be and well - what can I say.
todd
-------------- Original message ----------------------
From: Russ Housley <housley@xxxxxxxxxxxx>
> 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@xxxxxxx 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@xxxxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxx
> > > > [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Tom Gindin
> > > > Sent: Wednesday, October 12, 2005 6:39 PM
> > > > To: Russ Housley
> > > > Cc: ietf-pkix@xxxxxxx; simon@xxxxxxxxxxxxx
> > > > 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.
> > > >
> > > >
> > > >
> > >
>