Dear Mr. Okubo, Thank you for your review and comments. Some of your editorial comments I have previously noticed, many I had not and I will attempt to address them. I have included my responses where appropriate, below. Best Regards, jimt. At 07:29 PM 8/27/97 JST, you wrote:

Dear Jim,

I had a chance to read (actually look) through APC-1191 (Hertzlia meeting document) and found some presumable editorial errors as attached from a bystander perspective. This might be too late for your Sunriver input, but I hope it would be of some use for your further editing. { } indicates my thoughts.

I have a couple of questions other than THE editorial comments for my understanding.

1) General

H.235 seems to be handling only media by media encryption. The case of encrypting H.222.1 multiplexed stream or H.223 multiplexed stream is also covered by the current specification? Or can it be part of the future H.235 extension?

The current H.235 only covers logical channel oriented encryption. The intent was to adopt other methods for other H series terminals. Section 14 is a place holder for H.324. The initial possibility there, was to allow for a secure adaptation layer to be provided above the H.223 MUX. This could be used to swap the modes to either simulate the 'per channel' encryption or provide the entire MUX encryption. In any case, I believe this area would benefit from further work, and perhaps some additional Annexes.

2) Section 9.2, nonIsoMediaEncryptionAlgorithm ::=CHOICE Section 13.3.5, nonIsoIdAlgorithm ::=CHOICE

We have three such non-ISO algorithms specifically listed. Is this the policy we confirmed? Are we going to list all of proprietary algorithms one by one in H.235 (or H.225.0, H.245)? Or are they identified in non-standard ways?

This has been changed to incorporate all algorithms (whether they be 'standards body' registered or completely proprietary) by utilizing a generic object identifier. This method removes the ITU-T from any awkward position of deciding which algorithms to include/exclude.

3) Section 9.2, ASN.1 syntax

H.245 syntax has a top-down structure, but here it looks bottom-up. {Perhaps either way is alright for encoding and decoding?}

Much of this has be re-worked to facilitate the cryptographic functionality needed within ASN.1. The general intent was to allow for an association between specific codecs (modes/media) and specific security mechanisms.

Best regards,

Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo@gctech.co.jp 151 Japan ********************************************************************

Source: Sakae Okubo Title: Ecitorial comments on APC-1191 Draft H.235 Date: 27 August 1997

1. Contents

title of 13. ==> H.323 SPECIFIC TOPICS title of 14. ==> H.324 SPECIFIC TOPICS

2. Section 2, Item 4

The last sentence "This may include both the number of secured users and the levels of security provided." is duplicated.

3. Section 2, Item 6

Period is missing at the end.

4. Section 7.1, Items IV. and V.

OpenLogicalCahhnel, OpenLogicalChannelAc, EncryptionUpdateRequest, EncryptionUpdate ==> in bold {?}

5. Section 7.1.3, second sentence

on a channel by channel basis ==> on a logical channel by logical channel basis {?}

6. Section 7.2, 2nd paragraph, 4th sentence

the card is always may always be ==> one of them should be deleted {may be due to my reading the document on Mac Word}

7. Section 7.2.1, 2nd paragraph

H.Secure ==> H.235

8. Section 7.5, 1st paragraph, "any entity which terminates a call control channel (H.245) "

{There are several places where "call control" is associated with H.245, but Q.931/Q.2931 is more appropriate for the call control. H.323 says H.245 control, call control H.225.0 and RAS control H.225.0 as part of the system control in Figure 4. So, H.245 control channel may be the replacement, otherwise communication control may be the choice according to the title of Rec. H.245.}

9. Sections 7.5.2 and 7.5.3

They should be transposed {?}

10. Section 8.1, 1st paragraph

See #8.

11. Section 9.1, 1st paragraph

The first sentence needs a period at the end.

12. Section 9.1, 2nd paragraph

"scope (in italic)" is used with a security specific meaning. I would suggest this should appear in Section 4 Definitions. We have general "scope" in other places.

13. Section 9.3, 2nd paragraph, 2nd sentence

It is hard to understand this sentence; notions of "inclusive and exclusive" and "encrypted codes" in particular.

14. Section 11.1, 3rd sentence

I cannot find "prepend" in my dictionaries.

15. Section 11.3, overall

The style is something like a discussion contribution. We need to change it to that of specification.

15. Section 11.3, Item I. A. Initialization vectors, 2nd last sentence

What is "B" octets?

16. Section 11.3, Item I. B. Padding, 2nd paragraph, "Two methods are proposed to handle packets ..."

"proposed" is strange in Recommendation.

17. Section 11.3, Item I. B. Padding, 4th paragraph

There is a spurious period.

18. Section 11.3, Item I. B. Padding, 5th paragraph

- H.Secure ==> H.235 - "It is recommended that all H.Secure implementations must support ..." must ==> should {?}

19. Section 11.3, Item I. B. Padding, 5th paragraph

What is "P" bit? See also #15.

20. Section 11.3, Item Stream Algorithms

The item number ==> II.

21. Section 11.3, after Item II. A. (spurious)

and if the performance problem is not deemed to be exist, it should not be included. ==> to be existing, or to exist

22. Section 13.1, Figure, TLS/SSL

SSL is striked out in Section H.245Security. If it is valid, it should appear in Section 5. Symbols and Abbreviations.

23. Section 13.3.1, 2nd paragraph, 2nd sentence

The intent (as stated in section 7.2) is to not provide absolute, ==> is not to {?}

24. Sections 13.3.2, 13.3.3, 13.3.4

There are several "shared secret" in this section. ==> shared secret key {?}

25. Appendix B, 3rd paragraph

SSL appears. See #22.

26. Appendix E, 1st paragraph

"call control" appears. See #8.

27. Appendix E, 2nd and 3rd bullets

TLS/SSL appears. See #22.

28. Appendix E, Item III. Call Control (H.245)

See #8.

29. Appendix E, Item 1b), 3rd sentence

Some of the RAS messages are multicast by definition, and as such is would be impractical to make confidential. ==> either of "is" or "would be" is spurious.

30. Appendix E, Item 1b), 4th sentence

Call establishment messages are currently carried on UDP (unreliable) transport Possible solutions ... ==> Call establishment messages are currently carried on UDP (unreliable) transport. Possible solutions ...

31. Appendix E, Item 1c)

H.Secure ==> This Recommendation, or H.235

32. Appendix E, Item 1c), last sentence

... using a "per-message randomization" in section Non-registration RAS signaling 13.3.4. ==> ... using a "per-message randomization" in section 13.3.4 Non-registration RAS signaling. {?}

33. Appendix E, Item 3a)

... as provide in TLS/SSL. ==> ... as provided in TLS/SSL.

See also #22.

34. Appendix E, Item 3b)

Bystanders able to snoop media encryption algorithms and keys exchanged by participants loss of 4b, 4c and 4d. ==> Some words are missing between participants and loss {?}

35. Appendix E, Item 4c)

Denial of service attack if bystanders, 'scramble' data. ==> the comma is unnecessary {?}

36. Appendix E, Item 4c), last sentence

Integrity servies for media data is ... ==> Integrity service for media data is ... or Integrity services for media data are ...

37. After Appendix F

There are five definitions. These should be moved to Section 4. Or are they a part of Appendix F?

---------< Thank you for your attention. >---------

************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************