Subject: [Gen-art] review of draft-herzog-setkey-03.txt (resent)

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Feb 2011 15:00:38 +0100

Oops, missing spelling errors...

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-herzog-setkey-03.txt
Reviewer: Francis Dupont
Review Date: 20110203
IETF LC End Date: 20110222
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: I have an ASN.1 question related to implicit tagging:
this can lead to encoding ambiguity with nested CHOICEs for instance,
it is something which could be addressed in specs, is the extension
mechanism an issue (i.e., the spec can be correct now but become
incorrect whene extended) and BTW is there a known tool to check
the syntax against this particular issue?

Nits/editorial comments:
 - ToC page 2 and 5 page 9: Acknowledgements -> Acknowledgments

 - 1.1 page 3 and 2 page 8: Becuase/becuase -> Because/because

 - 1.1 page 3: partipants -> participants

 - 1.2 page 5: futher -> further

 - 1.3 page 5: Heirarchy -> Hierarchy

 - 2 page 6 and A page 11 (twice): XX -> TBD? or TBD1/TBD2?
  (note this will be solved anyway by the assignment of a numerical
   value before publishing)

 - 2 page 7 (twice): SetKeyParticipentSet -> SetKeyParticipantSet

 - 2 page 7 (in intersection): if it is all -> if it is in all
                                                        ^^

 - 2 page 8: miniumum -> minimum

 - 2 page 8 (twice): freeform -> free form

 - 2 page 8: SubjectPublicKeyInfor -> SubjectPublicKeyInfo

 - 5 page 9: Housely -> Housley?

 - 6.1 page 10 (RFC6031): please use the 'RFC' abbrev

Regards

[email-masked]

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Thu, 17 Feb 2011 14:01:39 -0500

> Please resolve these comments along with any other Last Call comments 

Before I incorporate our proposed changes into the document, may I bounce them off of you first?

> the syntax against this particular issue?

Actually, I don't have any changes to propose in response to this, yet and I'm not sure I understand your question. I am not aware of any issues regarding extension, nor am I aware of any tools for checking for it. But I am not an ASN.1 expert. Can you expand a little more on this issue for me?  

Side note: I used IMPLICIT TAGS in this spec only because that is what is used in the main CMS ANS.1 specification (see RFC 5652). I would be happy to use another sort of tagging instead-- do you request/recommend explicit or automatic tagging instead?

> - 5 page 9: Housely -> Housley?

I had a spell-checking on while writing this, I swear! 

More seriously: I will fix all of these typos.

> - 6.1 page 10 (RFC6031): please use the 'RFC' abbrev

Will do. 

>  (note this will be solved anyway by the assignment of a numerical

I think I see the problem: I am using XX in two places to indicate two different values. I will replace these with TBD1 and TBD2 to dis-ambiguate. 

(But my understanding matches yours: these will be replaced with real numbers when published.)

Thanks.

-- 
Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:  [email-masked]
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Feb 2011 01:26:03 +0100

> the syntax against this particular issue?
   
   Actually, I don't have any changes to propose in response to this, yet
   and I'm not sure I understand your question. I am not aware of any
   issues regarding extension, nor am I aware of any tools for checking for
   it. But I am not an ASN.1 expert. Can you expand a little more on this
   issue for me?
   
=> this is something I got working on an interim version of SCVP
(RFC 5055):
with implicit tagging:

CHOICE {
  foo [0] Foo,
... }

Foo ::= CHOICE {
  bar [0] Bar,
...}

the tag 0 in a BER encoded value doesn't help you to know if it is for
Foo or Bar. BTW in the RFC 5055 you have for instance PKCReference and
ACReference CHOICEs (section 3.2.1) using different tag ranges for
IMHO this kind of reasons.

   Side note: I used IMPLICIT TAGS in this spec only because that is what
   is used in the main CMS ANS.1 specification (see RFC 5652). I would be
   happy to use another sort of tagging instead-- do you request/recommend
   explicit or automatic tagging instead?
   
=> I expected to get an answer from an ASN.1 expert. If we get
nothing this should be considered as a not justified fear.

Regards

PS: I do the implicit assumption there are ASN.1 experts
(or people knowing ASN.1 experts) in the gen-art list (:-).