ietf-smime
[Top] [All Lists]

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

1998-02-01 13:42:27
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:
1.  PGP certificates could have an OID defined for them and the
certificate would be the any field.  This allows for PGP certificates to
be used at the same time as X.509 certificates in encrypting a single
message.
2.  This would permit the use of other key agreement algorithms (such as
the derived password keys in PKCS#12) to be used.  This would be
especially useful with the new CRS syntaxes to permit a token to be used
for the purposes of authentication and enveloping the data in the
certificate request.  In this world identification information about the
sender could be placed in the UserKeyingMaterials field, and information
about the encryption of the bulk key would be carried in the
OtherKeyIdentifier field.  (It would be along the lines of the OID for
3DES followed by the parameters for 3DES).


2.  Apply similar changes to the signedData structures.  This would
change the ASN as follows:


SignerInfo ::= SEQUENCE {
      version Version,
      ukm [2] IMPLICIT UserKeyingMaterials OPTIONAL,
      rid RecipientIdentifier,
      digestAlgorithm DigestAlgorithmIdentifier,
      authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,
      signatureAlgorithm signatureAlgorithmIdentifier,
      signature SignatureValue,
      unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL}


The switch from IssuerAndSerialNumber to Recipientidentifier allows for
the use of certificates other than X.509.  Additional
UserKeyingMaterials will permit the usage of algorithms such as HMAC to
be used.  Please note that I am intentionally only dealing with the case
were there are attributes present.  I am not suggesting that this be a
general purpose solution, rather I am trying to solve the case where we
are going to do a shared secret authentication message to a RA during
certificate enrollment.  This means that there are going to be
attributes present.  It also greatly simplifies the problem to a more
manageable set of issues.

jim schaad

P.S.  Please refrain from doing correctness passes on the ASN until we
decide if the problem should be dealt with in the working group.  This
does not apply to correcting security or algorithm flaws.  
thanks jls


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Incorporate some PKCS#7 V2.0 items into CMS, Russ Housley <=