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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Jeff Stapleton
Sent: Monday, March 12, 2007 2:53 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: draft-stapleton-ttned-01 : Trusted Transactions for Network Enabled
Devices
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