RE: PKCS#7 in PKIX-3

[Carlisle Adams <Cadams@xxxxxxxxxxx>]

Hi,

>----------
>From: 	peter@verisign.com[SMTP:peter@verisign.com]
>Sent: 	Friday, January 31, 1997 2:15 PM
>To: 	Carlisle Adams; 'housley%spyrus.com'
>Cc: 	'ietf-pkix%tandem.com'
>Subject: 	RE: PKCS#7 in PKIX-3
>
>Carlise:
"Carlisle".


>
>I believe there is a better way than saying always "no, no
>and no", to _actually_ open systems component technology and a world
>of third-party, multi-vendor "highly re-bundlable" 
>key management technology.

No one has accused me, anywhere, at any time, of always saying "no, no,
and no" to anything without considered thought and reasoning, so I can
only conclude that either you're not reading my postings or you're not
understanding them.


>
>I want PKIX to be a useful componentware standard, not merely a 
>pretend std for marketing closed or proprietary technology.

Every person I know in any way connected with PKIX is absolutely agreed
on this point, so your implication here shows again that you may not
have been following this discussion in sufficient detail...
>
>
>
>From my mailbox, and having consulted the primary players, I think 
>Carlise you are the only party not in consort with the proposal. 

Sounds like your mailbox has a selective memory because my mailbox (and
the PKIX archive) suggest otherwise, but let's move on:


>Id urge folk to respect the (expressed) will of the group to move
>down this layering path. Precisely which wire format specs are agreed upon,
>I for one dont really mind; this is not the issue for me. Id like PKCS7 as
>defined now _at least_ to be indicated, and for the next generation
>being developed in the IETF process with specifically these CA and other
>environment's requirements in mind to be urged, and architected into
>the PKIX-3 system and protocol requirements.

I have no problem whatsoever with saying that when PKCS#7 is able to
accommodate the requirements of the PKIX-3 environment (i.e., when it
has evolved in the ways in which it needs to evolve), then it will be
the preferred (perhaps the *mandated*) protection mechanism.  In its
current form it cannot accommodate all the requirements of the PKIX-3
environment, but it can accommodate some, so I have no problem also
stating in the document that PKCS#7 may be used now wherever it is
appropriate.  I think that Stephen Farrell will agree with such wording
(Stephen?).

Note that this requires no changes at all to the current PKIX-3 protocol
(i.e., PKIX-3 already supports all this, as I have been saying
repeatedly); it simply requires a bit more explanatory text to make the
intentions clearer.  Is this something we can all live with?



>So, 
>
>Just as the Oakley key agreement spec for IPSEC asserts that use of
>DNS security/certs is mandatory (despite the fact that DNS security is
>neither agreed, fully finished/documented, nor ratified within its
>respective WG and the IESG security area directorate) so then,
>with the appropriate language, we mandate an architectural
>realationship to a PKCS7-like messaging service, but not required
>that all implementations have to realise it.
>
>just as SKIP specifies 4 cert types, not all of which need
>to be implemented...
>
>just as IPSEC std allows a multitude of non-interoperable 
>security service and algoirithm profiles....
>
>just as SSL/TLS allows an RSA client to fail to work with a DH-only
>SSL server...

Interesting.  I guess I must be an "old-timer" at IETF now, because I
still remember the days when interoperability was of some value to
protocol designers and working groups...
>
>These std are real, and not pure. So PKIX-3 should be.

So PKIX-3 *is*.  If your point with the examples above is that other
protocols allow non-interoperable options, then it is abundantly clear
that PKIX-3 already has this.  What Stephen and I have tried to do is to
profile this activity (i.e., specify the mandatory subset of the myriad
options) so that a working, interoperable protocol can be achieved.  I'm
guessing that if the PKIX working group does not have a set of working,
interoperable protocols for certificate management then it hasn't really
achieved anything.

--------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
---------------------------------------
> 
>