headers
Warwick Ford | 1 Feb 1997 01:57
Picon
Favicon

Re: PKCS#7 in PKIX-3

>From observation of many prior standardization activities, I suggest that
solutions built by incrementally advancing existing, accepted,
well-understood solutions have been far more successful than attempts to
define something totally new, even if the latter was technically superior.

I believe this same feeling was supported by strong concensus in the San
Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
some incremental extensions to PKCS#7 would satisfy requirements for
everyone, then this is clearly far more likely to be accepted as a standard
than a totally new invention such as the proposal in the December I-D.

I would hate to see us use up scarce resources on a new protocol which lacks
broad buy-in from day one.

I would appreciate hearing opinions from other members of the list.

Warwick

At 12:08 PM 1/27/97, you wrote:
>
>Peter:
>
>> My observation that an *unbundled* protection envelope (which encapulates 
>> std information objects, rather than protects inner types) be the basis
>> of the design is founded on such observation of the success of the above 
>> approach in which componentware from multiple sources were bunded by the 
>> customers without third-party invention, yet all parties in a staticaly
>> configured certification system could agree the actual basis for technical 
>> interworking and system msg flow with minimal effort, complete control
>> over local security policy maintained in the hands of the procurer, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
sanders_jeff | 1 Feb 1997 17:34

Monthly reminder

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "listserv <at> tandem.com"
(NOT ietf-pkix <at> tandem.com):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 
Warwick Ford at wford <at> bnr.ca  or Jean Pawluk at pawluk_jean <at> tandem.com.

If you have any questions about this list service in general, you
can contact postmaster <at> tandem.com.
Permalink | Reply | 0 comments |
headers
sanders_jeff | 1 Feb 1997 17:29

(unknown)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "listserv <at> tandem.com"
(NOT ietf-pkix <at> tandem.com):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 
Warwick Ford at wford <at> bnr.ca  or Jean Pawluk at pawluk_jean <at> tandem.com.

If you have any questions about this list service in general, you
can contact postmaster <at> tandem.com.
Permalink | Reply | 0 comments |
headers
scott%phx.sectel.mot.com | 3 Feb 1997 15:33

(unknown)

help
list
Permalink | Reply | 0 comments |
headers
Mike Smith | 3 Feb 1997 16:58

Re: PKCS#7 in PKIX-3 -Reply

I concur, Warwick.

Michael
Permalink | Reply | 0 comments |
headers
David P. Kemp | 3 Feb 1997 18:55

Re: PKCS#7 in PKIX-3

> From: Warwick Ford <wford <at> verisign.com>
> 
> >From observation of many prior standardization activities, I suggest that
> solutions built by incrementally advancing existing, accepted,
> well-understood solutions have been far more successful than attempts to
> define something totally new, even if the latter was technically superior.
> 
> I believe this same feeling was supported by strong concensus in the San
> Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
> some incremental extensions to PKCS#7 would satisfy requirements for
> everyone, then this is clearly far more likely to be accepted as a standard
> than a totally new invention such as the proposal in the December I-D.
> 
> I would hate to see us use up scarce resources on a new protocol which lacks
> broad buy-in from day one.
> 
> I would appreciate hearing opinions from other members of the list.
> 
> Warwick
> 
> >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.  Further, RSA has agreed to work with the 
> >IETF on the PKCS "standards" and give configuration control to 
> >the IETF where standards track RFCs result.
> >
> >So, how does the group want to proceed?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlisle Adams | 3 Feb 1997 19:32
Favicon

RE: PKCS#7 in PKIX-3

Hi Warwick,

>----------
>From: 	wford <at> verisign.com[SMTP:wford <at> verisign.com]
>Sent: 	Friday, January 31, 1997 7:57 PM
>To: 	ietf-pkix <at> tandem.com
>Subject: 	Re: PKCS#7 in PKIX-3
>
>From observation of many prior standardization activities, I suggest that
>solutions built by incrementally advancing existing, accepted,
>well-understood solutions have been far more successful than attempts to
>define something totally new, even if the latter was technically superior.
>
>I believe this same feeling was supported by strong concensus in the San
>Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
>some incremental extensions to PKCS#7 would satisfy requirements for
>everyone, then this is clearly far more likely to be accepted as a standard
>than a totally new invention such as the proposal in the December I-D.

I agree with this reasoning.  However, I would argue that PKCS#7 does
*not* "satisfy requirements for many people", within the PKIX-3
environment, because initialization (for example) cannot be done using
PKCS#7 in its current form.  It does not make sense to *mandate* a
protection mechanism which does not even allow you to get *started* in
this protocol.  What you need to do is to mandate something which *will*
work, and optionally allow anything else to be used wherever it can be
used.  This is what PKIX-3, as currently defined, already does.

Why do I think that PKCS#7 will not work for initialization?  Let me
dredge up an old posting:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlisle Adams | 3 Feb 1997 19:08
Favicon

RE: PKCS#7 in PKIX-3

Hi,

>----------
>From: 	peter <at> verisign.com[SMTP:peter <at> 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...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Williams | 5 Feb 1997 22:23
Picon
Favicon

Re: PKCS#7 in PKIX-3

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.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Robert Hettinga | 6 Feb 1997 19:32

My apologies...

I'm very sorry.

I just committed a major breach of nettiquette.

I just accidentally sent out the last FC97 Revised Program to this
monsterous cc list, instead of using the bcc: field.

Again, please my most sincere apologies.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah <at> shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Never attribute to conspiracy what can be
explained by stupidity." -- Jerry Pournelle
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/
Permalink | Reply | 0 comments |

Gmane