Moin!
On 12.03.2009, at 01:10, Joe Baptista wrote:
You poor souls. The DNSSEC monster is vast and complex. So much
easier just to fix the problem instead of this endless gibberish.
It's so complex it's funny when you consider a simple solution like
DNSCURVE -http://dnscurve.org/ - and s
In message <558a39a60903110907i6edad88dye59293cbac951...@mail.gmail.com>, James
Seng writes:
> Agreed :)
>
> DNS is suppose to be 8-bit clean as according to RFC 1035.
No it is supposed to be nearly 8 bit clean. :-)
> But taken in context with that recommended section in RFC 1035, toge
You poor souls. The DNSSEC monster is vast and complex. So much easier
just to fix the problem instead of this endless gibberish. It's so complex
it's funny when you consider a simple solution like DNSCURVE -
http://dnscurve.org/ - and so much more secure. No man in the middle
issues.
Oh well
In message , Edward Lewis writes:
> At 8:19 +1100 3/11/09, Mark Andrews wrote:
> >In message , Edward Lewis writes:
>
> >> record involves less typing than a DNSKEY, I'd want to work with a DS
> >> record.
> >
> > Has anyone on this list ever typed in a DNSKEY or DS as a
> > trust ancho
Hi Mike,
Hi Alfred -
A better scheme for threshold signing for the root might be the
Shoup paper: "Practical Threshold Signatures", Victor Shoup (s...@zurich.ibm.com
), IBM Research Paper RZ3121, 4/30/99
The major difference between the two is that the Shamir system
(which you describe) requ
At 06:27 PM 3/11/2009, David McGrew wrote:
>Hi Mike,
>>Hi Alfred -
>>A better scheme for threshold signing for the root might be the
>>Shoup paper: "Practical Threshold Signatures", Victor Shoup
>>(s...@zurich.ibm.com ), IBM Research Paper RZ3121, 4/30/99
>>The major difference between the two i
Eric, et al,
I think it wise to move the discussion to dnsops and to remove from
idna-update, please, as has been suggested earlier. IDNAbis does not
deal with labels in a way that distinguishes TLDs from any other label
position in a domain name.
Vint
Vint Cerf
Google
1818 Library St
Sure.
Vint Cerf wrote:
Eric, et al,
I think it wise to move the discussion to dnsops and to remove from
idna-update, please, as has been suggested earlier. IDNAbis does not
deal with labels in a way that distinguishes TLDs from any other label
position in a domain name.
Vint
Vint Ce
internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Top Level Domain Name Specification
Author(s) : L. Liman
Filename: draft-liman-tld-names-00.txt
Pages : 9
> The DISCUSSION portion of 2.1 is explaining why relaxing RFC 952's
> restriction is safe. The safety flows exclusively from the premise
> that the highest-level component label of a domain name "will be
> alphabetic"; this guarantees that a syntactic check for an IP address
> will fail due to at
On Wed, Mar 11, 2009 at 11:44:54PM +0800, James Seng wrote:
>
>
> ::= [ [ ] ]
>
> ...
>
> ::= any one of the 52 alphabetic characters A through Z in
> upper case and a through z in lower case
Selective quoting can prove anything. Immediately prior to that
section, RFC 1035 says
Agreed :)
DNS is suppose to be 8-bit clean as according to RFC 1035. But taken
in context with that recommended section in RFC 1035, together with
RFC 952, many legacy implementation already assumed DNS must be LDH.
By the time RFC 2181 comes along, it was too late.
This was one of the reasons wh
On Mar 11, 2009, at 15:44, James Seng wrote:
::= [ [ ] ]
...
::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
Er, that's in Section 2.3.1: Preferred Name Syntax which says before
the BNF:
"The following syntax will result in fewer p
On Wed, Mar 11, 2009 at 11:36 PM, Andrew Sullivan wrote:
> On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote:
>> By the same logic, the whole IDN would be pointless because RFC 1035
>> restrict labels to "alphabetic letter" only.
>
> I'd like the reference to where 1035 says that, please.
On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote:
> By the same logic, the whole IDN would be pointless because RFC 1035
> restrict labels to "alphabetic letter" only.
I'd like the reference to where 1035 says that, please. In
particular, the following passage in §3.1 of RFC 1035 seems
On Wed, Mar 11, 2009 at 10:56:10PM +0800,
James Seng wrote
a message of 4 lines which said:
> By the same logic, the whole IDN would be pointless because RFC
> 1035restrict labels to "alphabetic letter" only.
I assume you're playing the devil's advocate? Because I believe that
all dnsop membe
At 8:19 +1100 3/11/09, Mark Andrews wrote:
In message , Edward Lewis writes:
record involves less typing than a DNSKEY, I'd want to work with a DS
record.
Has anyone on this list ever typed in a DNSKEY or DS as a
trust anchor? I would presume that most (99.%) people
By the same logic, the whole IDN would be pointless because RFC 1035
restrict labels to "alphabetic letter" only.
IDNA transform IDN labels into punycode so that it become transparent
to the resolvers who made those assumption.
-James Seng
> I think this is what's up for dispute. If people have
On 11 mar 2009, at 15.08, Matt Larson wrote:
On Sat, 07 Mar 2009, Patrik Fltstrm wrote:
Will there also be a problem with digits within a label? "Probably
not", but I rather see a generic good definition of "the gray area"
and who is responsible for arguing (I an not saying proving here)
whethe
On Sat, 07 Mar 2009, Patrik Fltstrm wrote:
> Will there also be a problem with digits within a label? "Probably
> not", but I rather see a generic good definition of "the gray area"
> and who is responsible for arguing (I an not saying proving here)
> whether something is "ok to delegate" or not, a
On Tue, Mar 10, 2009 at 10:27:21AM +0100, Stephane Bortzmeyer wrote:
> recollection of one specific person. The "alphabetic-only" rule in RFC
> 1123 is just a side note, never detailed, and presented as a fact
> (which it was at this time), not as a mandatory restriction.
I don't know whether I a
> I have to agree with that, except that you probably need more 9's.
Oh, I don't know about that.
Three 9's should be more than enough accuracy to describe the set of
people who've ever put a DS or DNSKEY record in their zone files ;-)
Ray
___
DNSOP
I've got one. I modified an implementation of Shoup by Steve Weis which does
raw RSA sigs to do PKCS1-v1.5 RSA signatures and from those to do DNSSEC
signing. It allows the generation and wrapping of shares under remotely
generated public keys - e.g. share holder public keys. When signatures
23 matches
Mail list logo
