Subject: [Gen-art] Gen-ART review of draft-ietf-smime-3278bis-07.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 27 May 2009 11:45:25 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-smime-3278bis-07.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 27-May-2009
IETF LC End Date: 28-May-2009

Summary: The document is almost ready for publication as Informational 
RFC. There are a number of minor/nits comments.

Comments:

- In Section 7, I am missing a normative reference to ASN.1. Probably 
this is either [X.680] or the same reference used by 
draft-ietf-smime-new-asn1:

    [ASN1-2002]
               ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and
               X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.

- Similarly, in Section 7.1.1 there should be normative references to 
SHA1-, SHA-224, SHA-256, etc.

- There are a number of notes at the end of Sections 7.1.2 and 7.1.3. 
These notes, contains a normative text (the word OPTIONAL). I believe a 
note should be informative in nature, thus, it should not contain 
RFC-2119 reserved words. Perhaps the text should be promoted outside a note.

- Section 7.1.3, the text mentions ECDSA with SHA-1, ECDSA with SHA-224, 
etc... Is there a reference to add here? The same question is applicable 
to Sections 7.1.4, 7.1.5, etc. Even Section 8. I believe all these should 
be normative references.

- Honestly, I didn't understand the IANA Considerations section. I don't 
undersetand if IANA needs to take an action or not, and if it needs to do 
it, which is the registry they should act upon and which values they 
should assign. This should be clarified.

Cheers,

       Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Sean Turner <[email-masked]>
Date: Wed, 27 May 2009 16:32:34 -0400

Miguel,

Thanks for the review.  Responses inline.

spt

>               X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.

I changes 7 to be: The ASN.1 syntax [X.680], [X.681], X.682], [X.683]
used in this document is gathered in this section for reference purposes.

> SHA1-, SHA-224, SHA-256, etc.

The last sentence in 7.1.1 provides the references.  While [CMS-ALG] and
[CMS-SHA2] aren't the algorithm specifications, they do provide
algorithm conventions and then point to the appropriate FIPS.  Is this
acceptable?

> RFC-2119 reserved words. Perhaps the text should be promoted outside a 

I removed "NOTE:" from the last paragraph in 7.1.2 and 7.1.3.

> to Sections 7.1.4, 7.1.5, etc. Even Section 8. I believe all these 
> should be normative references.

The last sentence in 7.1.3, 7.1.5, and 7.1.6 provides the references for
the algorithms.  While references aren't algorithm specifications, they
do provide conventions and then point to the appropriate FIPS/RFC.  Is
this acceptable?

References definitely missing from 7.1.4.

For section 8, I've got to ask if I need to sprinkle the
references after each algorithm OID/name if they're already in section 7?

> undersetand if IANA needs to take an action or not, and if it needs to 
> do it, which is the registry they should act upon and which values they 

I had this wrong.  The Arc isn't delegated from IANA it's delegated from
RSA.  I clarified this, the # of OIDs we needed, and who does the
registrations (note that Russ Housley has acted as the SMIME WG 
Registrar).  It now says:

This document makes extensive use of object identifiers to register 
originator public key types and algorithms. The algorithm object 
identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, and 
SECG arcs. Additionally, object identifiers are used to identify the 
ASN.1 modules found in Appendix A (there are two). These are defined by 
the SMIME WG Registrar in an arc delegated by RSA to the SMIME Working 
Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
smime(16) modules(0).  No action by IANA is necessary for this document 
or any anticipated updates.

Clearer?

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 29 May 2009 09:22:10 +0200

Hi Sean:

Some comments below

> algorithm conventions and then point to the appropriate FIPS.  Is this

Probably yes. I will let your own judgment decide. The key point here is 
that someone should be able to trace back to the precise specification 
that defines an algorithm. Whether the trace back is done directly or 
indirectly, I think is less important.

>> - Section 7.1.3, the text mentions ECDSA with SHA-1, ECDSA with 
>> SHA-224, etc... Is there a reference to add here? The same question is 
>> applicable to Sections 7.1.4, 7.1.5, etc. Even Section 8. I believe 
>> all these should be normative references.
> 

Same as before, I believe it is acceptable, providing it is possible to 
trace to the normative specs of references.

> references after each algorithm OID/name if they're already in section 7?

Ok.

> 
>> - Honestly, I didn't understand the IANA Considerations section. I 
>> don't undersetand if IANA needs to take an action or not, and if it 
>> needs to do it, which is the registry they should act upon and which 
>> values they should assign. This should be clarified.
> 

I think so.

Thanks,

        Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain