Carlise,
Much of the analysis here seem highly prescriptive (you seem to
have decided you dont like the proposal, then constructed an argument
against it), whereas what we need is internet PKI components with feature flexibility
in order to satisfy the actual market demand for multi-vendor
PKI product/service interworking, and the buildup of a unified infrastructure
involving many parties.
Depending upon local threats, the protection requirements for
the messaging channel for a certification system are diverse; one
protection concept will simply not fit all as the assurnaces required
demand different mechanims in different enviornments, given
local threat analysis, and model of handling liability.
Thus I argue that general-purpose enveloping standards (PEM, S/MIME,
MOSS. MSP, PGP), versus a given protection mechanism solution, is where the
IETF WG needs to spend it efforts amending PKIX-3. This is the mood that the WG
expressed, it was reported (subjectively...) to me. I would argue for the syntax of PKCS#7
to ensure harmonization of software interworking - the actual mechanism
for indiciating protection requiremnets, negotiation thereof, and signalling
of features etc, can be worked as the WG proceeds to consider the IETF WG's
polled desires.
If one wishes to use use MOSS, instead, I would not
architecturally object. On account of market penetration, I would *practically*
argue for adoption of the equivalent PKCS7 framework, though, as
many parties have tools, working implementations/products or component-level
integrations already already bundled with the OS.
To consider the issues, rather than an ordained outcome:
PKCS7 can be used in a PEM-like S/MIME mode - designed
for inter-personal email environments, else it can be used in SET mode (tailored
for tight, specialised, payment protocol environments) else it can
be used in support of key management protocols.. The channels
protected by PKCS7 services may be profiled as "S/MIME-like channels"
- between parties who may have no prior relationship -
else they may be symmetrically-keyed "EncryptedData channels"
- for use in more statically-managed crypto/security environments
relying upon other PKCS#7 or S/MIME messages to periodically distribute
pairwise keys
Obviously, there may be mix and match needs, which good management systems
will enable for the certification system when deployed in a specific context.
One should note that the use of PKCS#10 within PKCS#7
is - at the layering abstraction - an identical design to the DoD/MISSI work
on MMP over MSP in a enviornment of personal presence identity
confirmation. There is nothing unusual about the proposal to
rely upon "static channels" to protect all or part of a certification system; this
contrasts with the proposal to build/bundle a specific protection technology
directly into the certification protocol for no apparent customer benefit. This
PKIS style design is a technique known to be in use using the Entrust email
std, for example, to pass authenticated msgs around for
use by CAs using PKCS#10. Relying on secure messaging as a std
component, is perhaps the way to go, rather than constructing a specialist
envelope satisying no one particular need, but being insufficeint for everyone.
----
To evaulate the background and opportunity for the issues, and available technology
for constructing *systems* of security, rather than force everyting
into a monolithic application layer service, list members may wish to
consider the following sources of practical technolgy for standards-conformant
componentware. (Equivalent featured offeringsm, conforming to the same
standards, are also available from non-Microsoft sources, buts its not as well
presented, in my own view.)
As PKCS#7 and PKCS#10 have been distributed as components
in the Windows product, available worldwide, it seems silly to
to deny use of these very recent/pending deployments of industry standards
- for which much effort has already been expended in the retention of licenses,
export approvals, intergration with weak and strong ciphers etc
by many, many, many parties using the Internet worldwide.
A working copy of PKCS#10 and PKCS#7 can be downloaded for
free from the MS website:http://www.microsoft.com/intdev/security/misf6_6.htm
In generalcomment on PKIX-3 - there is no reason in aa complex INternet/intranet/extranet
enviornment to always force the protection model for the certification system to use a
particular in-band protection mechanism - MISPC/PKIX-3 nor PKCS7 nor
any other thing.
Part of the desire to promote PKCS7 as an allowed option is, being a component
technology, that it allows *multiple* localised protection models to be configured.
Having established this as an important goal, it then possible to note that "messaging
security" is itself not even necessary - one might rely on an authenticated
IPSEC channel, else a WINSOCK/SSL channel in those enviornments
were such faciliities are available.
See. perhaps free code on: http://www.microsoft.com/intdev/security/schannel/default.htm
I could go on to suggest how the messages defined for certiifcation might
also pass over DCE RPC relying upon the RPC security for optional privacy
and authentication of the operations passing over the
wire. I think Windows NT4 comes with a free implementation...
Perhaps, in final comment, we should note in the PKIX document that
- to make the point strongly to implementors - that the MOSS protocol
should be assumed as a possible transport environment used
to protect the PKS messages - be these using certs, using raw RSA keys,
uysing symmetric pairs, using DH, etc whatever that toolkit permits. Then,
one should note that any equivalent protocol to MOSS might similarly be used
between cooperating systems - be it IPSEC - SSL/TLS - S/MIME - PKCS7
or DCE RPC.
We should divorce the service lements from the protection mechanism,
and make architectural allusions to the protection context, but
not standardize it overly allowing mix and match ot occur to suit
lcoal security needs, and relay over well-deployed infrastructures such
as the hihgly secure NT/Entrust secure messaging, for example.
Peter.
---------
From: Carlisle Adams
Sent: Monday, December 16, 1996 12:31 PM
To: 'ietf-pkix@tandem.com'
Subject: PKIX-3 San Jose Discussions...
Hi All,
At the San Jose meeting, there was some discussion about the
"proper" relationship between the PKCS series (mainly 7 and
10) and PKIX part 3.
There were two suggestions mooted, which should be
treated *independently*. The purpose of this mail is to
start the discussion so that we reach consensus on the
two issues. (So if lots of discussion ensues, please
indicate in the subject line which issue you're addressing).
Before looking at the details it's probably worth stating
that at the S/MIME BOF in San Jose, RSADSI indicated a
willingness to allow the PKCS series to be recast as
informational RFCs which should remove whatever procedural
problems might otherwise exist.
One proposal which was supported at the meeting was
the requirement contained within the current draft that
proof-of-possession is mandatory where applicable. This means
that proof-of-possession is part of the profile and not
a policy issue. (This has some bearing on the PKCS10 issue.)
1. Use of PKCS7 to protect PKIMessages
The suggestion here is to drop the PKIProtection bit string
and related fields and to call for PKIMessages to be protected
using PKCS7 when required. The idea is to wrap the PKIHeader and
PKIContent as a PKCS7 contentInfo type which contains the signature
(or whatever) which protects the PKIMessage.
It initially appeared that PKCS7, with some modifications, can support
the various options which we need for protection of PKIMessages
(i.e. signatures, DH protection, MACs).
This proposal seemed to be supported in a straw-poll in San Jose, which
at the time we were happy with. However, whilst at first sight this
seems to offer an attractive option to re-use existing technology,
there are some problems which appear to require modification of any
existing PKCS7 implementation (see below).
This means existing applications (e.g., S/MIME user agents) can't be
used to protect all PKI messages, which, in turn, means the deployed
base would have to be modified in either case.
So we've changed our minds on this one, and would now propose
sticking with the protection fields in the current draft.
2. Catering for PKCS10 certification requests
The point here is that there are a lot of existing end-entity
implementations which produce PKCS10 certification requests.
We would like to (and maybe need to?) provide a way for
such end-entity implementations to be able to work within
the internet PKI which we're all developing in this working group.
(Note: it's important to be clear about what PKCS10 supports -
*please* read the PKIX part 3 draft and PKCS10 spec. before getting
involved in commenting on this one.)
The proposal is to add a new PKIContent type which is a PKCS10
certification request. This is actually already done within
the NIST MISPC document, so you can look there for details of
how to do it. (Actually, we intend cogging their text if the proposal
is accepted and Tim lets us :-)
Some details of how to fit a PKCS10 request into the PKIX part 3
exchanges is still TBD (e.g., we'd need to specify exactly which
header fields should be used, and how they relate to attributes
which may (or may not) be included within the PKCS10 request).
Our sense of the opinion at the meeting was that there was some
support for including PKCS10, but that there wasn't agreement on
how to position it in the document. The choices seemed to be:
- PKCS10 is included as a "legacy" format which we
discourage end-entity implementors from using and which
in any case is only to be used in requests for certification
of RSA signature key pairs;
- PKCS10 is included as a "live" format -- possibly instead
of the existing PKIX-3 format -- in which case we have to
extend and profile it to cater for the remaining
proof-of-possession cases (difficult (impossible?) for
key pairs which can be used for encryption only);
- somewhere in between, in which case we discourage its use
but profile PKCS10 for use with, e.g., D-H keys as well as
RSA signature keys.
Our preference is for the first choice. Some arguments are included
below.
Regards,
Stephen and Carlisle.
PKCS7 pros & cons.
1. (Minor pro):
Using PKCS7 allows for re-use of some existing code (but not as much
as one would initially expect (which is why the pro is only "minor");
see the following three points).
2. (con):
PKCS7 isn't well suited for cases in which one protects a message before
getting allocated a name/certificate. This is important for
initialization
and for key recovery, where the end-entity may not know anything about
itself
or its environment prior to the exchange with the CA/RA. Thus, the
mandatory field IssuerAndSerialNumber in SignerInfo (which is used to
identify the signer's certificate) will require a new (and very liberal)
interpretation in this context, meaning that existing implementations
would
have to be modified to deal with this situation.
3. (con):
It is not at all clear how to use the PKCS7 spec. to do a MAC on a
message. "Digesting" seems to apply to hashing only, and MACing does
not appear to fit very well in the SignedData construct. Given that
MACing is important for some operations (again, initialization and
key recovery come to mind, in which the messages may be protected by
a MAC based on secret out-of-band information), further specification
or profiling of PKCS7 would be necessary before it could be used
within PKIX-3.
4. (con):
Using D-H to calculate the signature bits for a PKCS7 signedData is
quite different from using RSA to sign (i.e., although it is quite
possible to force the results into the same syntax, the semantics of
the "encryptedDigest" field of the SignerInfo construct is entirely
changed, resulting in a significant modification to existing PKCS7
implementations). Thus, for example, an existing S/MIME user agent
will be very unlikely to produce the desired result.
5. (Minor con):
The protection scheme in the draft requires us to profile 2 fields;
using PKCS7 would mean having to profile ~12 fields (or wait on
someone else to produce such a profile).
6. (Minor con):
Using PKCS7 makes PKIX-3 less self-contained and really relies on the
PKCS documents coming within the IETF (in terms of change-control).
While we have some fairly high assurance that this *will* happen, it is
worth noting that it hasn't *actually* happened yet.
Arguments for our PKCS10 position:
1. (strong):
A single message can never be used to prove possession of an RSA
decryption-only private key. PKCS10 is a kind of "fire-and-forget"
scheme,
whereas PKIX-3 defines exchanges which do allow for the above proof.
Therefore, PKCS10 is fine for some cert. requests but will definitely
not
work for others; PKIX-3 defines a set of exchanges which can be used for
all cert. requests.
2. (strong):
The deployed base only issues PKCS10 requests for a limited set of
algorithms. PKIX-3 has no such limitations.
3. (medium):
A non-trivial specification effort is required in order to allow PKCS10
to cover a wider range of cert. request cases (see, for example, the
proposal for doing a D-H cert. request using PKCS10). This does little
more than repeat the work already done to arrive at the current PKIX-3
draft and, at any rate, still does not cover all cases.
4. (medium):
The effort required to change a PKCS10 implementation to cater for
a wider range of cases is about the same as implementing the messages
in the current draft (i.e., the code reuse argument begins to look a
bit thin..).
In short, we see fairly little benefit to including either PKCS7 or
PKCS10 in PKIX-3 (due to the need for a non-trivial amount of
specification
work from the PKIX group, coupled with a less-than-expected amount of
code reuse).
Since PKCS10 is useful "as-is" for some certification requests, however,
we see no problem in including it as a message type for those purposes
(but recommending migration to the more general/flexible FullCertRequest
exchanges as soon as possible). The advantage of PKCS7 is even less
clear
(due to the difficulty with unknown DNs and the need for further
specification
on how to do MACing), and our real preference is to stick with the very
simple
and flexible ProtectionBits, as defined in the current draft.
Comments are appreciated (and hereby solicited) on any of the above
points.
[Recall that our goal (as stated at San Jose) is to get a revised draft
out
and into working group last call by January...]
--------------------------------------
Carlisle Adams
Nortel Secure Networks
cadams@entrust.com
---------------------------------------
>
Attachment:
CryptoAPI Source and Sample Code.url
Description: Binary data
Attachment:
SSL-Winsock Spec.url
Description: Binary data