Subject: [dnsop] comments on draft...epp-secdns-05

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Nov 2004 14:50:31 -0500

Based on reading (not implementing/operating) the EPP DNS Security 
Extensions Mapping:

#1

Section 2.1 states that a "server operator SHOULD NOT sign any key 
provided".  While I admire the intent, I don't think it's appropriate 
to have this level of detail in the document.

o This statement singles out "keys" and not DS hashes.

o In some operational environments, this objective can be "covered" 
by existing business relationships.  In the same, there may be no 
allowance for direct contact between the registry and the registrant 
(DNS operator).

#2

Section 3.1.2, top of page 7, the secDNS:vInterval description is a 
bit unclear.  I and another person came to different interpretations, 
talking with Scott, there was a third interpretation.

o My (unspecified) interpretation was the "most wrong."

o If I have this right now, the interval in question is a request to 
have the RRSIG(DS) regenerated at a certain rate.  (I'm still not 
sure. ;))

#3

Not sure what section to hang this on - The secDNS:sig record does 
not specify what the signature "covers."  The assumption is that the 
signature in this would correspond to the data in an appropriate 
(making a long story short) RRSIG.  I can explain better with an 
example:

             example. DNSKEY (flags=257) key... ; ID 12345
             example. DNSKEY (flags=257) key... ; ID 54321
             example. DNSKEY (flags=256) key... ; ID 11111
             example. DNSKEY (flags=256) key... ; ID 22222
             example. DNSKEY (flags=256) key... ; ID 33333
             example. RRSIG  DNSKEY ...by example. 12345 ...sig over RRSet...
             example. RRSIG  DNSKEY ...by example. 54321 ...sig over RRSet...
             example. RRSIG  DNSKEY ...by example. 11111 ...sig over RRSet...
             example. RRSIG  DNSKEY ...by example. 22222 ...sig over RRSet...
             example. RRSIG  DNSKEY ...by example. 33333 ...sig over RRSet...

The first two flags (12345,54321) are secure entry points, meaning 
that the intention is to make DS's of these two.  The other three are 
not - neither SEP's nor intended to be "DS'd."

All five RRSIG's "cover" the 5 DNSKEY records, each signature comes 
from the private key corresponding to the listed public key ("by 
..."), yadda yadda yadda.  The important point is that the covered 
data includes both the DS-intended keys and the non.

So - if the RRSIG in the secDNS:sig means to use that signature, the 
non-DS'd keys have to become visible to the registry (if the intent 
is to verify the data).  I don't think this is desirable. ;)

Therefore - what is covered by the RRSIG needs to be decided.

Suggestion - have the RRSIG cover the corresponding DNSKEY "solo."

#4

This isn't a document issue, so I'll just keep this short...

I'm not 100% certain whether DS or DNSKEY is the better path, but 
lately I've been leaning on DS.  This is a reflection of "the 
registry needn't be involved with anything other than the DS."

If it is determined that DS is the way to go for all, we should - in 
the name of simplicity - drop the DNSKEY option.  (Issue #3 would go 
away for one.) OTOH, if there's a registry that needs to do the 
DNSKEY option, we should keep it.

I'd like to raise the question - does any registry out there *need* 
the DNSKEY option - as opposed to thinking it might be better.  Not 
to argue the point, but to help *me* understand whether or not the 
DNSKEY is a needed option.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

I would have been at the meeting, but I was busy raking the leaves from
the (now) empty non-terminals in my yard.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Sun, 14 Nov 2004 21:28:37 +0100

Ed,

> DNSKEY is a needed option.

For me as well, the natural option is the provision of the DS record. 
However in a discussion with somebody (Miek, was it you?), he mentioned 
that it could be useful for the registry to have the DNSKEYs handy, in 
case the algorithms to distille the DS out of it would change.

Best,
Marcos
.

---

From: Miek Gieben <[email-masked]>
Date: Mon, 15 Nov 2004 11:07:15 +0100

[On 14 Nov, @ 21:28, Marcos wrote in "Re: [dnsop] comments on draft. ..."]
> case the algorithms to distille the DS out of it would change.

I don't remember exactly... but my opinion always has been that a
child doesn't really have to deal with DSs, that's a parent only
thing. So why burden a child with the DS creation?

Also if a parent has access to the child's key, you can use that to
verify oob messages which are signed with the private key of child (if
you wanna go that route).

OTOH the keys _are_ in the DNS, so you could also query for them if
you need them.

grtz Miek
.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 15 Nov 2004 13:05:06 +0100

My 2 euro cents

The DNSKEY is the object that the registrants deals with, the DS is what 
the registry  puts into the zone.  You do not want the EPP protocol to 
fix where the DNSKEY to DS transformation takes place, that is why the 
protocol should allow for both the DNSKEY and DS RR, rest is "local policy".

I personally like the idea that the registrants deals with DNSKEYs, that 
is what they have the tools for, they should not touch DS RRs. From a 
deployment point of view it is probably more easy to centrally do the 
DNSKEY to DS hashing instead of shipping the tools to the custommers 
(registrants). A registry could off course also push the responsibility 
for DS generation to the registrar. The EPP protocol should not enforce 
this but enable this.

What a registry (or registrar) could do at the moment it does the 
translation from DNSKEY to DS RR is to put both the values in the WHOIS 
DB.  That could be handy for troubleshooting.

--Olaf Kolkman
.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 15 Nov 2004 07:57:04 -0500

> case the algorithms to distille the DS out of it would change.

This was the primary reason that the current proposal includes the option to
do one or the other.  It adds some complexity.  Is the benefit worth it or
not?

-Scott-

.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Nov 2004 09:48:34 -0500

>do one or the other.  It adds some complexity.  Is the benefit worth it or

That's a question I wanted to raise.

If the DNSKEY is the basis of the transaction, then the registry can 
"do more" - it can display the keys in whois, it can generate the 
hash under "controlled" circumstances.

OTOH - is that the job of the registry?  Why put the keys in whois 
when the "important" protocol is DNS?  Why would the registry ever 
need to recalculate the hash?  (A recalculation would only be 
*required* if the digest type - only SHA-1 is currently defined - 
were to be rescinded from code bases.)

The first issue to hash out is - whether a registry needs the key or 
even if the registry should get the key.  Remember that "key at 
parent" was ditched in favor of the delegation signer record.

The second issue is whether the protocol ought to even support a 
choice.  In my opinion, the DS option is required.  If the protocol 
does not allow the DNSKEY option, we are cutting out a design choice. 
But is that a bad thing?

Is there a hard requirement that the epp-secdns retain the DNSKEY 
option?  (I don't consider "maintaining the choice" or "pushing the 
decision up a level" as hard requirements.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

---

From: Miek Gieben <[email-masked]>
Date: Mon, 15 Nov 2004 16:12:16 +0100

[On 15 Nov, @ 15:48, Edward wrote in "RE: [dnsop] comments on draft. ..."]
> hash under "controlled" circumstances.

<SNIP>

> decision up a level" as hard requirements.)

I don't think there is a hard requirement either way (DS/DNSKEY). The
only thing I know is that when I designed the SECREG registry I used
DNSKEY as a base for communication. That was done because I could
query for the DNSKEY records in the child zone. As a parent I could
then create the DS records and put them in the zone. (To put the whole
implementation in a tiny nutshell)

So I went for DNSKEY and Ed goes for DS. Two people, two different
choices. I think we should let the implementers decide this and not
the draft writers,

grtz Miek
.

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 15 Nov 2004 15:23:24 +0000

> do one or the other.  It adds some complexity.  Is the benefit worth it or

I didn't follow the debate that led to the choice to include both. But
previous experience suggests that only including one (either!) would
be seen as dictating security policy or procedure in some way. I think
keeping both is better.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Nov 2004 10:57:47 -0500

>be seen as dictating security policy or procedure in some way. I think

I'm not sure there was a debate that led to both being there.

Keeping both covers ourselves with respect to having the protocol do 
either.  But this is done at a cost - more complex code, more complex 
business rules.

As operators (DNSOP) what is the consensus of the group?  Is 
specifying one way going to make the operations job easier than 
specifying two ways of doing this?  If we don't specify the DNSKEY 
option are we losing something important?

This isn't just a question for registries, it's also for registrars 
and whoever else is on the client end of the connection (e.g., LIRs 
and NIRs if EPP spreads to the number registries).  Does a registrar 
want to have to configure "DNSKEY" for one TLD, and "DS" for a 
different TLD?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Nov 2004 10:47:02 -0500

>choices. I think we should let the implementers decide this and not

Well, it's deeper than that.  We've implemented the DS option and not 
the DNSKEY option in our initial toolkit.  You've implemented the 
DNSKEY option.

The question is - if you had to do it all over again, would you have 
bothered with the DNSKEY option?  Has there been any demand to use 
the DNSKEY option by any users/testers of SECREG?

This isn't intended as a critical question, nor just a question over 
what is said in the draft.  I'm trying to determine if there is a 
reason for the DNSKEY option.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 15 Nov 2004 12:12:21 -0500

> I'm not sure there was a debate that led to both being there.

There was, but it was between me and Olafur around the time of the Yokohama
meeting. ;-)

-Scott-

.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 16 Nov 2004 09:54:11 +0100

[On 15 Nov, @ 16:47, Edward wrote in "Re: [dnsop] comments on draft. ..."]
> the DNSKEY option by any users/testers of SECREG?

I think I would use the DNSKEY option again. Solely on the basis of
not bothering the child with generating the DS. And I really liked my
in-band thingy (which used DNSKEY, prob. just KEY at the time).

I should say that I haven't read the epp-secdns draft in a LONG time,
but I doubt if I reread it my thinking would change,

grtz Miek
.

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 16 Nov 2004 10:45:40 +0100

> If we don't specify the DNSKEY

Not in my opinion, because the registry could query DNS if need be.

> Does a registrar

That's always a difficult question with trade-offs to be considered. Take 
for instance the IDN-over-EPP BoF in DC: the existent disparity of 
IDN-information provisioning (which drives to the problem you mention) 
wasn't considered a danger enough to move us to standardize the submission 
of IDNs.

Best,
Marcos
.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 16 Nov 2004 10:57:16 +0100

[On 16 Nov, @ 10:45, Marcos wrote in "Re: [dnsop] comments on draft. ..."]
> Not in my opinion, because the registry could query DNS if need be.

when you do that I would be handy to compare the result with something
you already have...

at least that's what I did. Let the user go to a website, submit his
keys - get the keys from DNS - compare.

grtz Miek
.

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Nov 2004 12:32:22 -0500

<hat wg-co-chair=off just-another-bozo=yes>

  With respect to all participants, this discussion of whether EPP
  should carry DNSKEY or DS appears to be following the "What color
  shall we paint the bike shed?" pattern.

  http://a.mongers.org/clueful/1999-phk-bikeshed

</hat>

<hat wg-co-chair=on>

  Is there anyone who would vehemently object to allowing EPP to
  support both record types and letting the users decide?

</hat>
.

---

From: Paul Vixie <[email-masked]>
Date: 16 Nov 2004 19:22:26 +0000

>   http://a.mongers.org/clueful/1999-phk-bikeshed

i disagree.  asking your parent zone to calculate a hash leaves open
the possibility that someday the way that hash is to be calculated
will change and you will know about the change but your parent won't,
and also the possibility that your parent will calculate it wrongly.

the simplest design is one where a zone owner gives the parent zone
data, and the parent zone publishes that data.  no transformations,
just storage and publication.

this is somewhat analagous to having to tell a parent zone both the
name and the address of a nameserver.  it's best to tell the parent
zone what it needs to know -- the name.  if you also tell it the
addresses, then there's a chance (a very good chance as it turns out)
that those addresses will be wrong, or will become stale.

just the facts, ma'am.

>   support both record types and letting the users decide?

that would be me.  if ORG ends up wanting DS, but COM and NET end
up wanting full keys, then the EPP community will not have been
well served by the standards process.  we have to make a decision
and make it stick.  compared to that, making the right decision is
a secondary consideration.
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Nov 2004 16:33:24 -0500

>   support both record types and letting the users decide?

I might, which is why I raised the question.  As far as I can tell, 
DNSOP is the best place to reach "the users" which is why the 
question came here.

There are two reasons why I *might* object to having the DNSKEY option.

One is that it represents more complexity in the implementations than 
the "DS alone" option - implementations of EPP and registry/registrar 
application code.

The other is that the DNSKEY option needs some work in hammering out 
the document - e.g., what does the RRSIG cover?  (Maybe the RRSIG 
isn't important to have?)

I am asking if there is a real situation in which the exchange of the 
DNSKEY can work and the DS key cannot work.

Marcos raised the points made in the IDN in EPP BOF.  The temperature 
of that room was that there isn't a need to attempt to define one 
"true" path to IDN.  The reason is that different registries were 
operating under different sets of incompatible requirements and that 
the chance of a unified technical approach was unlikely. 
Additionally, EPP would support multiple extensions to do this.

During the tail end of EPP work, there was a last minute addition to 
allow privacy to be "processed" at the client or the server - not 
just at the server.  This was in response to an AD comment for more 
operational flexibility.

As far as -epp-secdns- I don't know of dissimilar, incompatible sets 
of requirements that would need two different approaches.  'Course, 
no one has mandated even one set of requirements either. ;)

Since "I don't know" - I'm asking.  If we can eliminate the DNSKEY 
option, -epp-secdns- will move along a lot faster and toolkits will 
appear faster.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

---

From: Miek Gieben <[email-masked]>
Date: Thu, 18 Nov 2004 13:43:27 +0100

[On 16 Nov, @ 20:22, Paul wrote in "Re: [dnsop] comments on draft. ..."]
> and also the possibility that your parent will calculate it wrongly.

I think this is little bit far fetched. If your parent cannot even
calculate the correct DS, they will be able to correctly generate
the signature for the DS?

> just storage and publication.

I agree that this is the simplest design, but with DS you will have
to some transformation, no matter what. 

But who is more likely to make mistakes? The child, which doesn't even
see the DS in its zone? Or the parent who generates them by the
million?

> a secondary consideration.

true,

grtz Miek
.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 18 Nov 2004 15:58:02 +0100

[On 16 Nov, @ 09:54, Edward wrote in "Re: [dnsop] comments on draft. ..."]
> in-band thingy (which used DNSKEY, prob. just KEY at the time).

to reply to my own reply.

After some internal discussion here at labs, the following is also
possible:

1) get the DS via EPP from the child
2) parent retrieves the key via the DNS from the child
3) parent _transforms_ the key into a DS and compares that with
   the one from step 1

Step 3 falls under the category of *duh* :-)

So I guess my main argument for using DNSKEY is now void, 

grtz Miek
.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Nov 2004 10:06:05 -0500

>see the DS in its zone? Or the parent who generates them by the

Resisting the open net shot at a snide comment, what difference does 
this make?  If you are concerned that the child can't generate the 
hash, consider that making the keys, putting them in the zone, and 
signing is more difficult.

Granted this is a comment on an implementation, but here is the 
sequence of commands issued to get to a signed zone and the hash:

  Make two keys
   $ dnssec-keygen -a RSA -b 512 -n zone -f KSK zone1.example
   $ dnssec-keygen -a RSA -b 512 -n zone zone1.example

  Add the keys into the zone ($INCLUDE used in this example)
   $ vi zone1.example

  Sign the zone
   $ dnssec-signzone -k Kzone1.example.+001+42509 -o zone1.example \
     -t zone1.example Kzone1.example.+001+64678

At the end of this, I see a file called dsset-... which has the DS all set.

'Course this is one implementation's tools.  There are still some 
more operational optimizations to go.  Also, I'm showing a "clean 
start" - no old keys to mess with.

The point is that the DS hash generation is a byproduct of a far more 
"complicated" process (= a two [2!] line signing command ;) ).

This is not an argument of DNSKEY vs. DS.  The tools above also give 
a keyset-... file, although it doesn't have the RRSIGs in it as 
needed in -epp-secdns-05.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

I think my jabber client and SMS phone are talking about me behind my back.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Nov 2004 10:12:08 -0500

Just to clarify (btw, wildcards are making me *hate* that word), I'm 
not on a bender to stamp out DNSKEY from the EPP specification per se.

I am just curious if there is a case or an environment where the 
DNSKEY approach will work and the DS approach "WILL NOT" work.

Private replies are welcome, I'll post a summary.  There's no time 
limit, but it would be nice to hear of any such cases before Scott's 
draft makes it to Full Standard.

;)

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 19 Nov 2004 11:33:55 +0100

> 3) parent _transforms_ the key into a DS and compares that with

Labs have read my mind.

Best,
Marcos
.

---

From: [email-masked]
Date: Fri, 19 Nov 2004 13:18:30 +0000

> > 2) parent retrieves the key via the DNS from the child

	operationaly does this presume that the parent
	can/MUST beable to do a zone transfer or will there
	be a mutually agreeable, common location where the
	parent can retreive the key via standard queries?

--bill

.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Nov 2004 09:28:53 -0500

>	parent can retreive the key via standard queries?

Wouldn't (minimally, assuming BIND) this do the trick?

                    dig registrant.example DNSKEY

That would give the "live" view of the data.

'Course, if it's cache poisoning you fear, you can direct the dig to 
a server, protect it with a mutually agreed upon message protection 
mechanism (TSIG, etc.) yadda, yadda, yadda.

Why would a zone transfer be needed?

---

From: [email-masked]
Date: Fri, 19 Nov 2004 15:03:42 +0000

> That would give the "live" view of the data.

	which DNSKEY?  presuming a single key here?

> Why would a zone transfer be needed?

	if there was no other way, that is -a- way to get the key from
	the child.

.

---

From: [email-masked]
Date: Fri, 19 Nov 2004 15:06:44 +0000

marcos, is there a reason you are blacklisting me?

> > can/MUST beable to do a zone transfer 
> 
> No need for that.

	but that will work - yes?

> > or will there
> A query to the DNSKEY RR at the child's apex with the SEP bit set?

	does that presume a single DNSKEY?
	
.

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 19 Nov 2004 16:01:28 +0100

Bill,

No need for that.

Best,
Marcos
.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Nov 2004 10:15:46 -0500

>	which DNSKEY?  presuming a single key here?

dig returns RRSets...

>	if there was no other way, that is -a- way to get the key from

Is there a situation (on the public Internet) in which only a zone 
transfer is available?

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 23 Nov 2004 15:00:11 -0500

> > 3) parent _transforms_ the key into a DS and compares that with

To state the obvious, using steps 2 and 3 it is possible to do
a DS digest algorithm rollover.

In the discussion between Scott and me in 2002, I was advocating DS
as the only option due to simplicity and less typing for registrant
into web form at registrar, Scott and his co-workers where not
sold at the time on the concept of DS so they wanted to keep both
options.
EPP is a protocol between Registry and Registrar, and I see the
registrar as the natural place to handle translation from
DNSKEY to DS for the technically challenged.
For EPP used in Enterprises

I want to remind: one of the reasons for using HASH in the DS record
was liability issues for the parent, another one was to allow delayed
exposure of  public key material,

In any case IMHO there is  no good reason to provide both DS and
DNSKEY, lets only standardize DS.

Now on to new issue:
The RRSIG in the EPP transfer.
This text was put in based on my suggestion, upon reflection I think
this is a bad idea and should be removed from the document.
If we send DS then the recipient needs to query for the DNSKEY RRset
to evaluate the signatures, this forces the registrant to have the new
SEP key on-line.

Overall I think the question is: why provide more Security for the
DS exchange than is provided for the NS exchange?

         Olafur 

.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 23 Nov 2004 21:21:10 +0100

[On 23 Nov, @ 21:00, Ólafur wrote in "Re: [dnsop] comments on draft. ..."]
> DS exchange than is provided for the NS exchange?

...because we can?

grtz Miek
.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Nov 2004 08:51:39 +1100

> > DS exchange than is provided for the NS exchange?

	There is no need for DS to have a different level of protection
	than NS or glue have.  As far as EPP is concerned they are just
	data.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Nov 2004 18:03:53 -0500

>>  DS exchange than is provided for the NS exchange?

The inclusion of the RRSIG doesn't add 
"security."  Any bozo can make a key pair and 
submit the public key, or the hash of the public 
key.  So what if it is self-signed?

As far as provisioning is concerned, only the DS 
RRSet matters.  (This is why I'm taking a fairly 
hard line with respect to the DNSKEY option.) EPP 
is a provisioning protocol, not a registry 
correctness protocol.

If a registry wants to be more proactive in 
correctness (e.g., per a business rule), the 
registry can reach out to the DNS of the 
registrant and pull the data (via port 53) for 
the check.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 29 Nov 2004 13:55:51 -0500

Olafur,

> to evaluate the signatures, this forces the registrant to have the new

If we remove the DNSKEY data, the RRSIG stuff goes with it because
<secDNS:sig> is currently part of <secDNS:keyData>.  Are you suggesting
something else?  If we remove it I can see a need for some text to describe
the operational issue that you've touched on above.

-Scott-

.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 29 Nov 2004 16:45:02 -0500

>the operational issue that you've touched on above.

It was not perfectly clear from the draft that RRSIG was only on the
DNSKEY RR submission mechanism, if the choice is between
DNSKEY+RRSIG or DS

Then my vote is for DS only mechanism.

         Olafur

.