Session Initiation Protocol (SIP) Torture Test Messages
draft-ietf-sipping-torture-tests-09

Mail from Robert Sparks 9/16 noting that the Editor Cullen just had a baby so that will delay
the rev, but:

addressing Russ' concerns with the torture test draft:

- Cullen and Eric have looked at openssl and Eric thinks the required
  changes to that library are doable. If this hasn't been done already, it will
  be the first time Cullen and Eric have a few minutes to sit together. The path to
  getting a correctede xample message has been charted and looks manageable.

[Eric  = Eric Rescorla]

[We're tracking the delay - it's not a black hole, but a lot of delay.  The benefit is
that there's a tarball on the document, so this isn't  just going to result in
a cosmetic example, the signature does get used in testing]

[Ballot discuss]
I decoded the CMS SignedData structure in section 3.1.1.11, and it
  contains a few things that surprised me.

    - The encoding of the SHA-1 algorithm identifier is valid, but
      it is not the preferred form.  The preferred form omits the
      NULL parameters as is clearly stated in RFC 3370 in section 2.1,
      which says: "Implementations SHOULD generate SHA-1
      AlgorithmIdentifiers with absent parameters."

    - The S/MIME Capabilities advertise support for Triple-DES-CBC,
      RC2-128-CBC, RC2-64-CBC, RC2-40-CBC, and DES-CBC.  The last two
      algorithms are clearly deprecated.  I would like to see AES in
      this list.  RFC 3853 requires SIP support for AES.

  This signature cannot be properly validated without the trust anchor
  for the certificate issuer (OU=Sipit Test Certificate Authority,
  O=sipit, L=San Jose, ST=California, C=US).  The RSA public key is
  needed to validate the signature on the certificate.

[Ballot discuss]
I decoded the CMS SignedData structure in section 3.1.1.11, and it
  contains a few things that surprised me.

    - The encoding of the SHA-1 algorithm identifier is valid, but
      it is not the preferred form.  The preferred form omits the
      NULL parameters as is clearly stated in RFC 3370 in section 2.1,
      which says: "Implementations SHOULD generate SHA-1
      AlgorithmIdentifiers with absent parameters."

    - The S/MIME Capabilities advertise support for Triple-DES-CBC,
      RC2-128-CBC, RC2-64-CBC, RC2-40-CBC, and DES-CBC.  The last two
      algorithms are clearly deprecated.  I would like to see AES in
      this list.  RFC 3853 requires SIP support for AES.

    - The validity period in fluffy's certificate has not begun yet.
      The certificate will not be valid until 12/04/2005 17:19:38 GMT.

  This signature cannot be properly validated without the trust anchor
  for the certificate issuer (OU=Sipit Test Certificate Authority,
  O=sipit, L=San Jose, ST=California, C=US).  The RSA public key is
  needed to validate the signature on the certificate.

[Ballot discuss]
This signature cannot be properly validated without the trust anchor
  for the certificate issuer (OU=Sipit Test Certificate Authority,
  O=sipit, L=San Jose, ST=California, C=US).  The RSA public key is
  needed to validate the signature on the certificate.

  I decoded the CMS SignedData structure in section 3.1.1.11, and it
  contains a few things that surprised me.

    - The encoding of the SHA-1 algorithm identifier is valid, but
      it is not the preferred form.  The preferred form omits the
      NULL parameters as is clearly stated in RFC 3370 in section 2.1,
      which says: "Implementations SHOULD generate SHA-1
      AlgorithmIdentifiers with absent parameters."

    - The S/MIME Capabilities advertise support for Triple-DES-CBC,
      RC2-128-CBC, RC2-64-CBC, RC2-40-CBC, and DES-CBC.  The last two
      algorithms are clearly deprecated.  I would like to see AES in
      this list.  RFC 3853 requires SIP support for AES.

    - The validity period in fluffy's certificate has not begun yet.
      The certificate will not be valid until 12/04/2005 17:19:38 GMT.

[Ballot comment]
No tests related to IPv6 addresses, as far as I can
see. Since IPv6 address contain colons and there are colons
in SIP syntax, it might be as well to torture implementations
in this area too.

Reviewed (but forgot to put into AD Evaluation state).  The working group did a lot of
review of this, with explicit review tokens assigned.  I think it is carefully done.