1 / 51

Comments for EESSI/CEN Draft Standards

Comments for EESSI/CEN Draft Standards. 7Apr2003 Japan PKI Forum China PKI Forum. Table of Contents. Restrictions of Comments Comments (1-45) Annex Requests. Restrictions of Comments. It is the voluntary (No authorized) comments sent from the following; - Members of Japan PKI Forum

karik
Download Presentation

Comments for EESSI/CEN Draft Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Japan PKI Forum Comments forEESSI/CEN Draft Standards 7Apr2003 Japan PKI ForumChina PKI Forum

  2. Japan PKI Forum Table of Contents Restrictions of Comments Comments (1-45) Annex Requests

  3. Japan PKI Forum Restrictions of Comments It is the voluntary (No authorized) comments sent from the following; - Members of Japan PKI Forum - PKI related organizations in Japan - China PKI Forum Although notified to the Asia PKI Forum, due to the limit time and large amount of documents, many members (Korea, Singapore, Chinese Taipei, Hong Kong, China, Macao, India) were not able to respond.

  4. Japan PKI Forum Comments (1/45)TS101733 #1 P49,P67,P76 "OPTIONAL" should be described after [2] OtherRevVals marked ****. RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL otherRevVals [2] OtherRevVals **** }

  5. Japan PKI Forum Comments (2/45)TS101733 #2 P16, P17 Timestamp seem unnecessary in ES-X Type1 and ES-X Type2, since ES-X-L is enough. These two should be deleted to avoid being complicacy of specifications.

  6. Japan PKI Forum Comments (3/45)TS101733 #3 8.9.1 Signature policy is made mandatory in the specification, while it is felt necessary to specify a mechanism that allows dynamic policy referencing, which is presently lacking. At the same time, it is preferable that there is a method to link policy inside signature and that outside signature data .

  7. Japan PKI Forum Comments (4/45)TS101733 #4 11.1 As a part of the policy source protection, we feel it is necessary to consider signature of the signature policy itself, not just its hash value.

  8. Japan PKI Forum Comments (5/45)TS101733 #5 11.11 As the use case demand for the signature policy extension is deemed to increase, it would be nice to have a concrete specification of extension instances as has been done in X.509 certificate profile standard (RFC3280).

  9. Japan PKI Forum Comments (6/45)TS101733 #6 5.4.2 “CRI Information” may be a spelling mistake for “CRL Information”

  10. Japan PKI Forum Comments (7/45)TS101733 #7 5.4. 5 and 5.4.7 The same clause title “Timestamping for long life of signature”

  11. Japan PKI Forum Comments (8/45)TS101903 #1 P17 Timestamp seems unnecessary in XAdES-X, since XadES-X-L is enough. This should be deleted to avoid being complicacy of specifications.

  12. Japan PKI Forum Comments (9/45)TS101903 #2 It makes sense that signature format, which is designed to incorporates signature policy, is defined in terms of XML, when considered that the worldly policy standards, like SAML, XACML, WS-Security, are specified at the same processing layer using XML. In this sense, it would be preferable (if not normatively, but informatively) for the present standard to investigate its practicable interoperability with these policy related standards.

  13. Japan PKI Forum Comments (10/45)TS101903 #3 Relative to ETSI TS 101733 ES Formats, a profile of XML long term signature format was introduced assuming a similar use of CMS SignedData last year. Relative to Japan e-Government, Electronic applications are specified to be XML based documents and XML signature will be in use. In this case, XadES matches well than ASN.1 based TS 101733 from the point of view of long term signature save. To diffuse the use of XadES, test programs for interoperability should be implemented. Some errors are pointed out in some parts of XadES schema so that bug information should be opened to public promptly. The manual of XML time-stamping used in this specifications should be described soon after OASIS standard formulation.

  14. Japan PKI Forum Comments (11/45)TS101456 #1 P10 In “4.3 Certificate policy and certification practice statement”, will it be better to add the specifications of the relations between them and the cross authentication?

  15. Japan PKI Forum Comments (12/45)TS101456 #2 P18 “7.2.4 Key escrow”, how to handle the problem of “legal monitor” in the wireless communications?

  16. Japan PKI Forum Comments (13/45)TS101456 #3 P18 In “7.2Public key infrastructure - Key management life cycle”, why it doesn’t mention the operation of “certification authority key update” like the protocols in PKIX?

  17. Japan PKI Forum Comments (14/45)CWA14167-1,-2 #1 “Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures” has two parts, one is security requirement and the other is MCSO-PP, which is based on CC, why the first part doesn’t use the same specification method to produce a PP like “the Certificate Issuing and Management Components Family of Protection Profiles Version 1.0”. If do so, the two parts will look more like a whole.

  18. Japan PKI Forum Comments (15/45)CWA14172-2 #1 P8 It should be shown the source of the requirements for qualification or a numerical value. Is it quotation from other EU directives ?

  19. Japan PKI Forum Comments (16/45)CWA14172-2 #2 P212 ・An interval of audits should be written (for example, every year) clearly. ・It should be specified about the notice concerning the CA termination.

  20. Japan PKI Forum Comments (17/45)CWA14172-3 #1 P11 It should be shown the source of the requirements for qualification or a numerical value.

  21. Japan PKI Forum Comments (18/45)CWA14172-3 #2 P11Figure1 Is there any case where the product which accredited of ITSEC is investigated? If so, what kind of case is it?

  22. Japan PKI Forum Comments (19/45)TR102038 #1 To describe about OCSP trust condition, both in CommonRules and CommitmentRules element schema, add following element <xsd:element name=”OCSPTrustCondition” type=”OCSPTrustConditionType” minOccurs=”0”/> This addition should apply on signature policy section of TS 101 733 in same syntax.

  23. Japan PKI Forum Comments (20/45)TR102041 #1 8.3.1 Signature validation policy In this section, the Reports describe two types of commitments, which are Common Rules and Commitment Rules. However, meaning difference between these rules are little bit understandable. It is helpful for us if you explain some example of these Rules, especially commitment rules. Also in this section, description “trust conditions for user certificate, timestamps and attributes” should be added OCSP responder’s trust conditions.

  24. Japan PKI Forum Comments (21/45)TS102041 #2 8.3.2 Signature validation information Revocation Requirements Please add CRL Distribution points not only full CRLs.

  25. Japan PKI Forum Comments (22/45)CWA14170 #1 4 ABBREVIATIONS "SCS" should be added to the list.

  26. Japan PKI Forum Comments (23/45)CWA14168 #1 Is it possible to define two or more TOE(s) by one PP? If impossible, Should ID is divided separately?

  27. Japan PKI Forum Comments (24/45)CWA14169 #1 5.1.1.2 - The sentence could be read that “Destruction of a private key is performed only at the time of renewal ”. Isn't there any case that a private key is destroyed except renewal? - The sentence could be read that “The number of the private keys which can record SSCD is only one”. May not SSCD record two or more private keys?

  28. Japan PKI Forum Comments (25/45)CWA14171 #1 4.2 "However, it is recommended to support one of the three following ways that allow to make sure that the signature policy is genuine." -> There are no detail descriptions of "three following ways". "Using trusted Repositories for registered security policies", "Using a trusted media" and "by placing them on a secure web site" described in chapter 4.3 are supposed to be the "three ways" but it is not clearly mentioned.

  29. Japan PKI Forum Comments (26/45)CWA14171 #2 6.1/6.2/6.2.1.3 "A display/sound/video interface to present (e.g. display, listen to or visualize) the signer's document with the right format" -> It is not clear that which description in a figure matches this description. It seems that the description represents "Interface to present the signed user data". If so, the description both in body and in figure should be the same.

  30. Japan PKI Forum Comments (27/45)CWA14171 #3 6.1 "Interface to present the Signature Policy" in a figure ->There is no descriptions of "Interface to present the Signature Policy" in body of 6.1.

  31. Japan PKI Forum Comments (28/45)CWA14171 #4 6.1/6.2 Arrows from "Initial Verification Process" (6.1) and "Usual Verification Process" (6.2) in figures ->It is not easy to recognize which explanation goes to which arrow. For "Interface to present the signed user data" in figures, there are different explanations in 6.1 and 6.2, such as Content-format (6.1) and Content-type (6.2).

  32. Japan PKI Forum Comments (29/45)TS102023 #1 4.2 It should be clearly defined the TSA’s key. Because readers cannot distinguish if it is TSA’s key or TSU’s key.

  33. Japan PKI Forum Comments (30/45)TS102023 #2 4.2 We propose to describe a restriction on key backup. E.g. “TSA’s key should not be cloned”

  34. Japan PKI Forum Comments (31/45)TS102023 #3 7.1.2 d) Readers easily understand “The expiration date of the time-stamp token, TSA assured,”

  35. Japan PKI Forum Comments (32/45)TS102023 #4 7.1.2 J) “See clause 7.4.10” is wrong. “See clause 7.4.11” is right.

  36. Japan PKI Forum Comments (33/45)TS102023 #5 )7.2.1 b) FIPS140-2 is also required.

  37. Japan PKI Forum Comments (34/45)TS102023 #6 7.2.2 a) FIPS140-2 is also required.

  38. Japan PKI Forum Comments (35/45)TS102023 #7 7.2.2 b) Following note is needed. Note: When the backup key is recovered, the TSA needs to assure that it does not use previously used serial numbers in the TSTs for new TSTs.

  39. Japan PKI Forum Comments (36/45)TS102023 #8 7.2.4 NOTE 1: “See clause 7.4.10” is wrong. “See clause 7.4.11” is right.

  40. Japan PKI Forum Comments (37/45)TS102023 #9 7.3.1 e ) Following measure is needed. If the TSA’s clock has been out of the stated accuracy and TSTs were issued before it was detected, the TSA shall revoke the TSTs

  41. Japan PKI Forum Comments (38/45)TS102023 #10 7.3.2.a) The TSA also needs to show to users how it can prove its clock’s correctness. For instance, The TSA shall keep and show tractability and authenticity to UTC as its time source to users. An investigation of guideline is required.

  42. Japan PKI Forum Comments (39/45)TS102023 #11 7.3.2 d) We believe that “the TSA should not issue time-stamps when it is processing for a leap second”. Some investigation of guideline is required.

  43. Japan PKI Forum Comments (40/45)TS102023 #12 7.4.8 It should be provided a way of how to deal with issued TSTs in the following cases. 1. Compromise of the TSA’s signing key 2. Detected loss of calibration

  44. Japan PKI Forum Comments (41/45)TS102023 #13 7.4.8 c) There will be possibility that TST is issued after compromise occurred and it cannot be detected for a while. So we believe that when such cases happened the TSA need to show information of it to relying parties and subscribers. (E.g. by time-stamps revocation list) Some investigation of guideline is required.

  45. Japan PKI Forum Comments (42/45)TS102023 #14 Referring to ETSI TS 102 023, as examples of a specific TSA policy, two operation regulations were created in FY2002 report, "Time-stamping usage guideline". 1. Example of time-stamping service operation regulation using simple protocol 2. Example of time-stamping service operation regulation using linking protocol Also in "Time-stamping usage guideline", the important matters on use of time-stamping were summarized. Here we discussed about "Time Authentication" which is not specifically described in the above ETSI TS. A time-stamp token issued by TSA should have the correct time but the token does not have a mechanism to prove that the token itself uses a reliable time source to guarantee the time accuracy. The time included in time-stamp token that TSA insist the accuracy should link to the national standard time based UTC and there should be a mechanism to guarantee the accuracy.

  46. Japan PKI Forum Comments (43/45)TS101861 #1 5.1.2 Please add “One of “ to the beginning of the sentence, because the sentence uses “must”.

  47. Japan PKI Forum Comments (44/45)TS101861 #2 5.2.3 Please add “One of “ to the beginning of the sentence, because the sentence uses “must”.

  48. Japan PKI Forum Comments (45/45)TS101861 #3 This profile is appropriate for common use of time stamp.

  49. Japan PKI Forum Annex The thesis about the comments of TS101733 (#3,#4,#5) and TS101903 (#2) is attached.

  50. Japan PKI Forum Requests Japan PKI Forum is waiting for the following; #1 The report of how to have treated these comments. #2 The schedule and related information of EESSI in the future. Regarding XadES, Japan PKI Forum have hard that ETSI are having an interoperability event in June. Please provide us with the following information; #1 Contact Person. #2 Discussion Agenda #3 Experiment Method #4 #5

More Related