|
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
It is my understanding that the internet draft draft-stapleton-ttned-01
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
|