Subject: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt

From: Stephen Morris <[email-masked]>
Date: Mon, 13 Jun 2011 18:22:39 +0100

Dear DNSOP WG,

This is to initiate a working group last call (WGLC) on

      "DNSSEC Policy & Practice Statement Framework"
       draft-ietf-dnsop-dnssec-dps-framework-04.txt

Owing to the length of the document, the WGLC will last for three weeks
instead of the usual two, and will therefore end on

             Monday, 4 July 2011, 23:59 UTC

The IETF tools site gives easy access to the current and previous
versions, as well as differences and the like, at:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-04

The document is aimed at a status of "Informational".

Please review the document and send any comments you may have to the
list.  If you have no comments but support (or do not support) the
document being published, please send that information to the list.

The document is subject to the normal five reviewer threshold.

    Stephen and Peter
     DNSOP co-chairs

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 14 Jun 2011 17:39:04 +0200

I have read this draft, have no further comments and support it being published as Informational.

	jakob

---

From: Richard Lamb <[email-masked]>
Date: Tue, 14 Jun 2011 08:59:45 -0700

I've reviewed it and have nothing to add. I find it very useful and support it being published as Informational.

-Rick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Morris
> Sent: Monday, June 13, 2011 10:23 AM
> To: [email-masked]
> Subject: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt
> 
> Dear DNSOP WG,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mehmet Akcin <[email-masked]>
Date: Tue, 14 Jun 2011 10:15:57 -0700

I've read and support informal draft-ietf-dnsop-dnssec-dps-framework-04.

mehmet

---

From: Sebastian Castro <[email-masked]>
Date: Thu, 16 Jun 2011 17:01:00 +1200

On 06/14/2011 05:22 AM, Stephen Morris wrote:

I've read this document (and previous versions), I have no further
comments and support its publication as Informational

-- 
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 17 Jun 2011 08:37:51 +0200

I have read it and have one comment:

I would have expect that section 4.6. on Zone Signing would have a
subcomponent on Signing Scheme. Such a subcomponent would address the
number of keys used for signing and what roles (zsk, ksk) they fulfill.

I would like to see this addition and I support its publication as
Informational.

Best regards,

Matthijs

---

From: Fredrik Ljunggren <[email-masked]>
Date: Fri, 17 Jun 2011 07:56:55 -0700

Matthjis,

thank you for reviewing the document. The intention is to cover those aspects you mention (key separation, number of keys and roll-over scheme) in sections 6.4, 6.5 and 6.6. It is also intended that a drafter of a DPS may put a rationale, explaining why a particular scheme has been choosen, directly in the main component (6).

For this reason, I'm concerned that a new component may overlap with those already existing. However, I do agree that the intentions described above are not very clear (section 4.6.4 - 4.6.6 of the document), and could be explained in more detail. Would that fulfil your purpose, or did I misunderstand you?

 -- Fredrik Ljunggren

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 17 Jun 2011 16:31:43 -0400

On 13/06/2011 1:22 PM, Stephen Morris wrote:
>        "DNSSEC Policy&  Practice Statement Framework"

I have reviewed this document and support its publication.

Few nits and questions below:

a) DP and DSP should be included in the Definitions section 2, even 
though the abbreviations are are defined in section 1.2
Alternatively spell out in section 3.1. and 3.2 titles what DP and DPS are.

b) The document for all practical purposes is about the process until a 
zone has been signed/resigned. There is almost no discussion about the 
operation of the signed zone is this intentional or an omission ?
(the exceptions are the key rollover sections 4.5.4+5)

c) Section 4.6.9 should not limit itself to TTL's to types it should 
cover all types in the zone as the Maximum TTL in the zone impacts how 
fast keys can be added/removed from DNSKEY set.

d) Section 4.6.8 does not indicate what the purpose of this test is.
I think the purpose is to prevent bad data from showing up in the DNS.

f) There needs to be section (4.6.x) for zones that use NSEC3 as to the 
policy for changing NSEC3 parameters as this is similar to a ZSK roll-over.

Questions:

c)  should the DPS have a section describing if/when/how a zone (i.e. 
the one covered by the DPS) goes to unsigned?

d) Should the DPS have a section describing the zone's policy as how to 
perform an algorithm rollover ?
what I'm in particular looking for is in particular how long the zone 
expects to be signed by both algorithms.

	Olafur

---

From: Fredrik Ljunggren <[email-masked]>
Date: Sun, 19 Jun 2011 09:22:02 -0700

On 2011-06-17, at 13:31, Olafur Gudmundsson wrote:

> a) DP and DSP should be included in the Definitions section 2, even though the abbreviations are are defined in section 1.2

Makes perfect sense. I prefer spelling it out in the section headers to keep the document from growing even further.

> b) The document for all practical purposes is about the process until a zone has been signed/resigned. There is almost no discussion about the operation of the signed zone is this intentional or an omission ?

The document is intended to cover all security-related aspects and topics (including operational) which is impacted by the introduction DNSSEC in a zone. So in this context, technical operation of the signed zone is covered in the key-rollover sections (6.4, 6.5), in the signing/re-signing section (6.6) and the verification of the data to be signed (6.7, 6.8). From a business-operational perspective, contingency and disaster-recovery planning is covered in 4.5 and 4.6. For key management life-cycle operations (such as generation of new keys and possibly also distribution, backup and destruction), should be covered in sections 5.1 and 5.3.

Are other aspects to operations which you think should be included in the document? (Or do you think the scope is too narrow?)

> c) Section 4.6.9 should not limit itself to TTL's to types it should cover all types in the zone as the Maximum TTL in the zone impacts how fast keys can be added/removed from DNSKEY set.

Good point, you are absolutely right. SOA expire and negative caching is also part of the equation.

> I think the purpose is to prevent bad data from showing up in the DNS.

Yes. It currently reads:

   This subsection addresses the controls around the verification of the
   resource records in order to validate and authenticate the data to be
   signed.

Should we clarify in that? Suggestions?

> f) There needs to be section (4.6.x) for zones that use NSEC3 as to the policy for changing NSEC3 parameters as this is similar to a ZSK roll-over.

The intention is to have this in 6.2. But I see that there are no mentions of policy for changing of NSEC3-parameters in 4.6.2 of the draft. I'm thinking of adding a sentence to the text in 4.6.2 instead of creating a new subsection?

> Questions:
> 
> c)  should the DPS have a section describing if/when/how a zone (i.e. the one covered by the DPS) goes to unsigned?

There has been discussions about this among the authors, but so far we've agreed on that such procedure is a DR-procedure and may be described in 4.5.

> d) Should the DPS have a section describing the zone's policy as how to perform an algorithm rollover ?
> what I'm in particular looking for is in particular how long the zone expects to be signed by both algorithms.

I'm thinking that whatever forces a zone to change the algorithm is an unexpected event which has many dependencies to unknown factors (such as resolver implementations, new algorithms .. ), which is really hard to plan ahead for in such detail.

Although, the emergency case (where a algorithm has been fundamentally broken) should be covered in 4.5.3 (Entity private key compromise procedures).

-- Fredrik

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 20 Jun 2011 10:00:53 +0200

Hi Fredrik,

On 06/17/2011 04:56 PM, Fredrik Ljunggren wrote:
> Matthjis,
> 
> thank you for reviewing the document. The intention is to cover those
> aspects you mention (key separation, number of keys and roll-over
> scheme) in sections 6.4, 6.5 and 6.6. It is also intended that a drafter
> of a DPS may put a rationale, explaining why a particular scheme has
> been choosen, directly in the main component (6).

I think you mean sections 4.6.4, 4.6.5 and 4.6.6. Those sections
(especially the first two) cover ZSK specific rollover and KSK specific
roll-over schemes and are relevant in case a zone is subject to a
KSK/ZSK Split Signing Scheme.

However, if a zone is subject to a Single Type Signing Scheme, different
roll-over schemes are relevant.

The main component of 4.6 already says:

   This component covers all aspects of zone signing, including the
   cryptographic specification surrounding the Key Signing Key and Zone
   Signing Key, *signing scheme* and methodology for key roll-over and
   the actual zone signing.

I think 4.6.4 and 4.6.5 cover methodology for key roll-over. I miss a
section that says "Signing Scheme: This subcomponent describes which
signing scheme is in use."

Best regards,

Matthijs

> 
> For this reason, I'm concerned that a new component may overlap with
> those already existing. However, I do agree that the intentions
> described above are not very clear (section 4.6.4 - 4.6.6 of the
> document), and could be explained in more detail. Would that fulfil your
> purpose, or did I misunderstand you?
> 
>  -- Fredrik Ljunggren
> 
> 
> On 16 jun 2011, at 23:37, Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>>>             Monday, 4 July 2011, 23:59 UTC <x-apple-data-detectors://2>
>>>
>>> <http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-04>http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-04
>>>
>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>> <https://www.ietf.org/mailman/listinfo/dnsop>https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
>

---

From: Scott Rose <[email-masked]>
Date: Mon, 20 Jun 2011 07:32:32 -0400

I have read previous versions of the draft, and skimmed this one looking at the changes.  I agree that the document is (almost) ready to go.

> the one covered by the DPS) goes to unsigned?

I agree, adding this will improve the doc.

> expects to be signed by both algorithms.

There might be a variety of reasons that a zone may want to roll the algorithm(s) in use and that reason may dictate the length of time both algorithms are used.  So I don't think it's the best idea.  

Scott

> 	Olafur

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Jun 2011 11:20:10 -0400

Fredrik,

> Makes perfect sense. I prefer spelling it out in the section headers to keep the document from growing even further.

Good

> Are other aspects to operations which you think should be included in the document? (Or do you think the scope is too narrow?)

I think the document needs to be clearer as to what is NOT covered in a 
DSP.

It is fine for the document to say that it only covers: (in section 1.3)
"As to DNS operational aspects of the zone, Normal DNS operation is 
outside the scope of this document but best DNS operational practices 
are expected".
(as this is a product of the dnsop WG you need to say that or some 
readers may have expectations as how to set up name-servers).

Having said that does the document need to spell out how to recover if 
the signing infrastructure fails?

> Should we clarify in that? Suggestions?

What I want to know is, how does a failure in the signing system, show up?
1) updates to be blocked i.e. zone will stop processing updates.
2) New versions of zone will not show up on schedule
3) bad data will be published but will be replaced as soon as possible?
4) something else.

as this may affect Service level agreements having this spelled out is a 
good thing.

> The intention is to have this in 6.2. But I see that there are no mentions of policy for changing of NSEC3-parameters in 4.6.2 of the draft. I'm thinking of adding a sentence to the text in 4.6.2 i…

That is fine,

> There has been discussions about this among the authors, but so far we've agreed on that such procedure is a DR-procedure and may be described in 4.5.

I agree this frequently is a Disaster Recovery, but this may also be a 
policy decision.
In particular for a tld. having DS removed is estimated to take 2 days, 
flushing the DS takes another day, DNSKEY may still trusted by resolvers 
for the DNSKEY TTL.
Thus in the case of loss of zone signing the DS must be removed 3 days + 
DNSKEY TTL before the first signature in the zone expires.

If the zone is going to bring up a new signing system (with new keys) is 
the zone going be dual signed until old keys are flushed from the system.

> I'm thinking that whatever forces a zone to change the algorithm is an unexpected event which has many dependencies to unknown factors (such as resolver implementations, new algorithms .. ), which…

Still does not cover if/how long the zone is going to be dual signed.

As to the planning for algorithm rollover.

The DSP may say
     "before any algorithm rollover a new DSP will be published x months 
before the event"
or   "in case of introduction of new algorithm in the zone the zone will 
be dual signed for x days"
or   "zone will NEVER roll algorithm only go to longer keys"
or   "zone will change from NSEC3 to NSEC 6 months after x% of the zone 
has DS records"

Algorithm rollover is the scariest part of DNSSEC operation,
> Although, the emergency case (where a algorithm has been fundamentally broken) should be covered in 4.5.3 (Entity private key compromise procedures).

I think there are two different cases, that need to be covered, key 
compromised and algorithm compromised.

The first one is important the second one is not a big deal as
DNSSEC is only one of many security systems that will be affected and 
slow and deliberate process in this case is better for everyone than 
quick over-reaction.

Thus the document should focus on the first case, by recommending that 
the zone publish a time-line for algorithm rollover and include a 
policy as how long the zone is going to be dual-signed.

	Olafur

---

From: Fredrik Ljunggren <[email-masked]>
Date: Wed, 22 Jun 2011 10:51:09 -0700

> signing scheme is in use."

I think we may have different conceptions of what a "signing scheme" is (which may call for clarification of that in the definitions section).

For me, signing scheme is the signature life-time and re-signing frequency, paired with the key roll-over schedule. What exactly is it you are missing? What would a drafter put in the "signing scheme" section which does not fit into any of the other subsections?

-- Fredrik

---

From: Fredrik Ljunggren <[email-masked]>
Date: Wed, 22 Jun 2011 11:32:24 -0700

On 2011-06-20, at 08:20, Olafur Gudmundsson wrote:

> I think the document needs to be clearer as to what is NOT covered in a DSP.
> 
> "As to DNS operational aspects of the zone, Normal DNS operation is outside the scope of this document but best DNS operational practices are expected".
> (as this is a product of the dnsop WG you need to say that or some readers may have expectations as how to set up name-servers).
> 
> Having said that does the document need to spell out how to recover if the signing infrastructure fails?

I'm fine with clarifying the scope. Although, I strongly believe we should try real hard to not give recommendations as how to run a zone in the DPS framework document:

1.2.  Purpose

   The purpose of this document is twofold.  Firstly, the document aims
   to explain the concept of a DNSSEC Policy (DP) and a DNSSEC Practice
   Statement (DPS), and describe the relationship between a DP and a
   DPS.  Second, this document aims to present a framework to encourage
   and assist writers of Policies and Practice Statements in creating
   heterogenous and comparable documents.  In particular, the framework
   identifies the elements that should be considered in formulating a
   DP/DPS.  It does not, however, define a particular Policy or Practice
   Statement, not does it seek to provide legal advice or
   recommendations as to the contents.

> as this may affect Service level agreements having this spelled out is a good thing.

Doesn't this belong in section 4.5.2 (Corrupted computing resources, software, and/or data) of a DPS - described in section 4.4.5 in the framework document?

> I agree this frequently is a Disaster Recovery, but this may also be a policy decision.
> In particular for a tld. having DS removed is estimated to take 2 days, flushing the DS takes another day, DNSKEY may still trusted by resolvers for the DNSKEY TTL.
> Thus in the case of loss of zone signing the DS must be removed 3 days + DNSKEY TTL before the first signature in the zone expires.
> 
> If the zone is going to bring up a new signing system (with new keys) is the zone going be dual signed until old keys are flushed from the system.

The intention is that this is to be covered in the same sections as mentioned above (4.4.5 in the framework document). That is where a TLD (or other zone operator) would spell out the policy for recovering from a lost or compromised key.

>    "before any algorithm rollover a new DSP will be published x months before the event"
> or   "in case of introduction of new algorithm in the zone the zone will be dual signed for x days"
> or   "zone will change from NSEC3 to NSEC 6 months after x% of the zone has DS records"
> 

Ok, I see what you mean. Good point. I'm thinking maybe clarifying on this under "Key lengths and algorithms" (and possibly also under "Authenticated denial of existence"), or do you think we should create a new subsection for it?

> I think there are two different cases, that need to be covered, key compromised and algorithm compromised.
> 
> DNSSEC is only one of many security systems that will be affected and slow and deliberate process in this case is better for everyone than quick over-reaction.
> 
> Thus the document should focus on the first case, by recommending that the zone publish a time-line for algorithm rollover and include a policy as how long the zone is going to be dual-signed.

Agreed. Although I think it may be worth mentioning the case of algorithm compromise under "Entity private key compromise procedures". Planning for that case may reduce the risk of quick over-reaction.

- f

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 23 Jun 2011 11:21:50 +0200

On 06/22/2011 07:51 PM, Fredrik Ljunggren wrote:
>> (especially the first two) cover ZSK specific rollover and KSK
>> specific roll-over schemes and are relevant in case a zone is
>> subject to a KSK/ZSK Split Signing Scheme.
>> 
>> However, if a zone is subject to a Single Type Signing Scheme,
>> different roll-over schemes are relevant.
>> 
>> cryptographic specification surrounding the Key Signing Key and
>> Zone Signing Key, *signing scheme* and methodology for key
>> roll-over and the actual zone signing.
>> 
>> I think 4.6.4 and 4.6.5 cover methodology for key roll-over. I miss
>> a section that says "Signing Scheme: This subcomponent describes
>> which signing scheme is in use."
> 
> I think we may have different conceptions of what a "signing scheme"
> is (which may call for clarification of that in the definitions
> section).
> 
> For me, signing scheme is the signature life-time and re-signing
> frequency, paired with the key roll-over schedule. What exactly is it
> you are missing? What would a drafter put in the "signing scheme"
> section which does not fit into any of the other subsections?

Basically it comes to this: It is not clear to me in what component I
can describe whether:
- - I am going to use a ZSK/KSK split signing scheme (where I have two
keys for signing, one to sign the DNSKEY RRset and another to sign the
rest), or
- - I am going to use a Single Type Signing Scheme (where I have one key
that signs all).

The two different methods I call signing scheme.

If I am going to use ZSK/KSK Split, there is a component that covers
ZSK(-only) roll-over and there is a component that covers KSK(-only)
roll-over.

If I am going to use a Single Type Signing Scheme, where do I describe
the roll-over schedule for that key.

Best regards,

Matthijs

> -- Fredrik
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: Fredrik Ljunggren <[email-masked]>
Date: Thu, 23 Jun 2011 09:51:40 -0700

> The two different methods I call signing scheme.

Ok! I follow you.

> the roll-over schedule for that key.

A KSK is a DNSKEY with the SEP bit set. And for validation to work with a single key, that key has to have the SEP bit set. So I would suggest roll-overs in a single-key zone to be described under KSK roll-over.

And you do have a point that this should be spelled out in the DPS framework document. Although, I'm a bit reluctant to having a whole new section for this, but would rather see it included in the existing sections. 

What do you think about adding some descriptive text to the section "Key lengths and algorithms", to include split/single key signing there? And using the existing subsections as relevant for roll-overs?

-- Fredrik

---

From: Chris Thompson <[email-masked]>
Date: 23 Jun 2011 18:51:10 +0100

On Jun 23 2011, Fredrik Ljunggren wrote:

>A KSK is a DNSKEY with the SEP bit set. And for validation to work with
>a single key, that key has to have the SEP bit set.

Shome mishtake, shurely? There are zones around that have only one DNSKEY,
without the SEP bit, and they validate just fine. To take two examples at
random: "nu" and "co.uk".

"nu" had its 15 minutes of fame when it failed to get included in
dlv.isc.org when ISC were importing the ITAR, just because the SEP bit
was missing. I seem to recall that ISC had to make special arrangements
to fix that.

"co.uk", and the other sub-zones of "uk" managed by Nominet, are more
recent examples.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Jun 2011 14:17:35 -0400

At 9:51 -0700 6/23/11, Fredrik Ljunggren wrote:

>A KSK is a DNSKEY with the SEP bit set. And for validation to work with a
>single key, that key has to have the SEP bit set. So I would suggest
>roll-overs in a single-key zone to be described under KSK roll-over.

SEP != KSK.

In the protocol, there is no distinction between KSK and ZSK.  The 
SEP bit signals the intent of the zone administrator to distribute 
this key to other parties to develop a chain of trust.

What is known as a KSK is a key that signs only other keys in the 
DNSKEY set and is (in the vast majority of cases) intended to be 
distributed to another party, for example, in a DS record to the 
parent zone.

A zone may use one key to sign everything (Common Signing Key is a 
designation I like) and have it be marked with the SEP bit.

The SEP bit is not a factor in validation.  It's a factor in key 
management tools.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 24 Jun 2011 10:41:13 +0200

Hi Fredik,

As others already pointed out. A key with the SEP bit set is not
necessarily a KSK.

I like to see Key Signing (KS) and Zone Signing (ZS) as a role of a key.
A key can than have one or both of these roles. The document focuses too
much on the situation where those roles are divided between different
keys (aka a KSK/ZSK split). Therefore, it might be difficult to fit in
the Single Type Signing Scheme into the framework.

I propose the following changes:

- --------------------------------------------------------------------------

Section 2 Definitions:

Key Roll Over - A operational process of DNSSEC to change one of the
keys currently used for signing.

Section 4.4.5. Compromise and Disaster Recovery:

Bullet point 2:
The recovery procedures used ... is re-established, whether one of the
keys requires a roll-over, how to assess the damage and carry out the
root cause analysis.

Bullet point 3:
The recovery procedures used if one of the keys is compromised.  These
procedures describe how ...

Section 4.6.1. Key lengths, algorithms and roles

This subcomponent describes whether the keys are used as Key Signing
Key, Zone Singing Key or both. It describes the key generation algorithm
and the key length used to create the keys.

Merge 4.6.4 and 4.6.5: Key Roll-over

This subcomponent explains the roll-over scheme per key. Roll-overs vary
depending on the roles of the key (e.g. does the key act as a Key
Signing Key, Zone Singing Key or both).

- --------------------------------------------------------------------------

I think these are fairly small changes and makes a Single Type Signing
Scheme fit more into the framework.

Best regards.

Matthijs

PS: Perhaps the Flags Field (to SEP or not to SEP) should also be
covered. I think it would fit in Section 4.6.1.

On 06/23/2011 06:51 PM, Fredrik Ljunggren wrote:
>> If I am going to use a Single Type Signing Scheme, where do I
>> describe the roll-over schedule for that key.
> 
> A KSK is a DNSKEY with the SEP bit set. And for validation to work
> with a single key, that key has to have the SEP bit set. So I would
> suggest roll-overs in a single-key zone to be described under KSK
> roll-over.
> 
> And you do have a point that this should be spelled out in the DPS
> framework document. Although, I'm a bit reluctant to having a whole
> new section for this, but would rather see it included in the
> existing sections.
> 
> What do you think about adding some descriptive text to the section
> "Key lengths and algorithms", to include split/single key signing
> there? And using the existing subsections as relevant for
> roll-overs?
> 
> -- Fredrik
> 
>

---

From: Fredrik Ljunggren <[email-masked]>
Date: Fri, 24 Jun 2011 14:27:28 -0700

> I like to see Key Signing (KS) and Zone Signing (ZS) as a role of a key.

Agreed, although I prefer the term "key type" rather than "role", as "role" may be confused the controls surrounding personnel and "trusted roles".

> I propose the following changes:

I like the idea of merging the subsections covering key roll-overs. 

> Scheme fit more into the framework.

I agree with the only remark to as calling it key types, rather than roles. If there are no objections I'll incorporate these and Olafur's suggested changes shortly and submit a -05 version of the draft.

-- Fredrik

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 27 Jun 2011 22:40:20 +0200

Hi Fredrik,

On 06/24/2011 11:27 PM, Fredrik Ljunggren wrote:
> Agreed, although I prefer the term "key type" rather than "role", as
> "role" may be confused the controls surrounding personnel and
> "trusted roles".

That's fine with me.

Best regards,

Matthijs

>> I think these are fairly small changes and makes a Single Type
>> Signing Scheme fit more into the framework.
> 
> I agree with the only remark to as calling it key types, rather than
> roles. If there are no objections I'll incorporate these and Olafur's
> suggested changes shortly and submit a -05 version of the draft.
> 
> -- Fredrik
> 
>