On 10/18/2017 5:21 PM, Wes Hardaker wrote:
You said in 4.1:
which the principle
way RFC5011 is currently being used (even though Section 6 of
RFC5011 suggests having a stand-by key available)
And then in T-1 you say:
Note that for simplicity we assume the signer is not pre-signing and
creating "valid in the future" signature sets that may be stolen and
replayed even later.
But - "the way RFC5011 is currently being used" is with "pre-signing"
and "valid in the future" signature sets. So you want to have your
cake and eat it too. You're now both not dealing with the way 5011
said you should do things nor are you dealing with the way that the
root actually does things.
All of this can be fixed by going to a wall clock model which is the
way the publisher works vs the interval model which is only
appropriate for the client.
I understand that's how you'd structure the document. For me,
I believe it's easier for people to understand the problem as
structured.
This is unfortunately a deflection. The document is still being
two-faced in that it is claiming to address "the way RFC5011 is
currently being used" but ignoring the "pre-signing" and "valid in the
future" signature sets in its discussion of the issue AND the solution.
With respect to below, I believe that "most people" (who are doing 5011
in the way you've described) would want the answer to the question:
"When is it safe for me to revoke all of the older trust anchor
keys?". When they discuss it with "other people" they will use a fixed
date not "5 days from when I did the calculation which was 2 days ago so
three days from now".
This isn't about a structuring preference, it's about having 10 people
doing the math at different times and having 100s others get the same
understanding of the answer when the first 10 discuss it.
Even the Root 5011 folks discuss their timings in terms of actual
dates. Yes they get to the dates by doing interval calculations, but
what matters are the dates and I haven't heard anyone say otherwise.
The example walk-through is designed to be simple
for learning about the issue, which is already complex enough.
This topic was brought up on the list before and in Chicago and
the consent was to leave it as is, though there wasn't a huge
number of voiced opinions. We designed the document to come at
the topic for human understanding, and I believe most people
think about the problem as a delta from the time they sign and
publish the zone. I believe that coders will implement it
according to how they need to given their software.
If you feel strongly about this, please encourage others to
chime with requests for change too in order to shift consensus.
At this time we don't plan to change the document to reflect
your preferred style.
You continue to have a problem with "sigExpirationTime".
> The amount of time remaining before any existing
> RRSIG's Signature Expiration time is reached. Note that for
> organizations pre-creating signatures this time may be fairly
> lengthy unless they can be significantly assured their signatures
> can not be replayed at a later date.
the problem is: Amount of time measured from when? (and it should
be "latest RRSIG's Signature Expiration time is reached" at least.
> sigExpirationTime will
> fundamentally be the RRSIG's Signature Expiration time minus the
> RRSIG's Signature Inception time when the signature is created.
This is no longer fundamentally the difference between one RRSig
inception and expiration time. You can't even describe it as the
difference between the earliest inception and latest expiration
because that changes as the earlier RRSigs expire. The only fixed
value (and easiest value) is "latest expiration date". You could say
"latest expiration date - now" which then gets added to "now" to get
back to lastest expiration date.....
Please, please please just move to a wall clock value based on the
latest expiration date plus appropriate intervals. All the minor
twiddles you've done to try to avoid doing this have made the document
less clear.
I've changed the wording to your "latest...". Thank you for the
concrete suggestion.
You're welcome. However, all the rest of these are also "concrete
suggestions". Or do you mean "actual text that I can incorporate"? I'm
happy to edit the entire document to fix the issues if you want to give
me the edit token.
As to "when" it amounts to the current
value time(), which is indicated by the "The amount of time
remaining...".
So 10 people doing this have to publish both the interval they calculate
and the time() value at which they did their calculations? So the other
10-100 people can figure out "when"? I think not.
Again, this is written from the point of view of
a human wanting to calculate how long the need to continue waiting.
And it should be written from the POV of a human wanting to tell a group
of people WHEN something will be done. Sending out "we're going to do
this in 45 days" is problematic especially if I re-read the email 10
days after it was sent or if the email was delayed. Sending out
"we're going to do this on January 1st at 10am" or "we're going to do
this in 45 days which is January 1st at 10am" is going to be more useful
than a simple interval.
I can't figure out why you continue to argue as you do - the output of
this calculation is a date and time at which it is safe to revoke the
old keys - not an interval. In fact you have to work hard to make it an
interval.
Later, Mike
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
