Just to clarify a bit further, issues 1 and 2 are on the use of ASN
and the proposed responses for (1) and (2) together address those issues.
Lakshminath
At 01:59 PM 1/23/2006, Lakshminath Dondeti wrote:
Hi Brian and Scott,
Please review the following notes to see if they address your
concerns on the MSEC Policy Token draft. Thanks to Russ for helping
Andrea and Uri craft some of the responses.
Please look for <Res></Res> below (there is one <LD></LD> below,
please ignore that for now; it is related to an IANA concern).
thanks and regards,
Lakshminath
At 01:31 PM 1/23/2006, Lakshminath Dondeti wrote:
1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a
number of choices and structures that seem like they are intended to
be extended in the future. Without extensibility markers, a
conforming implementation will reject a sequence or choice with
elements not permitted by the abstract syntax.
<Res>
The EXPORTS statement is to be removed so that any structure def can be
exported.
</Res>
2) There is no extensibility or versioning strategy described in the
document. How do we add fields? What should recipients of a token do
if they do not understand part of it?
<Res>
A Policy Token version indicator is to be added to the TokenID.
</Res>
<Res>
Russ provided the following example that we might use:
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
....
Version ::= INTEGER { v1(0), v2(1), v3(2) }
</Res>
<Res>
"Implementations encountering unknown protocol identifiers MUST handle
this gracefully by providing indicators that an unknown protocol is among
the sequence of permissible protocols. If the unknown protocol is the only
allowable protocol in the sequence, then the implementation cannot support
that field and the member cannot join the group.
It is a matter of local policy whether a join is permitted when
an unknown protocol exists among other allowable, known protocols."
</Res>
The above will be added to provide
handling instructions when encountering unknown protocols.
<Res>
Under the main token structure it will say that additional protocols
SHOULD NOT be added unless the MSEC architecture changes.
</Res>
3) It's not clear that the GSAKMP document combined with this document
provides enough mandatory to implement features that any two
implementations of this specification will work together. The GSAKMP
document specifies mandatory to implement mechanisms for GSAKMP.
However the policy token allows for a wide variety of combinations of
protocols. For example, a policy token could specify one protocol for
registration, one protocol for rekey, and a completely different
protocol for de-registration. If only one of these is GSAKMP, what
happens? Where is it specified what combinations a GM, a GC/KS etc
must support in terms of policy token contents?
<Res>I understand the issue, but the token's purpose is to tie the
abstract MSEC
architecture to a configurable system. The MSEC architecture allows for any
of these protocols for registration, de-registration, etc. and does not
specify what the mandatory to implement protocols are. To say that the
appendix B and appendix C protocols are the mandatory-to-implement protocols
would mean that the MSEC architecture now requires those protocols. This is
one case where I believe a mandatory to implement scheme would be a
disservice to the community.
Interoperability testing for the token, really becomes system
interoperability testing vs. protocol interoperability testing.
</Res>
4) IANA Comments:
The IANA Considerations section requests that 13 object identifiers
be assigned.
In which registry should these be assigned? IANA needs clarification.
<Res>
Statement to IANA section will essentially say that the spec is extended
through specification. Those specifying new objects will register them with
IANA. Those that change the structure of the PT must change the version
indicator.
</Res>
<LD>
The resolution does not address the question on "which registry"
should be used. I think this requires a new registry, right?
</LD>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
