Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
RFC 5698

Note: This ballot was opened for revision 12 and is now closed.

(Tim Polk) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-06-16 for -)
No email
send info
I don't understand this bullet item from the list in section 5.1:

   o  Time of interest (optional).  Providing no time of interest means
      determination of the validity end date of algorithm.

Also, as a clarification, do I understand correctly that the time of interest is an absolute time identifying the time for which the algorithm policy is to be evaluated?

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2009-06-17 for -)
No email
send info
Call me a pedant, but in the Abstract...
   Since cryptographic algorithms can become weak over the years
This is poorly worded. I don't believe the algorithms change in any
way. It may be discovered that they were always weak.


Code fragments appear to be missing license terms.
RFC Editor will pick this up, but you can save the IETF money by 
making the changes now.

(Russ Housley) (was Discuss) No Objection

Comment (2009-08-18 for -)
No email
send info
Miguel Garcia noticed a problem with the XML schema in Appendix B:

Locate the "EvaluationType" element, towards the end of page 31.
The text reads:

    <xs:complexType name="EvaluationType">
        <xs:element ref="dssc:Parameter" minOccurs="0"
        <xs:element ref="dssc:Validity"/>
        <xs:any namespace="##other" minOccurs="0" minOccurs="0"/>

Notice the duplication of "minOccurs" attribute in the "xs:any" element. So please, delete one of the duplicated minOccurs attributes.

Once this error is fixed, the XML schema and the example correctly validates.

(Alexey Melnikov) (was Discuss) No Objection

Comment (2009-09-27 for -)
No email
send info
Updated as per revision 11 of the draft:

I think it would have been better if the document said in section 3.1 that the "lang" attribute applied to all human readable text, including Information and Usage.

In Section 7:

  7.  The policies described in this document are suitable to evaluate
       basic cryptographic algorithms, like public key or hash
       algorithms, as well as cryptographic schemes (e.g. the PKCS#1
       v1.5 signature schemes [RFC3447]).  But it MUST keep in mind that

What is "it" referring to here?

       a basic cryptographic algorithm that is suitable according to the
       policy, does not necessarily mean that any cryptographic schemes
       based on this algorithm are also secure.

In Section 8:

      Type name: application

      Subtype name: dssc+der

      Required parameters: none

      Optional parameters: none

      Encoding considerations: binary

I think it would have been much better to say here something like the following:
 The content of the media type is binary, so it needs to be encoded using a 7bit-safe content transfer encoding when sent over a non-8bit-clean
transport such as SMTP.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Comment (2009-06-18 for -)
No email
send info
I also had concerns with the text in the second sentence of the first paragraph of section 5.2 (covered in Pasi's discuss). I'd also like to see some information on when its appropriate to violate the SHOULDs in that paragraph.

Given that the document anticipates new elements (particularly Parameters), please consider a registry for the schema and its extensions.