[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-pkix
Subject:    Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
From:       Stephen Farrell <stephen.farrell () cs ! tcd ! ie>
Date:       2008-10-17 11:09:36
Message-ID: 48F87270.7090402 () cs ! tcd ! ie
[Download RAW message or body]



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.

Carl Wallace wrote:


> 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.

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.

> 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.

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?

> 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.

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).



[prev in list] [next in list] [prev in thread] [next in thread]