Comments on draft-ietf-pkix-ipki3cmp-03.txt

Proposal:
Add extensibility to the PKIBody has been defined in an non extensible
form, the following addition should be added to the PKIBody structure.

Rational:
The message sets needed to support a operational PKI , will need to
mature with experience. Creating non-extensible definitions,  limits the
usefulness of PKIX to support changing requirements. Addition of a
extensibility mechanism will support timely changes.

Change:
 PKIBody ::=3D CHOICE {       -- message-specific body elements
      ir      [0]  InitReqContent,
      ip      [1]  InitRepContent,
      cr      [2]  CertReqContent,
      cp      [3]  CertRepContent,
      p10cr   [4]  CertificationRequest,
        -- the PKCS #10 certification request (see [PKCS10])
      popdecc [5]  POPODecKeyChallContent,
      popdecr [6]  POPODecKeyRespContent,
      kur     [7]  KeyUpdReqContent,
      kup     [8]  KeyUpdRepContent,
      krr     [9]  KeyRecReqContent,
      krp     [10] KeyRecRepContent,
      rr      [11] RevReqContent,
      rp      [12] RevRepContent,
      ccr     [13] CrossCertReqContent,
      ccp     [14] CrossCertRepContent,
      ckuann  [15] CAKeyUpdAnnContent,

Monthly reminder (IETF-PKIX list)

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> verisign.com  
                             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.

Re: Comments on draft-ietf-pkix-ipki3cmp-03.txt

I would favor, in addition to this, the ability to add extensions to
existing
messages.  This could be in the form of extensions (similar to the X.509
v3 extensions) in the PKIHeader, or added to the PKIMessage, or
whatever.  This would allow the messages to carry (of particular interest
to some of us in ANSI X9) billing-related info, among other things.

Regards,
Rich
----------
> From: Charles Moore <cmoore <at> signet.org.au>
> To: ietf-pkix <at> tandem.com
> Subject: Comments on draft-ietf-pkix-ipki3cmp-03.txt
> Date: Sunday, August 31, 1997 7:17 PM
> 
> 
> Proposal:
> Add extensibility to the PKIBody has been defined in an non extensible
> form, the following addition should be added to the PKIBody structure.
> 
> Rational:
> The message sets needed to support a operational PKI , will need to
> mature with experience. Creating non-extensible definitions,  limits the
> usefulness of PKIX to support changing requirements. Addition of a
> extensibility mechanism will support timely changes.
> 
> Change:
>  PKIBody ::=3D CHOICE {       -- message-specific body elements
>       ir      [0]  InitReqContent,
>       ip      [1]  InitRepContent,

Re: PKIX-1 key purpose

> From: Russ Housley <housley <at> spyrus.com>
> 
> Peter:
> 
> I think that ObjectSigning could be more confusing that CodeSigning.
> Object Oriented Programming has nothing to do with the kind og Object you
> are proposing.  Maybe ObjectCodeSigning is better than either of the
> earlier choices....

I'll have to agree with Peter on this one.  "Web objects" includes
more than just "code" or "object code" -- it's not just java applets but
also text and images and metadata and manifests -- anything that can be
conveyed in an html page.

> At 04:02 AM 8/29/97 -0700, Peter Williams wrote:
> >PKIX-1 says, in repsect of the use of TLS to support http:-
> >
> >"id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
> >   -- TLS Web client authentication
> >   -- Key usage bits that may be consistent: digitalSignature
> >
> >To support TLS cipherSuite in which persistent D-H certificates
> >are issued to UAs (and thereby client authentication is not
> >performed using digital signature mechanisms) id-kp-clientAuth
> >should be extended in the bits that may be consistent:-
> >   -- Key usage bits that may be consistent: digitalSignature
> >should be augmented to include keyAgreement.

Agree.

Re: Possible SPKI simplifications

Re: key recovery options for PKIX-3 CAs?

Steve (et al)

>Mark,
>
>>When key recovery becomes a *real* issue, it will be harder to say no if
>>all the CA's out there built centralised key generation capability for
>>PKIX compliance.
>
>So your suggestion is that we not mandate support for a technical facility
>(that has legitimate uses other than key recovery) in order to prevent its
>use in support of key recovery, in an upcoming political battle.  That's a
>slippery slope, since one might identify other features of protocols that,
>despite having valid uses, might also be supportive of some function that
>we view as objectionable.  For example, source routing in IP can cause
>security problems, but it also has legitimate uses.  Support for source
>routing is mandated in IP, even though not everyone needs/wants it, and
>even though we know if can result in security problems.
>
>Steve

I recall several score messages back, someone suggesting, or perhaps asking,
whether PKIX-3 compliance with respect to key recovery and/or centralized
key generation need require a CA to "implement support" for the given service,
or simply support recognition and appropriate response to these requests.

If a CA receives a "generate central keys" type of request, are they to be
viewed compliant if they can say (in effect):

1.  This CA has chosen not to implement the requested service, or

2.  This CA has chosen not to honor such requests (although required to
    implement full support for reasons of compliance.)

Requiring (1) seems completely reasonable, independent of whether (the dark
side of) key recovery ever becomes a *real* issue.  The CA need only be able
to process the requests to the point of appropriate response (not hang, crash,
burn, etc.)

Requiring (2) seems positively Orwellian.

Clarification and comments wellcome.

___TONY___

(speaking for myself, and not as...)

Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb <at> llnl.gov   phone: 510-422-3881             LLLLLLLL

Re: key recovery options for PKIX-3 CAs?

Tony,

>If a CA receives a "generate central keys" type of request, are they to be
>viewed compliant if they can say (in effect):
>
>1.  This CA has chosen not to implement the requested service, or
>
>2.  This CA has chosen not to honor such requests (although required to
>    implement full support for reasons of compliance.)
>
>Requiring (1) seems completely reasonable, independent of whether (the dark
>side of) key recovery ever becomes a *real* issue.  The CA need only be able
>to process the requests to the point of appropriate response (not hang, crash,
>burn, etc.)
>
>Requiring (2) seems positively Orwellian.
>
>Clarification and comments wellcome.

The second statement is exactly what a mandatory option calls for, i.e.,
any product sold as compliant would have to be capable of supporting the
request, but it is up to the operator of the CA service to decide whether
to turn this feature on.  This is no more Orwellian than any other
mandatory option.  For example, the current discussion in TLS is whether to
require compliant browsers and servers to support D-H and DSA, even though
almost all such systems currebtly make use of RSA.  No browser would be
required to turn on support for the algorithms, but no implementation would
be consiedred compliant unless these algorithms could be turned on.

Steve

Re: key recovery options for PKIX-3 CAs?

Steve,

>Tony,
>
>
>>If a CA receives a "generate central keys" type of request, are they to be
>>viewed compliant if they can say (in effect):
>>
>>1.  This CA has chosen not to implement the requested service, or
>>
>>2.  This CA has chosen not to honor such requests (although required to
>>    implement full support for reasons of compliance.)
>>
>>Requiring (1) seems completely reasonable, independent of whether (the dark
>>side of) key recovery ever becomes a *real* issue.  The CA need only be able
>>to process the requests to the point of appropriate response (not hang, crash,
>>burn, etc.)
>>
>>Requiring (2) seems positively Orwellian.
>>
>>Clarification and comments wellcome.
>
>The second statement is exactly what a mandatory option calls for, i.e.,
>any product sold as compliant would have to be capable of supporting the
>request, but it is up to the operator of the CA service to decide whether
>to turn this feature on.  This is no more Orwellian than any other
>mandatory option.  For example, the current discussion in TLS is whether to
>require compliant browsers and servers to support D-H and DSA, even though
>almost all such systems currebtly make use of RSA.  No browser would be
>required to turn on support for the algorithms, but no implementation would
>be consiedred compliant unless these algorithms could be turned on.
>
>Steve

Well, that was clear enough, thank you.

I can certainly understand and appreciate the need among many for either or
both centralized keygen and key recovery.  I can even understand how certain
efficiencies may be gained by embedding such support in the certificate
protocols.

However, I hope that you also understand why many view such a tight coupling
with some alarm.  The scenario:

1999:  Terrorists wreak havok.  "If we'd had those keys we cound have
prevented this!" said presidential advisor.

2000:  CA licensing granted only to CA's that support keygen/key-recovery.
(No, actually only PKIX-3 compliance is required 

2001:  Certify digital keys without a licence, go to jail.

2002:  Another terrorist attack.

2003:  Centralized keygen/key-recovery mandatory by federal law.

2005:  Copies of all network traffic duplicated via high speed network to
NSA intelligent processors for political review...

OK, pardon the excess paranoia.

It certainly makes sense to standardize the form and content of centralized
key generation and key recovery for purposes of interoperability.  But to
embed it in the only network-wide key infrastructure per-se seems more than
just a convenience.

If I were to be a completely PKIX-3 compliant CA, EXCEPT for the keygen and
key recovery part, then I am not "mostly compliant", or "PKIX-3 compliant
but not PKIX-3+kg compliant, I am simply, starkly NOT COMPLIANT, which will
gain connotations of "flawed implementation", "poor interoperability", etc.

There are many other "key-related" services a CA may expand into offering,
such as "trusted timestamping", "notary public", etc.  These services can
(and likely will) be offered by many CAs, just as will keygen/recovery.
But they are not embedded into the protocol, and are certainly not required
for PKIX-3 compliance.

I do not mean to cast aversions, but I can't help envisioning the "smoke-
filled back rooms" where one imagines some of these decisions being crafted.

___TONY___

Re: Possible SPKI simplifications

> From: Peter Williams <peter <at> verisign.com>
> Im not willing to wait several years; Im planning for a world of three standards:
> X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an openCapability.
>
That's odd, I'm also planning for a world of three standards: SPKI certs,
DNS Key/Sig, and PGP certs.

I was hoping to make sure the SPKI effort can describe and link with
both PGP and DNS.

I don't think SPKI is anywhere close to ready.  (heavy sigh)

WSimpson <at> UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson <at> MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Re: Possible SPKI simplifications

> That's odd, I'm also planning for a world of three standards: SPKI certs,
> DNS Key/Sig, and PGP certs.

As someone who has just gone through the traumatic process of reverse
engineering PGP's signature format, I speak from experience when I say you
need your head read.

Philosophically, PGP's stuff is great.  But if OpenPGP is just PGP RFC'd,
it won't stand a chance.  It's inconsistent, ugly, and a whole lot of
other things.  An implementor spends a lot of time catering to vagaries
rather than adding valuable functionality.

BUT I think there's a lot that S/MIME could learn from it...
RSA-independence, thumbprint embedding rather than whole-cert-embedding,
canonicalising text for message signature purposes...  If we had the
consistency of S/MIME with the pragmatism of PGP we'd have a winner.

--
Mark Shuttleworth
Thawte Consulting