Re: draft-housley-ct-keypackage-receipt-n-error-00

Russ,

Here you go.

1.  What is SIR - not defined

2.  Is it your expectation that name types which do not have ASN.1 values
are going to be created?  If not then why is there an OCTET STRING wrapper
for nameValue.  This choice should be justified in the document.

3.  Should you define a relationship for relating nameType and nameValue
information?  Automated packages would find it useful, it also makes the
fact that you are use Name rather than possibly GeneralName explicit in the
module.

4.  You should probably give a reference to where signed, authenticated and
content attributes are found.  I am familiar with the first two since I do a
lot of CMS work, however the last one really needs to be tied to an RFC and
a specific content type.

5.  Can the key package identifier and receipt request attribute have
multiple values or is a single value attribute?

6.  We can rehash this discussion.  First I don't see any reason for
incrementing the version number unless you are going to re-assign the same
OID for the new structure as you did for the old one.  If a new OID is used
there is more than enough information to distinguish between the two
different structures.  Second, I am not a fan of assigning version numbers
to these structures because they do not help any encoding/decoding systems.
The structure will be encoded or decoded based on the ASN and not on the
version number.

7.  What is the purpose of the (1..MAX) on the definition of KeyPkgVersion.
Are you just trying to say that it cannot be a negative value?  It would be
more helpful if you used a smaller version such as 2^32-1 so that a compiler
would know that it fit into an int32 value.  I would also note that this is
a change from the old definition of the field in RFC 6031

8.  Is there a requirement that systems should accept
KeyPkgIdentifier.attribute values that they do not understand as it can be
reflected in the receipt without having to decode it?

9.  Why is there a requirement that the content types have to be encoded
using the DER rules?  This is not a general requirement imposed by CMS and
therefore needs some justification text.

10.  I find the field names errorOf and errorBy to be obtuse - but that is
not a strong reason to change them if they have a meaning that is not
documented.

11. does badContentInfo apply to embedded content types (i.e. eContent) as
well as the ContentInfo structure?

12.  Why should there be a problem with having more than one entry in the
digestAlgorithms field?  I can potentially understand complaining if there
is one that is not understood but not if there is more than one.

13.  I must have missed the rule that says that there is a problem if you
have a signed attribute that is unknown and not ignored.  Is that part of
the badSignedAttrs field or is this only an issue with the ASN.1 encoding?

14.  notAuthroized - this description seems off for this content type.  Is
the issue that the TA is not authorized or the TA does not root the
authorization.  It would not be the signer itself in this case one presumes.

15.  put in a reference for the content-decryption-key-identifier attribute.

16.  Is there a reason for the badKeyTransportRecipientInfo item being
absent?

17.  Do you want to distinguish between a decryptFailre and a failure
processing a key management item?  This is the basis of some online attacks
to get a key when dealing with RSA v1.5 and RSA OEAP.  This merits a
security consideration notice all by itself.

18.  Are there any security attacks that occur by differentiating between
decryptFailure and invalidMAC for AuthEnvelopedData?

19.  For mismatchedDigestAlg - are you comparing with the signature
algorithm or with the content digest algorithm?

20.  You need some text to distinguish missingCertificate and noTrustAnchor
if keep the "using a trust anchor" text.

21.  tooManySigners - where is this restriction imposed?

22.  can the missingSignedAttributes be used if there are attributes that
are required to be present but are absent - even if there are some attibutes
present?

23.  I don't understand the reason for the missingContentHints.  This
attribute would be an encrypted structure not a signed structure.  Why would
a content hint make any difference in terms of the processing?

24.  Are there any security attacks that are uncovered by the use of the
badMessageDigest error code rather than just saying that the signature
failed to validate?

25.  badAttributes should be modified to say that this is an error only if
the attribute is defined to say that it is not legal for that attribute.
For some attributes having multiple attributes or multiple values is legal.

26.  The description of unsupportedAsymmetricKeyPackage does not make sense
- There is a difference between not prepared and unsupported

27.  Should I be able to return more than one errorCode if I find more than
one error during processing?

28.  Given the number of times that AuthenticatedData was mentioned in the
text, is there a reason it is omitted from section 6?

29.  Security consideration on the cost benefits of using a generic vs a
specific error code.  Some specific codes might leak security information.

30.  Do you really want to make the KeyPkgVersion revised or is it a totally
independent thing?  As currently setup it will be a different thing since it
is in a different module.  If you want it to be a change on what is in the
original module then you need to re-publish that module as well.



> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Russ Housley
> Sent: Friday, April 19, 2013 9:21 AM
> To: IETF SMIME
> Subject: [smime] draft-housley-ct-keypackage-receipt-n-error-00
> 
> Since people that know about CMS hang out on this list, I am asking for
review
> and comment of this Internet-Draft here.
> 
> Thanks,
>   Russ
> 
> 
> 
> > From: [email protected]
> > Date: April 18, 2013 11:12:54 AM EDT
> > To: [email protected]
> > Subject: New Version Notification for
> > draft-housley-ct-keypackage-receipt-n-error-00.txt
> >
> >
> > A new version of I-D,
> > draft-housley-ct-keypackage-receipt-n-error-00.txt
> > has been successfully submitted by Russ Housley and posted to the IETF
> > repository.
> >
> > Filename:	 draft-housley-ct-keypackage-receipt-n-error
> > Revision:	 00
> > Title:		 Cryptographic Message Syntax (CMS) Key Package
Receipt
> and Error Content Types
> > Creation date:	 2013-04-17
> > Group:		 Individual Submission
> > Number of pages: 23
> > URL:             http://www.ietf.org/internet-drafts/draft-housley-ct-
> keypackage-receipt-n-error-00.txt
> > Status:
http://datatracker.ietf.org/doc/draft-housley-ct-keypackage-
> receipt-n-error
> > Htmlized:        http://tools.ietf.org/html/draft-housley-ct-keypackage-
> receipt-n-error-00
> >
> >
> > Abstract:
> >  This document defines the syntax for two Cryptographic Message Syntax
> >  (CMS) content types, one for key package receipts, and another for
> > key package errors.  The key package receipt content type is used to
> > confirm receipt of an identified key package or collection of key
> > packages.  The key package error content type is used to indicate an
> > error occurred during the processing of a key package.  CMS can be
> > used to digitally sign, digest, authenticate, or encrypt these
> > content types.
> 
> _______________________________________________
> smime mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime