headers
Russ Housley | 1 Feb 1998 07:40

Re: Critical Attributes

All:

Having heard from several implementors that the 
SEQUENCE { OID, BOOLEAN, SET OF ANY } is not an
implementation problem, the next draft of CMS will
include this structure for attributes.

I do not plan to allow unauthenticated attribute to
be critical.  Since these attribute are not covered
by the signature, they have no integrity protection.
This means that an attacker or malicious recipient
could turn the critical BOOLEAN to FALSE anyway.

Russ
Permalink | Reply | 586 comments |
headers
Russ Housley | 1 Feb 1998 09:46

Re: Incorporate some PKCS#7 V2.0 items into CMS

All:

The only comments that I saw on this came from John Pawling.  So, without
further supportive comments, I assume that there is not concensus for these
changes.

Russ

At 01:56 PM 12/26/97 -0800, Jim Schaad (Exchange) wrote:
>I would like to propose to the WG that we look at adopting some of the
>changes that are being examined in the V2 spec for PKCS#7 and modify the
>CMS document accordingly.  
>
>1.  We should allow for the usage of non X509 certificates in CMS for
>encryption purposes.  This would additionally allow for non-public key
>algorithms to be applied to envelopedData structures.  This proposal
>would change the ASN to the following:
>
>RecipientIdentifier :: = CHOICE {
>	issuerAndSerialNumber	IsuerAndSerialNumber,
>	rKeyId [0] RecipientKeyIdentifier,
>	mlKeyId [1] MailListKeyIdentifier,
>	otherKeyId [2] OtherKeyIdentifier }
>
>OtherKeyIdentifier ::= SEQUENCE {
>	keyIdentifier OBJECT IDENTIFIER,
>	keyInformaton ANY DEFINED BY keyIdentifier OPTIONAL }
>
>This allows for the following two scenarios to be included in the usage
>of CMS:
(Continue reading)

Permalink | Reply | 9 comments |
headers
ross | 2 Feb 1998 19:18
Picon
Picon

Re: Critical Attributes

I agree with this proposal from Russ.

-----Original Message-----
From: Russ Housley <housley <at> spyrus.com>
To: ietf-smime <at> imc.org <ietf-smime <at> imc.org>
Date: Sunday, February 01, 1998 12:53 PM
Subject: Re: Critical Attributes

>All:
>
>Having heard from several implementors that the 
>SEQUENCE { OID, BOOLEAN, SET OF ANY } is not an
>implementation problem, the next draft of CMS will
>include this structure for attributes.
>
>I do not plan to allow unauthenticated attribute to
>be critical.  Since these attribute are not covered
>by the signature, they have no integrity protection.
>This means that an attacker or malicious recipient
>could turn the critical BOOLEAN to FALSE anyway.
>
>Russ
Permalink | Reply | 0 comments |
headers
Russ Housley | 2 Feb 1998 03:06

Re: Hashing of CMS signedData objects

I am working on the text for the next draft already...

I have not figured out what to do with the section on the Data content
type.  The OID is still needed...

Russ

At 06:53 PM 1/30/98 -0500, John Pawling wrote:
>All,
>
>I believe that CMS should mandate the strategy that was agreed to at San
>Francisco as follows:
>
>"Proposal #2: Change the CMS SignedData contentInfo field to be
>signedContentInfo defined as follows:
>
>SignedContentInfo ::=  SEQUENCE {
>    sigContentType       ContentType,
>    sigContent      [0]  EXPLICIT  OCTET STRING  OPTIONAL}
>
>It is proposed that the CMS Section 5.3 will be changed so that the
>digesting rules are consistent for all types of data that is signed (i.e.
>the rules for digesting the Data content type will be extended to all types
>of data)."
>
>- John Pawling
>
Permalink | Reply | 0 comments |
headers
Russ Housley | 2 Feb 1998 03:48

Re: Comments to CMS-02

John:

In this case, you use the issuer Dn and serial number.  I assume that
anyone who would generate such a message lives in a environment where the
certificates are easily fetched from a repository.

Russ

At 05:44 PM 1/30/98 -0500, John Pawling wrote:
>Russ,
>
>I agree with all of your responses to my comments except for the following:
>
>I originally stated:
>>>3) Sec 6.2, RecipientInfo originatorCert description:  Please add "This
>>>field should be included when the recipientInfo keyEncryptionAlgorithm
field
>>>indicates a key agreement algorithm and the originator's certificate is
>>>omitted from the envelopedData originatorInfo field (i.e. the originator's
>>>public key material is required as part of the process to decrypt the
>>>encryptedKey, but the originator's certificate is not included in the
>>>envelopedData object)." 
>
>You responded:
>>I do not understand this one.  In the bag-of-certificates, the originator
>>may have more than one with the specified key management algorithm.  In
>>this case, the originator tells the recipient which one to use.  The
>>certificate itself is not carried here, rather an EntityIdentifier is
carried:
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 2 Feb 1998 03:11

Re: Content Type Attribute Question

John:

Thanks.  The contentType attribue is defined in CMS, and it already has an
OID.

I will assign an OID for the encapsulatedContentType attribute.  In fact,
I'll do it now ... I assigned:

    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
            rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

    id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }

    id-aa-encapContentType OBJECT IDENTIFIER ::= { id-aa 6 }

Russ

At 06:42 PM 1/30/98 -0500, John Pawling wrote:
>Russ,
>
>ESS, Sec 1.3.4 already lists encapsulatedContentType as a separate
>attribute.  This is needed to provide equivalent services as the ACP120
>encapsulatedContentType.  
>
>Please note that the ESS Open Issues (Appendix D) states that OIDs still
>need to be defined for the contentType and encapsulatedContentType
attributes.
>
>- John Pawling
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
John Pawling | 2 Feb 1998 16:04

Re: Hashing of CMS signedData objects

Russ,

Recommend that CMS Section 4 should be replaced with the following text:

"4  Data Content Type

   The data content type is identified by the following object
   identifier:

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The presence of id-data in signedData SignedContentInfo->sigContentType
   indicates that the sigContent OCTET STRING is present and includes
arbitrary data.

   The presence of id-data in ContentInfo->contentType
   indicates that the content field is present and is defined
   as an OCTET STRING including arbitrary data.

   In both cases, the presence of id-data indicates that the  
   OCTET STRING includes arbitrary data, such as ASCII text files;
   the interpretation is left to the application. Such data need
   not have any internal structure (although it may; 
   it could even include DER encoded ASN.1 objects)."

- John Pawling

At 09:06 PM 2/1/98 -0500, Russ Housley wrote:
>I am working on the text for the next draft already...
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Pawling | 2 Feb 1998 16:19

Re: Comments to CMS-02

Russ,

My point is that there won't be an issuer DN and serial number to use to
identify the originator's cert in my example (which is allowed by CMS).  In
my example envelopedData, there is not an originatorInfo and there is not an
originatorCert field in the recipientInfo.  Therefore, there is no place
that contains or identifies the originator's cert, so the recipient would be
unable to identify the originator's cert.  My original point was that CMS
should state that if the originator's cert is omitted, then it should be
identified in the originatorCert field in the recipientInfo.  In summary, I
believe that my original comment should be included in CMS.

- John Pawling

At 09:48 PM 2/1/98 -0500, Russ Housley wrote:
>John:
>
>In this case, you use the issuer Dn and serial number.  I assume that
>anyone who would generate such a message lives in a environment where the
>certificates are easily fetched from a repository.
>
>Russ
>
>At 05:44 PM 1/30/98 -0500, John Pawling wrote:
>>Russ,
>>
>>I agree with all of your responses to my comments except for the following:
>>
>>I originally stated:
>>>>3) Sec 6.2, RecipientInfo originatorCert description:  Please add "This
(Continue reading)

Permalink | Reply | 4 comments |
headers
Elliott N Ginsburg | 2 Feb 1998 18:49
Picon
Favicon

RE: I-D ACTION:draft-ietf-smime-cert-01.txt

Also in section 3.1, it is still "Receiving agents MUST check" the From
address against the email addresses in certificates. This must be changed
to allow for certificates that don't contain email addresses.

elliott ginsburg

At 02:42 PM 1/30/98 -0800, Blake Ramsdell wrote:
><internet-drafts recipients trimmed>
>
>On Friday, January 30, 1998 11:05 AM, Elliott N Ginsburg
>[SMTP:ginsburg <at> mitre.org] wrote:
>> We've had well over a month of discussions about the requirement for
>> email
>> address in end-entity certs, and the requirement for the MUA to check the
>> From field against the email addresses in the cert. Yet this latest draft
>> is virtually the same as the previous draft on these issues.
>> 
>> I thought that it had been settled that neither of these requirements
>> would
>> remain. Wasn't that the concensus from the meeting in San Francisco?
>
>I screwed up.  The word MUST will be replaced with MAY in the following
>sentence from section 3.1:
>
>> End-entity certificates MUST contain an Internet mail address as
>> described in [RFC-822].
>
>I read the first half of the paragraph from John's notes, but not the
>last half.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Pawling | 2 Feb 1998 19:50

Redundant Cert Mgmt Protocols

All,

The 28 Jan 98 S/MIME v3 Certificate Handling I-D, Sec 5 specifies
certificate request and response protocols which are redundant to those
specified as part of the PKIX Working Group Certificate Management Protocol
(CMP).  Sec 5.2 specifies the use of SignedData encapsulating a CRMF object.
The CRMF object is harmonized with the PKIX WG, but the Service Indicators
described in Sec 5.2.1.2 and 5.2.1.3 are redundant to the information
contained in the PKIX CMP PKIHeader.  Furthermore, Sec 5.6 specifies the use
of a degenerate signedData object as the S/MIME-mandatory response protocol.
This protocol is redundant to the CMP PKIHeader and certRepContent.

The IETF PKIX working group is developing a "harmonized",
application-independent, IETF standard set of cert mgmt protocols (see Dec
97 PKIX WG minutes).  IMHO, if the S/MIME Certs I-D mandates any cert mgmt
protocols, then those protocols should be the "harmonized",
application-independent IETF standard protocols.  If the S/MIME WG wishes
the Certs I-D to go to last call before the IETF "harmonized" protocols are
complete, then I recommend that all text should be removed from the Certs
I-D that mandates cert mgmt protocols.  Once the "harmonized" IETF standard
protocols are completed, then a separate S/MIME WG spec could be drafted
which specifies the use of MIME to communicate CMS-protected "harmonized"
cert mgmt protocol messages.

I believe that it would be a mistake for the Certs I-D to mandate
S/MIME-specific cert mgmt protocols (including the degenerate signedData).
I believe that there are a significant number of organizations that would
like to build a common cert mgmt module (CCMM) that can serve all of the
various apps running on a workstation (see below).  I believe that an IETF
standard cert mgmt protocol would make it much easier to develop a standard
(Continue reading)

Permalink | Reply | 1 comment |

Gmane