Subject: draft-stapleton-ttned-01 : Trusted Transactions for Network Enabled Devices

From: "Jeff Stapleton" <[email-masked]>
Date: Mon, 12 Mar 2007 08:53:01 -0500

It is my understanding that the internet draft draft-stapleton-ttned-01
<https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14230>
was assigned to the S/MIME group in January 2007.  This document specifies a
cryptographically protected message format and transaction protocol for
managing network-enabled devices. The message format consists of a header,
content and trailers. The message header uniquely identifies the message
type. The message content is afforded (i) authentication by means of a
digital signature trailer and (ii) confidentiality by means of encryption
trailer; and the whole message (header, content, trailers) is afforded
integrity by means of a trusted time stamp trailer. All message structures
are defined using ASN.1 and all cryptographic structures use CMS. The
transaction protocol consists of request messages, response messages,
acknowledgement messages, and notification messages.  

My intent is to transition this draft to RFC status.  I would be interested
in generating some dialogue on this document, collecting comments, and
applying changes to make it a better document.  Thanks!  

Jeff Stapleton

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 12 Mar 2007 09:33:57 -0500

Jeff Stapleton wrote:
> <https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14230> was 
> assigned to the S/MIME group in January 2007.  This document specifies a 
> cryptographically protected message format and transaction protocol for managing 
> network-enabled devices. [...]

> My intent is to transition this draft to RFC status.  I would be interested in 
> generating some dialogue on this document, collecting comments, and applying 
> changes to make it a better document.  Thanks! 

I'm curious as to what you plan to achieve that's not already covered by 
SNMPv3.

-- Tim

---

From: "Jeff Stapleton" <[email-masked]>
Date: Mon, 12 Mar 2007 10:01:45 -0500

Excellent question.  The security mechanisms for SNMPv3 are in flux, and
frankly in many environments inadequate.  Further, as network-enabled
devices become more intelligent, SNMPv3 becomes strained to keep up as
application level controls and protocols are deployed.  TTNED is not
designed to replace SNMPv3, rather it is designed to provide a robust
security layer for newer management applications and for existing management
protocols, such as SNMPv3.  The SNMPv3 PDU can be encapsulated within the
TTNED envelop, and the security protections can be added.  

Basically it is an enhancement to new and existing management protocols.
Does that address your question? 
Jeff

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 9:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-stapleton-ttned-01 : Trusted Transactions for Network
Enabled Devices

was 
> cryptographically protected message format and transaction protocol for
managing 

-- Tim

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 19 Mar 2007 09:56:08 +0100

Jeff,
 
Some comments (without the WG chair hat on):
 
1. There's about 20 pages of unexplained ASN.1 in Annex A.
 
2. 2119 language is not used in the draft.  You need to capitalize MUSTs
etc.  Additionally, language like "typically, the certificates and crls
components of type SignedData are not present" is not used it's usually
"Certificate and crls are OPTIONAL."  I actually think this will result in a
substantial rewrite.
 
3. In Section 2.2: Indicate that either encrypted or identity must be
present in Trailer.
 
4. In Section 3.4: Domain has all the same choices as GeneralName (from
RFC3280) why not use that syntax?  Well okay so you added
univeralUniqueIdentifier .. why isn't that an otherName?
 
5. In Section 5.1:
 - 5.a Need to indicate whether or not unprotectedAttrs are supported.
 - 5.b What is the content type(s) that goes in encapContentInfo?  I think
you need to define the transaction types as a content type or say you're
using one that is already defined.
 - 5.c OriginatorInfo is not the same as that in CMS, how is this going to
work?
 - 5.d What if somebody wants to use kari?
 - 5.e What are the algorithms that are required to be supported?
 
6. In Section 5.2: 
 - 6.a You prohibit signed and unsigned attributes but CMS requires some
(e.g., message-digest, content-type).  Seems like this would cause a generic
CMS implementation issues because of these required attributes.
 - 6.b What is the content type(s) that goes in encapContentInfo?  I think
you need to define the transaction types as a content type or say you're
using one that is already defined.
 - 6.c What are the algorithms that are required to be supported?
 - 6.d I think you have to explain the signature process/digest process: is
it just over the header, body, etc.?
 
7. In Section 5.3: I would probably add "in some scenarios/environments" to
the end of the 1st sentence in 5.3.  If I had a secure network with a trust
time source and used a signing-time attribute it may be good for the lawyers
;) 
 
8. In Annex B: Why is VisableString used instead of UTF8 or other types more
similar to RFC3280?   (hate to characterize it this way but isn't
VisableString one of the more obscure choices?)  Many of the name types
(e.g., URI) are already defined in 3280 and the string types don't match.
Why won't this cause a problem?
 
These are just the ones that popped off the top of my head during a quick
scan of the draft.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jeff Stapleton
Sent: Monday, March 12, 2007 2:53 PM
To: [email-masked]
Subject: draft-stapleton-ttned-01 : Trusted Transactions for Network Enabled
Devices 

Jeff Stapleton