Subject: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Oct 2008 16:10:44 -0400

Folks,

I'm back from a 3 week vacation and catching up on e-mail.  It 
appears that there have been no substantive comments on the list re 
this document, which was revised before the Dublin IETF meeting, and 
briefed there by Carl Wallace. So, I am initiating WGLC effective 
today, and continuing through 10/15.

Thanks,

Steve

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 3 Oct 2008 12:53:11 -0400

We just submitted a new version of this draft.  Changes are minor aside
from the addition of section 3.13, which adds a requirement to enforce
constraints where a TA mgmt protocol is used to manage a trust anchor
store.  Please review the -01 version for WGLC. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2008 4:11 PM
To: [email-masked]
Subject: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

Folks,

I'm back from a 3 week vacation and catching up on e-mail.  It appears
that there have been no substantive comments on the list re this
document, which was revised before the Dublin IETF meeting, and briefed
there by Carl Wallace. So, I am initiating WGLC effective today, and
continuing through 10/15.

Thanks,

Steve

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Oct 2008 12:30:14 +0200

Hi

I've just read through this document, and I have but one comment.

In section 3.2.1 it says, "A trust anchor management protocol must  
provide support for these basic operations, however, not all  
implementations must support each option..."

I think a similar paragraph is needed in sections 3.3.1 and 3.4.1:
- It's perfectly reasonable to have a certain implementation (maybe  
the same one that only replaces the entire store) only make messages  
for all the TA stores for which it is responsible
- It's also reasonable for certain implementations to never delegate  
authority to another manager, and only support re-key.

Other than that, I think the document is ready for publication.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2008 15:35:55 +0100

Bunch of comments attached. While this version is quite close, I
think some of these do warrant changes.

Cheers,
Stephen.

Comments on http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

General:
-------

1: A scope question - does this document specify requirements for a protocol
where the TAM is not represented as a TA?  If not (which is fine), then perhaps
just say so directly, rather than indirectly as (I think) is currently the
case.

2: MUST/SHOULD etc. Section 2 says in part "...trust anchor stores must be
managed in accord with..." whereas section 3 has a bunch of more specific uses
of "must" (all lowercase, but whatever). It should be clear which bits are RFC
2119 language and which aren't. I'd also prefer use of uppercase MUSTs where
2119 is supposed to apply (and then a reference is needed as well.) The
specific sentence is section 2 isn't something that I think can be a MUST since
its unenforceable. Similarly, in 3.1.2 the word "required" is used though the
section is called "rationale" - is that meant to be a 2119 keyword or not?

3: Does 3.1.1 imply that message integrity cannot be provided by a transport
security service/mechanism but MUST be defined and used "in-band" in the TAMP
protocol? I think I don't mind for this protocol, but its not quite clear from
the text.

4: Does "transport independent" here mean the same as "can be used in both
session oriented and store-and-forward contexts"? If not, then would a TAMP
that (somehow) works over TCP but not DCCP comply? If so, then maybe merge the
first two sentences of 3.1.1 and lose the "must be transport independent"
phrase.

5: section 3.2.2 - what does "are compound" mean? If its not needed maybe
delete the sentence. If its needed, I think it needs to be clearer.

6: 3.3.1 seems to introduce "groups of trust anchor stores" with the
implication that they are named groups, but the sentence isn't clear about
that. If named groups are required say so. If not, get rid of the term. (If the
latter, then bullets 2 & 3 here could be merged into "an emumerated list of
trust anchor stores" since a single element list is a fine list:-)

7: 3.4.1 calls for delegation to be a "MUST" for the protocol. I would have
thought that a "MAY" is better here since delegation is inherently complex and
a simpler protocol might turn out to be better. A "MAY" here lets us decide
that later.  Delegation in 3.6.1 is a "should" vs a "must" in 3.4.1 - is that
deliberate? (I'd go for "MAY" in both cases)

8: 3.8.1 calls for replay detection for reports - surely the requirement would
also apply to other operations as well? (Reading further it seems that 3.11.1
does call for that, so suggest removing that from 3.8.1 in which case one of
3.8.1 or 3.9.1 can be removed?)

9: 3.10.1 might be defining a new operation or might be covered in 3.2.1, I'm
not sure. If its covered, then maybe delete 3.10.1, or is the point that 3.2.1
is must whereas 3.10.1 is a should? 

10: 3.11.1 almost seems to prevent use of reliable time information, which I
guess isn't right. Presumably it'd be ok to have a TAMP that with an
applicability statement saying it only applied where time was available? (I do
however, like the idea of also being able to work where there's no good time,
but perhaps that implies that there's a "MAY" missing somewhere?)

11: 3.12.1 - a "MUST" here seems too strong, in particular for the "source of
trust anchor information" - I think that'd be better as a MAY.

12: 3.13.1 seems to be out of scope for a TAMP since its imposing a requirement
on the 5280 processor and not on a TAMP. Maybe change from a requirement to a
nice bit of advice or a security consideration?  (3.13.2 also contradicts the
"must" in 3.13.1 I think)

13: I think the security considerations could usefully point out that a TAMP
creates a nice new target to attack - if I can get at the TAM private key or
replace the public key I can control a lot of the security stuff on the box.
Also, if a TAM makes a mistake (e.g. a typo in an allowed name constraint) that
creates a new accidental-DoS vector.

Nits:
-----

1: section 1, 1st bullet "begins a certification path" is a bit ambiguous
depending on whether the EE or CA is first or last. Suggest rephrasing (maybe
just say "a public key certificate" and leave it at that)

2: section 2, "Throughout this document, trust anchor managers are assumed to
be represented as trust anchors." Well, in the case where an application
manages trust anchors (e.g. like a browser) that may not be true. Maybe just
add a caveat here that other schemes are possible but aren't covered in this
document. 

3: s/and etc./etc./

4: last para of section 2, s/which trust anchors/the set of trust anchors/

5: section 3.3.1: is "TA Management" the same as "TA Manager" (the latter is a
defined term, the former not). If so, just use one; if not, please define the
term.

6: "specification of public key identifier" needs an "a" in 3.7.1

7: 3.8.1 and 3.9.1 seem to overlap a bit and could maybe be simplified (3.9.1
seems to call for everything in 3.8.1 other than replay detection)

8: I've no idea if 5280 and 5055 should be normative references for a protocol
requirements document, but then I also don't care. However, maybe someone else
does? :-)

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Oct 2008 16:26:20 -0400

I think the comment in 3.2.1 should be removed and the decision
regarding what an implementation must/may implement left to protocol
specifications.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Sunday, October 05, 2008 6:30 AM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

Hi

I think a similar paragraph is needed in sections 3.3.1 and 3.4.1:
- It's perfectly reasonable to have a certain implementation (maybe the
same one that only replaces the entire store) only make messages for all
the TA stores for which it is responsible
- It's also reasonable for certain implementations to never delegate
authority to another manager, and only support re-key.

On Oct 3, 2008, at 7:53 PM, Carl Wallace wrote:

>
> We just submitted a new version of this draft.  Changes are minor 
> aside from the addition of section 3.13, which adds a requirement to 
> enforce constraints where a TA mgmt protocol is used to manage a trust

> anchor store.  Please review the -01 version for WGLC.

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Oct 2008 16:26:26 -0400

Comments moved from attachment and copied below along with responses.

General:
-------

1: A scope question - does this document specify requirements for a
protocol
where the TAM is not represented as a TA?  If not (which is fine), then
perhaps
just say so directly, rather than indirectly as (I think) is currently
the
case.

[CRW] The intent was not to limit the representation of a TAM to be a
TA.  This could be delegated using a certificate.  Will clarify this in
section 3.4 and in the definition of a trust anchor manager.  

2: MUST/SHOULD etc. Section 2 says in part "...trust anchor stores must
be
managed in accord with..." whereas section 3 has a bunch of more
specific uses
of "must" (all lowercase, but whatever). It should be clear which bits
are RFC
2119 language and which aren't. I'd also prefer use of uppercase MUSTs
where
2119 is supposed to apply (and then a reference is needed as well.) The
specific sentence is section 2 isn't something that I think can be a
MUST since
its unenforceable. Similarly, in 3.1.2 the word "required" is used
though the
section is called "rationale" - is that meant to be a 2119 keyword or
not?

[CRW] Have adopted RFC2119 language for the next draft.

3: Does 3.1.1 imply that message integrity cannot be provided by a
transport
security service/mechanism but MUST be defined and used "in-band" in the
TAMP
protocol? I think I don't mind for this protocol, but its not quite
clear from
the text.

[CRW] Section 3.1 has been clarified as requiring in-band integrity.

4: Does "transport independent" here mean the same as "can be used in
both
session oriented and store-and-forward contexts"? If not, then would a
TAMP
that (somehow) works over TCP but not DCCP comply? If so, then maybe
merge the
first two sentences of 3.1.1 and lose the "must be transport
independent"
phrase.

[CRW] Section 3.1 has been revised per some offlist comments.  These
should address your concerns.

5: section 3.2.2 - what does "are compound" mean? If its not needed
maybe
delete the sentence. If its needed, I think it needs to be clearer.

[CRW] Will clarify.  The intent is that multiple trust anchors can be
acted upon in a single add or remove message.

6: 3.3.1 seems to introduce "groups of trust anchor stores" with the
implication that they are named groups, but the sentence isn't clear
about
that. If named groups are required say so. If not, get rid of the term.
(If the
latter, then bullets 2 & 3 here could be merged into "an emumerated list
of
trust anchor stores" since a single element list is a fine list:-)

[CRW] Will clarify that named groups are intended.

7: 3.4.1 calls for delegation to be a "MUST" for the protocol. I would
have
thought that a "MAY" is better here since delegation is inherently
complex and
a simpler protocol might turn out to be better. A "MAY" here lets us
decide
that later.  Delegation in 3.6.1 is a "should" vs a "must" in 3.4.1 - is
that
deliberate? (I'd go for "MAY" in both cases)

[CRW] Will relax the requirement in 3.4.1 to SHOULD.

8: 3.8.1 calls for replay detection for reports - surely the requirement
would
also apply to other operations as well? (Reading further it seems that
3.11.1
does call for that, so suggest removing that from 3.8.1 in which case
one of
3.8.1 or 3.9.1 can be removed?)

[CRW] Will collapse 3.8 and 3.9 into one section.  Will let 3.11 serve
as replay detection requirement.

9: 3.10.1 might be defining a new operation or might be covered in
3.2.1, I'm
not sure. If its covered, then maybe delete 3.10.1, or is the point that
3.2.1
is must whereas 3.10.1 is a should? 

[CRW] 3.10 is not a new operation but is probably best presented as
rationale.  Will probably fold content into 3.2.

10: 3.11.1 almost seems to prevent use of reliable time information,
which I
guess isn't right. Presumably it'd be ok to have a TAMP that with an
applicability statement saying it only applied where time was available?
(I do
however, like the idea of also being able to work where there's no good
time,
but perhaps that implies that there's a "MAY" missing somewhere?)

[CRW] Reworded to require a replay detection mechanism to be available
that does not require reliable time and to clarify that mechanisms may
be available that do.  

11: 3.12.1 - a "MUST" here seems too strong, in particular for the
"source of
trust anchor information" - I think that'd be better as a MAY.

[CRW] MUST seems right here to me.  The protocol MUST provide a means
for recovering from loss of a TA key.  A protocol without this would not
meet the requirements.  An implementation may choose not to provide this
or a system may choose not to use it.  Replaced "source of trust anchor
information" with "trust anchor manager"

12: 3.13.1 seems to be out of scope for a TAMP since its imposing a
requirement
on the 5280 processor and not on a TAMP. Maybe change from a requirement
to a
nice bit of advice or a security consideration?  (3.13.2 also
contradicts the
"must" in 3.13.1 I think)

[CRW] A great deal of the value associated with a TAM protocol is lost
if enforcement of TA constraints is inconsistent.  I don't think this
can be omitted as a requirement.  This was discussed during the last
working group meeting.  The wording in the draft is based on some
comments from Tim (either during or after the meeting).  I think Stefan
advocated having specs require constraints to be processed, but no
general requirement.

13: I think the security considerations could usefully point out that a
TAMP
creates a nice new target to attack - if I can get at the TAM private
key or
replace the public key I can control a lot of the security stuff on the
box.
Also, if a TAM makes a mistake (e.g. a typo in an allowed name
constraint) that
creates a new accidental-DoS vector.

[CRW] OK.  

Nits:
-----

1: section 1, 1st bullet "begins a certification path" is a bit
ambiguous
depending on whether the EE or CA is first or last. Suggest rephrasing
(maybe
just say "a public key certificate" and leave it at that)

[CRW] The phrase is consistent with RFC 5280, which states that "Valid
paths begin with certificates issued by a trust anchor."  I assume you
don't want the change simply to accommodate invalid paths:-)

2: section 2, "Throughout this document, trust anchor managers are
assumed to
be represented as trust anchors." Well, in the case where an application
manages trust anchors (e.g. like a browser) that may not be true. Maybe
just
add a caveat here that other schemes are possible but aren't covered in
this
document. 

[CRW] This has been reworded in response to another comment - not
exactly this way but maybe good enough.

3: s/and etc./etc./

4: last para of section 2, s/which trust anchors/the set of trust
anchors/

5: section 3.3.1: is "TA Management" the same as "TA Manager" (the
latter is a
defined term, the former not). If so, just use one; if not, please
define the
term.

[CRW] Fixed all of the above.

7: 3.8.1 and 3.9.1 seem to overlap a bit and could maybe be simplified
(3.9.1
seems to call for everything in 3.8.1 other than replay detection)

[CRW] Will collapse these two sections.

8: I've no idea if 5280 and 5055 should be normative references for a
protocol
requirements document, but then I also don't care. However, maybe
someone else
does? :-)

[CRW] Left as-is pending comments from someone else.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Farrell
Sent: Tuesday, October 07, 2008 10:36 AM
To: [email-masked]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

Bunch of comments attached. While this version is quite close, I think
some of these do warrant changes.

Cheers,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Oct 2008 12:09:36 +0100

Hi Carl,

Thanks for those. I guess mostly I'll just peek at the next rev for
the changes. A few follow-ups below though.

S.

> [CRW] Section 3.1 has been clarified as requiring in-band integrity.

Seems ok. But I think you need to specify if use is required or
optional, i.e. the options seem to be "a TAMP MUST define in-band
integrity mechanisms," or "every TAMP message MUST use an in-band
integrity mechanism." I'd go for the former, just on the basis
that the latter is harder to state correctly (there might be some
message that's ok without in-band integrity and there could be
some deployments where transport-layer integrity is doable and
sufficient). But if you prefer the latter, I wouldn't object as
long as its clearly stated.

> [CRW] Will relax the requirement in 3.4.1 to SHOULD.

Not sure that SHOULD is right here - its a requirement that a protocol
designer has to meet, so unless you can say when its ok to not provide
delegation, then how could you judge a proposed protocol?

> advocated having specs require constraints to be processed, but no

I still don't get how you'll judge this when presented with a proposed
protocol and hence still think this is better as a security
consideration rather than present it as a requirement that a TAM
*protocol* has to meet (which it cannot).