Ok, I amend my basic proposal - Im tired of debating
the irrelvant PKCS7-nature issue here; the PKCS7 forums
are a better place.
The precise nature of PKCS7, or some alternative,
is not relevant, yet (though few of the passing comments
are objectively true; bias and key recovery agenda are strange
subjective beasts)
The whole point here is to separate protection from information.
There is emerging also the need to ensure group concensus on
the provision of optional or even mandatory presence of key recovey
capability during PKIX key certification activities.
So,
I move we re-consider PKIX-3 design to ensure the necessary
object protection is provided by relying upon the services
of the mime multipart security types, and that any certification system
specific protection requirements are abstracted out of the current spec
and put into either a specification for a new "PKIX" security multiparts
protocol or a PKIX-specified profile suitably combining existing available
multipart services (multipart/signed, multipart/enveloped, etc)
Once this separation of object and protection has occured (like
for DOD's MSP and MMP equivalent problem, or Netscape
use of SSL to protect their CSR messages, or MS demo of PKCS7 to
protect PKCS#10 during initial subscriber enrollment), we can argue
the nature of the std multipart protocol from an identified
requirements standpoint.
Nortel and other members of the Open Group (see APKI I-D) has
indeed identified a specific claim of a requirement - to ensure
mandatory and uniquitous presence of key recovery registation
capabilities during public key certification activities, which
neither 1424 nor MOSS were designed to guarantee. SO I
can see perhaps MOSS, S/.MIME, PGP - as multpart providers-
could well need to be tweaked in nesxt versions to satisfy PKIX-3 needs,
if they are to be used in that context by certification systems.
But lets identify and agree the needs first, and only then choose
the technology. Putting mime multiparts into the architecture
forces this important issue, by ensuring functional separation. It
also makes practical system integration/building from
std components even easier than just mandating PKCS7, say. The
entire point of my argument is to obtain separation, not merely
swap one specified technique for another. Reuse of
what is deployed or available is obviously a major benefit,
also, when weighing up the psosible approaches.
Finally, if it is truely the groups intention to satisfy the
PKIX APKI I-Ds requirements to mandate key recovery capability
on any and all key certification implementations
conforming to PKIX, for all deployments across the
Internet, then we can make a positive affimration of this design
requirement and analyse adequacy of either a single method (e.g. the
Entrust approach already built into PKIX-3), or a framework for
enabling multiple providers and technology approaches to perform
mandatory key recovery/escrow functions.
I dont want this mandatory key recovery thing pushed in by default;
its too sensitive a political issue. A nice sideeffect of
my argument, is that during the separation process, the
need for this as a mandatory requirements is questioned,
and can be agreed upon explicitely. If its mandatory, then
we can ensure the multipart protection environment really
enforces the escrow requirement.
Given the feedback to my iniative (which fell out of reading
the minutes of montreal and san jose IETF WG sessions), hopefully
I've updated and moved the issue forward. A few issues have fallen
out additionally upon reflection and comment (particularly the
escrow topic), and we might really try to reuse the multiparts stuff
as a middle-ground approach. It certainly hurts noone, and gets the job
done nicely without lots of room for future flexiblity. That PKCS7
can be one multiparts provider brings us round to the original
suggestion and motive, but now the topic is more refined and flexible,
embracing more players and technology approaches.
At 09:47 PM 2/4/97, Peter Gutmann wrote:
>Death Rays from Mars made Housley, Russ <housley@spyrus.com> write:
>
>>I think that we are near concensus on this point. A single encapsulation
>>mechanism would be ideal. PKIX Part 3 contains one suggestion, and PKCS #7
>>contains another. Carlise provided an analysis for the PKIX Part 3
approach.
>>PKCS #7 has a market share that should not be ignored, and the specification
>>is open for reivew and update.
>
>Just to further muddy the water, I've been using a format which is (IMHO) an
>improvement on PKCS #7 (it fixes a few problems in the PKCS format and is
>easier to use). In case anyone's interested, I've included the ASN.1
>specification for the encapsulation below.
>
>Peter.
>
>-/ The basic content type. PKCS #7 defines content as a sequence of { OID,
> ANY DEFINED BY } and then nests one of a number of different grand unified
> data types (signed, enveloped, signedAndEnveloped, etc) inside this. This
> doesn't allow for useful extensions such as compressed data or (currently)
> signed then encrypted data, and has the nasty problem of a combinatorial
> explosion of data types (which is also endemic among other RSADSI products
> which use grand unified types) such as SignedAndEncryptedButNotCompressed,
> SignedAndEncryptedAndCompressed, SignedAndEncrypted, EncryptedAndSigned,
> etc etc. A neater solution is to provide at the start of the content a
> SEQUENCE OF ContentInfo records which define the transformations to be
> applied to the content. The contentInfo field encodes in one step a
> transformation which would normally be encoded using nested ASN.1 objects,
> so that for example the transformation:
>
> Sign( Compress( data ))
>
> would be encoded as:
>
> Sign, Compress( data )
>
> The reason for trying to reduce the level of nesting as much as possible
> is that nested, indefinite-length ASN.1 data types are messy to encode and
> lead to unnecessary message expansion. This form of encapsulation is
> known as "logical wrapping", in which a single physical level of wrapping
> is used to provide the equivalent of multiple logical levels of wrapping.
>
> The sequence of ContentInfo fields encodes the progression of levels in
> which the data is encased. For example a contentInfo field of { Signed,
> Compressed } would specify that the content should be signature checked
> and then decompressed to recover the original data (ie the compressed data
> has been signed). In contrast a contentInfo field of { Compressed, Signed
> } would specify that the content should be decompressed and then signature
> checked (ie the decompressed data has been signed).
>
> This system can be used to encode arbitrary transformations on the
> content, with arbitrary logical nesting and an arbitrary processing order.
>
> One disadvantage of the one-size-fits-all basic content type is that two
> fields which are specific to two of the content types must be added. The
> signatures field is used for the Signed data type to contain the
> signatures on the data (which may be empty if the signatures are stored
> separately), and the padding field is used for the Encrypted data type to
> contain optional message padding /-
>
>Content ::= SEQUENCE {
> contentInfo SEQUENCE OF ContentInfo,
> -- Transformation to apply to the content
> content OCTET STRING, -- Data payload
> signatures [0] SET OF Signature OPTIONAL, -- Signature(s) on the data
> padding [1] OCTET STRING OPTIONAL -- Data padding
> }
>
>ContentInfo ::= CHOICE {
> nestedData [0] IMPLICIT NestedDataInfo,
> encryptedData
> [1] IMPLICIT EncryptedDataInfo,
> signedData [2] IMPLICIT SignedDataInfo,
> compressedData
> [3] IMPLICIT CompressedDataInfo,
> ...
> }
>
>-/ Nested data. This specifies that the data payload contains nested content
> which should be further processed. This is usually used after the
> encryptedData type to specify that the decrypted data should be further
> processed. The use of a BOOLEAN is somewhat unnecessary since the mere
> presence of the nestedData field is enough to convey the necessary
> information, however providing the field and setting the value to FALSE
> can also convey the information "I want to bloat up the header
> unnecessarily" /-
>
>NestedDataInfo ::= BOOLEAN
>
>-/ Encrypted data. The encryptionKeyInfo contains the session key and bulk
> data encryption algorithm details, encrypted with zero or more public or
> conventional key encryption keys. If the set is empty, the session key
> must be supplied by some other means. If the set is nonempty, the session
> key may be reconstructed by decrypting one of the EncryptionKeyInfo
> records with the appropriate private key or conventional KEK. Public and
> conventional KEK's may be mixed, so that a single message could be
> decrypted with one or more conventional and/or private keys.
>
> The IV is always present as a fixed-length string to obscure the details
> of the algorithm and mode being used. If necessary it is extended to more
> than CRYPT_MAX_IVSIZE bytes by padding to the right with 0 bits /-
>
>EncryptedDataInfo ::= SEQUENCE {
> encryptionKeyInfo
> SET OF EncryptionKeyInfo,
> -- Encrypted seesion key, may be empty
set
> keyCookie [0] IMPLICIT KeyCookie OPTIONAL, -- Key cookie
> iv OCTET STRING (SIZE(CRYPT_MAX_IVSIZE)) -- IV
> }
>
>-/ Signed data. The digestAlgorithms field contains information on which
> types of message digest to compute for the data in order to allow the
> signature check to be performed once the end of the data has been reached.
> This is stored before the data itself to allow for one-pass processing.
> The signatureCookie field is used to tie the signed data to the signature
> or signatures associated with it if they are stored separately /-
>
>SignedDataInfo ::= SEQUENCE {
> digestAlgorithms
> DigestAlgorithmIdentifiers,
> -- Information on digests for sig.check
> signatureCookie
> [0] IMPLICIT SignatureCookie OPTIONAL -- Signature cookie
> }
>
>-/ Compressed data. This provides information on the compression algorithm
> used and any necessary parameters. Unfortunately the only ISO-approved
> algorithms are peculiar, usually patented or otherwise restricted ones
> (check if Zip has an OID) /-
>
>CompressedDataInfo ::= SEQUENCE {
> compressionAlgorithm
> CompressionAlgorithmIdentifier -- Compression algorithm
> }
>
>
>
Attachment:
smime.p7s
Description: application/pkcs7-signature