Subject: Re: [IETF-PKIX] Dave's Critical Proposal
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Date: Wed, 31 Dec 1997 14:35:07 -0500

> From: Warwick Ford <[email-masked]>
> >
> >  "If an implementation recognizes the syntax of a particular extension,
> >   the value of the critical boolean in that extension SHALL be ignored."
>
> This would be going too far.  A critical extension conveys semantics that a
> conforming implementation must implement, otherwise not use the
> certificate.  With a non-critical extension, there is no requirement to
> implement particular semantics -- the extension may be ignored, regardless
> of whether or not the implmentation recognizes the syntax.

Warwick (and Bob),
  You are correct; I did not make a distinction between "recognize"
and "support".  A hypothetical implementation might recognize a particular
extension but not, for some reason, claim for compliance purposes to
support it.  Would the following rule be more suitable?

  "If an implementation claims PKIX-compliant support for a particular
   extension, where the scope of "support" is specified in the
   extension definition, then when processing that extension the value
   of the critical flag SHALL be ignored."

In the case of certificatePolicies, "recognize" or "support" means that
the application must support both the certificatePolicies extension
{ id-ce 32 } itself and at least one of the policies (specified by
the policyIdentifier field) contained in the extension.

> From: John Pawling <[email-masked]>
>
> Dave,
>
> X.509, Sec 12.4.3, certificate check, bullet 6 states:
> "d) If the certificate policies extension is present and is flagged
> critical, compute the intersection of the policies in that extension and the
> authority-constrained-policy-set and put the result as the new value of
> authority-constrained-policy-set. Check that the intersection of
> authority-constrained-policy-set and user-constrained-policy-set is non-empty."
>
> If certificate-processing software followed your proposed rule, then it
> wouldn't be allowed to use the value of the certificate policies extension
> critical flag as part of the certification path validation process specified
> in X.509, Sec 12.4.3.  Therefore, your statement is contradictory to X.509
> and should not be added to PKIX I.

I submit that this contradiction is a red flag that a design inconsistency
exists in X.509.

A CA has three options with respect to including a particular extension in
a certificate:  not present, non-critical, and critical.

An application has two options: claim support for an extension or not claim
support.

The processing of a particular extension by an application may have the
following outcomes:

                 |           Application:
      Cert:      | Not supported     Supported
                 |----------------|-------------
    absent       |     N/A        |    N/A
                 |                |
    non-critical |    Ignore      |  Process
                 |                |
    critical     |  Reject cert   |  Process

The path validation procedure described in section 12.4.3 introduces
a third column to processing model:

                 |---------------
    absent       |     N/A
                 |
    non-critical |   Process-A
                 |
    critical     |   Process-B

The use of a single flag for two independent purposes (managing
compatibility with non-supporting applications, and selecting different
processing in supporting applications) sounds like a mistake.

Is there really a need for the phrase "and is flagged critical" to be
included in certificate checks paragraph d)?  If not, it should be
removed from X.509.

If there is an operational requirement for both certificatePolicies
that are used as input to authority-constrained-policy-set, and
policies that are present in a cert but not used as input to a-c-p-s,
then two different extensions should be defined to specify the two
different processing procedures.  My suspicion is that there is no such
operational requirement.

Date:         Wed, 31 Dec 1997 11:45:18 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
Comments: To: [email-masked]
To: [email-masked]
Status:

Thank you, Warwick, for underscoring this vitally important point.  It is
the SEMANTICS of the critical extension that are relevant vis a vis the
application's "understanding", not the syntax. If the application does not
understand AND CONFORM TO the semantics of the extension, it must not
validate the certificate  ¯ at least if it does, it is at the replying
party's risk.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.,
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

>>> Warwick Ford <[email-masked]> 12/31/97 09:37:51 >>>
Dave:

At 09:30 AM 12/31/97 -0500, David P. Kemp wrote:
>It's worth remembering that the criticality flag does *not* affect the
>meaning of an extension; the flag's sole purpose is to cause
>applications which do not understand the extension to reject the
>certificate.  If an application does understand an extension, it makes
>absolutely no difference whether the extension is marked critical or
>not - the critical flag should not even be examined.  The recent
>discussion of certificatePolicies stirred up some mud in this area -
>it's probably a good idea to specify the purpose *and the non-purpose*
>of the critical flag more explicitly in section 4.2.  Something like:
>
>  "If an implementation recognizes the syntax of a particular extension,
>   the value of the critical boolean in that extension SHALL be ignored."

This would be going too far.  A critical extension conveys semantics that a
conforming implementation must implement, otherwise not use the
certificate.  With a non-critical extension, there is no requirement to
implement particular semantics -- the extension may be ignored, regardless
of whether or not the implmentation recognizes the syntax.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 31 Dec 1997 10:41:44 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
To: [email-masked]
Status:

At 09:30 AM 12/31/97 -0500, David P. Kemp wrote:
>This case cannot arise: section 4.2 specifies that only one instance of
>a particular extension may appear in a particular certificate.

Whoops, I missed that. That clears up some of my questions. But..

>As to the case of a subject DN and a subjectAltName, I don't know if
>there is an answer to be found in part 1.

I couldn't find one; I think one is needed.

>My guess would be that
>the CA is vouching for the binding between each name in a certificate
>and the remaining contents of the certificate.

Each name individually, or as a group? "The rest of this cert applies to
either the DN xxx,yyy or the email address [email-masked]" or "The rest of
this cert applies to DN xxx,yyy, but only when also thought of as
[email-masked]"?

>It's probably a
>distinction without a difference to ask whether the CA is vouching for
>a binding between name A and name B - if both are bound to the same
>public key, (in the same cert or in separate otherwise identical certs)
>then they are implicitly equally valid, and it doesn't make much sense
>to ask which name is "definitive".

To me, this means "each name individually". I'm fine with this answer (and
with the other), but neither is clearly stated in the doc.

I can see a reason why "as a group" could be a logical choice. You might
issue one cert for the combination of a DN of "o=FooCo, cn=Chris Smith" and
a subjectAltName of "[email-masked]", and a different cert for  DN of
"o=FooCo, cn=Kim Tong" and a subjectAltName of "[email-masked]". Or,
the DNs might be the same (with an ou and no cn) but with different
subjectAltNames.

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Wed, 31 Dec 1997 11:22:22 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Definition of terms
Comments: To: [email-masked]
To: [email-masked]
Status:

David,

You said:

b) Whatever words are chosen, I object to the fact that community
   underlined 1)-- in your definition is the same as community 2)--.
   I believe that cross-certification should *never* be a transitive
   process: if MISSI wants to verify users under Entrust and VeriSign,
   MISSI MUST issue cross-certs to both.  If MISSI issues a cross-cert
   to VeriSign, and VeriSign issues one to Entrust, that should never
   be a sufficient condition for dave@MISSI to be able to validate
   a signature from tim@Entrust.

   Communities 2) and 3) should be use one word (subscriber/subject/...),
   and community 1) should be the other word (relying party/...).

I believe that I would agree with you with respect to the
cross-certification of what are effectively top-level CAs (PCAs in the old
PEM vernacular).

But do you mean to specifically prohibit the inclusion of subordinate CAs
under a PCA as a result of a cross-certification?

In other words, if VeriSign has issued a Class 3 certificate to XYZ Corp.,
and MISSI cross-certifies the VeriSign Class 3 issuing CA, you would not
want a MISSI subscriber/subject/user/relying party to be able to accept an
XYZ cert?

Now take the case of a certificate issued by the USPS to the Smithsonian
Institution.  Assuming MISSI cross-certifies USPS, shouldn't the MISSI
community accept the Smithsonian's certificates?

If the State of Utah certifies MISSI as a licensed CA under Utah law, are
you saying that no one should trust an subordinate CAs under MISSI, unless
Utah checks out each and every one of them, and cross-certifies them
individually?

I think we are going to have a huge problem of scalability with this
approach, especially when we start to extend electronic commerce
internationally.

I believe that the way to solve the problem of uncontrolled extension of
transitive trust you are rightly concerned about is with legal agreements
between the primary CA's that are cross-certifying , to include a
requirement for flow-down provisions that would affect any subordinate CAs
that were so certified. This would be enforced technically by the use of
policy OID constraints, and if necessary controls over how deep the chain
can get.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.,
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

Date:         Wed, 31 Dec 1997 11:52:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Dave,

X.509, Sec 12.4.3, certificate check, bullet 6 states:
"d) If the certificate policies extension is present and is flagged
critical, compute the intersection of the policies in that extension and the
authority-constrained-policy-set and put the result as the new value of
authority-constrained-policy-set. Check that the intersection of
authority-constrained-policy-set and user-constrained-policy-set is non-empty."

You proposed adding the following statement to PKIX I:
>  "If an implementation recognizes the syntax of a particular extension,
>   the value of the critical boolean in that extension SHALL be ignored."

If certificate-processing software followed your proposed rule, then it
wouldn't be allowed to use the value of the certificate policies extension
critical flag as part of the certification path validation process specified
in X.509, Sec 12.4.3.  Therefore, your statement is contradictory to X.509
and should not be added to PKIX I.

================================
John Pawling
[email-masked]
J.G. Van Dyke & Associates, Inc.
================================

Date:         Wed, 31 Dec 1997 11:37:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
To: [email-masked]
Status:

Dave:

At 09:30 AM 12/31/97 -0500, David P. Kemp wrote:
>It's worth remembering that the criticality flag does *not* affect the
>meaning of an extension; the flag's sole purpose is to cause
>applications which do not understand the extension to reject the
>certificate.  If an application does understand an extension, it makes
>absolutely no difference whether the extension is marked critical or
>not - the critical flag should not even be examined.  The recent
>discussion of certificatePolicies stirred up some mud in this area -
>it's probably a good idea to specify the purpose *and the non-purpose*
>of the critical flag more explicitly in section 4.2.  Something like:
>
>  "If an implementation recognizes the syntax of a particular extension,
>   the value of the critical boolean in that extension SHALL be ignored."

This would be going too far.  A critical extension conveys semantics that a
conforming implementation must implement, otherwise not use the
certificate.  With a non-critical extension, there is no requirement to
implement particular semantics -- the extension may be ignored, regardless
of whether or not the implmentation recognizes the syntax.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 31 Dec 1997 11:25:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

> From: John Pawling <[email-masked]>
>
> I believe that your text expresses the original intention of the critical
> flag, but there are several cases in the 1997 X.509 Recommendation in which
> the critical flag is used for purposes beyong the original intent.  X.509,
> Sec 12.4.3, states special processing requirements for certificatePolicies
> extensions that are flagged critical.  Also, X.509, Sec 12.6.2, states
> special requirements associated with CRLDistributionPoint extensions that
> are marked critical.  Therefore, your proposed text should not be added to
> PKIX I because it would be contradictory to the X.509 Recommendation.

The text of 1997 X.509 section 12.2.2.6 (Certificate policies) is:

  If the extension is flagged critical, it indicates that the certificate
  shall be used for the purpose, and in accordance with the rules implied
  by one of the indicated certificate policies.  The rules of a particular
  policy may require the certificate-using system to process the qualifier
  in a particular way.

  If the extension is flagged non-critical, use of this extension does
  not necessaily constrain use of the certificate to the policies listed.
  However, a certificate user may require a particular policy to be present
  in order to use the certificate.

I believe that this text is a clarification of, not a contradiction of,
the original meaning of the critical flag:  it requires an application to
support (be able to recognize and act on) not only the syntax of the
certificatePolicies extension itself, but also the particular OIDs
present in the extension.

The wording of 12.2.2.6, standing alone, is open to misinterpretation: it
could be read as giving the critical flag the ability to modify the meaning
of the extension.  But that wording is also compatible with the "correct"
interpretation - it describes the effect of the critical flag when considered
over all implementations, not just those applications which support the
extension and the specific policy IDs.

That is why the wording of particular extensions must be considered in
the context of the universal meaning of the critical flag, not taken in
isolation.

For a simpler example, consider section 12.4.2.1 (Basic constraints):

  If this extension is present and is flagged critical then:
    -- if the value of cA is not set to true then the certified public
       key shall not be used to verify a certificate signature;

In the case of applications which do not support basicConstraints, this
statement is true because the critical flag causes the certificate to
be rejected.

In the case of applications which do support basicConstraints, the
cA flag is always expected to be honored, regardless of whether the
critical flag is set or not.  I.e. the critical flag does not modify
the meaning of the extension in applications which support the extension.

Section 12.4.2.1 omits an explicit statement for the non-critical case,
(except for Note 1).  If that statement were present, it might read:

  If the extension is flagged non-critical, use of this extension does
  not necessaily constrain use of the certificate to comply with the
  cA and pathLenConstraint values.

This statement is true not because it gives permission for supporting
applications to ignore the cA flag (it does not), but because it
recognizes that non-supporting applications may ignore the extension.

I still believe that an explicit statement of the (original) meaning of
the critical flag is needed.  That statement supplements, and does not
contradict, the wording in certificatePolicies and elsewhere.

Date:         Wed, 31 Dec 1997 10:04:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Dave,

You stated:
>It's worth remembering that the criticality flag does *not* affect the
>meaning of an extension; the flag's sole purpose is to cause
>applications which do not understand the extension to reject the
>certificate.  If an application does understand an extension, it makes
>absolutely no difference whether the extension is marked critical or
>not - the critical flag should not even be examined.  The recent
>discussion of certificatePolicies stirred up some mud in this area -
>it's probably a good idea to specify the purpose *and the non-purpose*
>of the critical flag more explicitly in section 4.2.  Something like:
>
>  "If an implementation recognizes the syntax of a particular extension,
>   the value of the critical boolean in that extension SHALL be ignored."

I believe that your text expresses the original intention of the critical
flag, but there are several cases in the 1997 X.509 Recommendation in which
the critical flag is used for purposes beyong the original intent.  X.509,
Sec 12.4.3, states special processing requirements for certificatePolicies
extensions that are flagged critical.  Also, X.509, Sec 12.6.2, states
special requirements associated with CRLDistributionPoint extensions that
are marked critical.  Therefore, your proposed text should not be added to
PKIX I because it would be contradictory to the X.509 Recommendation.

================================
John Pawling
[email-masked]
J.G. Van Dyke & Associates, Inc.
================================

Date:         Wed, 31 Dec 1997 09:30:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
To: [email-masked]
Status:

> From: Paul Hoffman / IMC <[email-masked]>
>
>   [snip]
>
> If the answer to the above is "only the combination", what do you do with a
> cert that has two AltNames, one that is set critical and one that isn't? If
> the answer to the above is "either is definitive", does that answer still
> hold true if the AltName is marked critical?

This case cannot arise: section 4.2 specifies that only one instance of
a particular extension may appear in a particular certificate.  The
single AltName extension may contain more than one name, including more
than one name in a particular namespace, but they all have the same
criticality status.

It's worth remembering that the criticality flag does *not* affect the
meaning of an extension; the flag's sole purpose is to cause
applications which do not understand the extension to reject the
certificate.  If an application does understand an extension, it makes
absolutely no difference whether the extension is marked critical or
not - the critical flag should not even be examined.  The recent
discussion of certificatePolicies stirred up some mud in this area -
it's probably a good idea to specify the purpose *and the non-purpose*
of the critical flag more explicitly in section 4.2.  Something like:

  "If an implementation recognizes the syntax of a particular extension,
   the value of the critical boolean in that extension SHALL be ignored."

As to the case of a subject DN and a subjectAltName, I don't know if
there is an answer to be found in part 1.  My guess would be that
the CA is vouching for the binding between each name in a certificate
and the remaining contents of the certificate.  It's probably a
distinction without a difference to ask whether the CA is vouching for
a binding between name A and name B - if both are bound to the same
public key, (in the same cert or in separate otherwise identical certs)
then they are implicitly equally valid, and it doesn't make much sense
to ask which name is "definitive".

The CPS would describe the CA's procedures and assurances for verifying
names, and those procedures would likely be different for different
namespaces.  It is up to the relying party to evaluate the assurance of
each name and the name's relevance to the application.

Date:         Wed, 31 Dec 1997 12:37:04 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

Andrew Csinger wrote:
>
> I didn't want to go into it on the list, but if you configure your systems
> to accept email only from people you know OR from people who are willing to
> pay to certify their email, you can effectively wipe out SPAM.  (If a user
> is unwilling or unable to do this, perhaps he/she can talk his ISP into
> providing such a service...)
>
> Several variations on this proposal are currently in the early stages of
> commercialization.  I'll be pleased to continue this off-list.

When you say "pay", this could (and should), of course, include
hashcash...

Cheers,

Ben.

--
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Date:         Wed, 31 Dec 1997 12:56:23 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Farrell <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Change Request
Comments: cc: [email-masked]
To: [email-masked]
Status:

Hi Mike,

> >1. The standard response message should include a MessageId field. This
> >allows the client to reference a response previously received which
> >contains a path deemed unacceptable by the OCSP client. Note that this
> >does not affect caching of responses. (A HREF would also suffice.)
>
> A MessageId field sounds like a useful request extension.  It would however
> predictably extend the complexity of an OCSP server such it must maintain
> this state information in addition to, for example, nonce information.

I agree that MessageId is a request extension, but would like it to
be a standard part of the response. I can see that it introduces some
state into a server which supports the request extension, however,
that statefulness is required in order to produce a "next" path
for the same request.

> >2. The standard response should include the base64 encoding of the entire
> >path and set of CRLs used to verify the certificate. There is very little
> >overhead involved as the OCSP server must possess all the relevant
> >items.
>
> I agree the OCSP server may have this information on hand, but its
> inclusion in the default case would be overkill for environments with
> well-defined trust paths.  Also, I hadn't seen OCSP as an alternate CRL
> retrieval mechanism.  In some instances OCSP deployment, there may not be
> any CRLs to send back.

I guess we're assuming different environments. I'd like that the
OCSP server and its clients needn't necessarily share well-defined
trust paths.

How about if the standard response were to contain the full certification
path used by the OCSP server with a way of using the extension mechanism
for the client to ask for a copy of the CRLs used?

> >3. A request extension should be defined which means "give me the next
> >path for response <<MessageId>>". The response should contain an
> >alternate certification path (+ CRLs) for the initial request. Of course the
> >second response contains a different MessageId so that iteration is
> >supported. Again this response can be cached without problems. (Or
> >nothing is needed if a HREF is present.)
>
> Might I ask that a draft of this proposed use of OCSP extensibility be
> drawn up, roughly in line with the briefing of this approach to extensions
> as discussed in D.C.?

Fair enough. I'll try to do that in the next week or so.

Meanwhile, I think it'd be worthwhile addressing the issue below on
the list.

> >In addition I'd note that the OCSP server should be chosen by (e.g.
> >configured into) the OCSP client. Using a cert extension to name the OCSP
> >server seems to open up security holes - e.g. it would allow the OCSP server
> >to masquerade as a CA to any of its clients..
>
> The contents of the certificate would be trusted to the extent the
> signature on the certificate is trusted.

I guess I basically don't like the situation where a certificate
contains the location of the OCSP server - it seems too much like making
the OCSP server into a root CA for the client (unless the OCSP server
actually is a root CA for the client, which is maybe what you had in
mind).

How do you actually see this working? Do you in fact expect that certs
will contain the location of the OCSP server? If so, how does a client
know that it should trust the named OCSP server? Maybe I'm just
misreading the draft, but I'd like to see this spelt out.

Regards,
Stephen.

Date:         Tue, 30 Dec 1997 22:09:54 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

There's also no obvious reason why email addresses (or for that matter
other identifying information) should form PART OF the certificate; see
Xcert's papers on the use of OCSP for the secure transmission of
attributes associated with certificates.  (There are few remaining proponents
of the view that credit card numbers, e.g., should be included in certs
as v3 extensions, but the same argument can be used against email addresses,
and so on...)

Andrew

At 14:02 12/30/97 -0400, [email-masked] wrote:
>> I would like to hear other opinions.  Does anyone else think this
>> problem may discourage people allowing their certs to be publicly
>> posted?  Have the email or directory working groups discussed this
>> issue?
>
>     Certs has to be made available to those who need them to
>     do what they were intended to do.  To achieve this availability
>     without making public important information like E-mail addresses
>     and personal details is the challenge here.
>
>     Making certs publicly available is not a security issue in
>     the conventional sense, any average E-mail user who subscribes
>     to a an ISP will tell you that they do not want their E-mail
>     boxes filled with Junk and porno E-mail every day.
>
>     As long as there is no Law to Stop unwanted harassing E-mail
>     from spammers the solution SHOULD come Engineering i.e
>     "do not provide spammers with lists of E-mail addresses
>     posted publicly for FREE".
>
>> Hal
>
>Adel Jaber/Certicom Corp
>
--------------------------------------------------------------
Andrew Csinger, Director                   Xcert Software Inc.
1001-701 West Georgia Street    P.O. Box 10145, Pacific Centre
Vancouver, B.C.                                 Canada V7Y 1C6
tel:     1-604-640-6210                fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           **** Internet Security Technologies ****
"Every  information  object known to modern man is a candidate
 for PKI-based ACL"                          - Young Etheridge
--------------------------------------------------------------

Date:         Tue, 30 Dec 1997 22:02:03 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
Comments: To: [email-masked]
To: [email-masked]
Status:

I didn't want to go into it on the list, but if you configure your systems
to accept email only from people you know OR from people who are willing to
pay to certify their email, you can effectively wipe out SPAM.  (If a user
is unwilling or unable to do this, perhaps he/she can talk his ISP into
providing such a service...)

Several variations on this proposal are currently in the early stages of
commercialization.  I'll be pleased to continue this off-list.

Andrew

At 13:28 12/30/97 -0500, you wrote:
>Andrew Csinger writes:
>> Although somewhat off-topic, I think it's important to note in passing
>> that
>>
>> PKI is ultimately the <bold><italic>solution</italic></bold> to the
>> problem of SPAM,
>
>Not likely. Just because you can then verify that one of
>Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
>does you any good to know where it came from.
>
>Perry
>
--------------------------------------------------------------
Andrew Csinger, Director                   Xcert Software Inc.
1001-701 West Georgia Street    P.O. Box 10145, Pacific Centre
Vancouver, B.C.                                 Canada V7Y 1C6
tel:     1-604-640-6210                fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           **** Internet Security Technologies ****
"Every  information  object known to modern man is a candidate
 for PKI-based ACL"                          - Young Etheridge
--------------------------------------------------------------

Date:         Tue, 30 Dec 1997 22:02:46 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] PKIX part 1: faulty ASN.1:1994
To: [email-masked]
Status:

Paul Hoffman / IMC wrote:
>
> I found some problems in the 1994 ASN.1 in Appendix B.
>
> - UniqueIdentifier is *not* defined. It's a simple definition, but without
> it the module should not compile. This is a bug and needs to be fixed.
>
> - AttributeValueAssertion is defined but never used (and didn't appear in
> the 1988 ASN.1). This shouldn't be a problem, but should be fixed before
> the draft moves on.
>
> - The names issuerUniqueIdentifier and subjectUniqueIdentifer were called
> issuerUniqueID and subjectUniqueID in the 1988 version.  This shouldn't be
> a problem, but should be fixed before the draft moves on..
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Paul,

Did I miss something? Is there ASN.1:1994 for PKIX again?

And BTW, where's all that IETF apathy you were telling
me about? Feels like folks have been whailing the yams
out of me all day :-)

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date:         Tue, 30 Dec 1997 18:40:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
To: [email-masked]
Status:

issuerAltName and subjectAltName seem squishy to me. In reading the spec, I
could not determine what to do if I was looking at a cert that had various
combinations of non-AltNames and AltNames. I don't believe that this is a
fatal flaw in the design, but I am sure we need more wording in the draft
to explain what to do in various cases.

In section 4.1.2.4, it says "The issuer identity may be carried in the
issuer name field and/or the issuerAltName extension." The same kind of
wording appears in 4.1.2.6 about subject names. There is a description of
how to put something in just issuerName or in just issuerAltName. However,
nowhere does it say how to interpret a certificate that has names in both
fields.

If I have a DN in the issuerName and an rfc822Name in the issuerAltName,
does it mean that either name is definitive? Or does it mean that only the
combination of the two names is definitive?

What does it mean if the subjectName is filled in and there is a
subjectAltName with the criticality bit set? Again, does this mean either
is definitive, or the combination is definitive?

If the answer to the above is "only the combination", what do you do with a
cert that has two AltNames, one that is set critical and one that isn't? If
the answer to the above is "either is definitive", does that answer still
hold true if the AltName is marked critical?

This also affects the name chain checking in section 6.

Again, I believe that the spec probably works fine, but the interpretation
of more cases need to spelled out.

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Tue, 30 Dec 1997 18:29:29 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] PKIX part 1: faulty ASN.1:1994
To: [email-masked]
Status:

I found some problems in the 1994 ASN.1 in Appendix B.

- UniqueIdentifier is *not* defined. It's a simple definition, but without
it the module should not compile. This is a bug and needs to be fixed.

- AttributeValueAssertion is defined but never used (and didn't appear in
the 1988 ASN.1). This shouldn't be a problem, but should be fixed before
the draft moves on.

- The names issuerUniqueIdentifier and subjectUniqueIdentifer were called
issuerUniqueID and subjectUniqueID in the 1988 version.  This shouldn't be
a problem, but should be fixed before the draft moves on..

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Tue, 30 Dec 1997 18:31:46 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] PKIX Part 1: using the same algorithm identifiers
To: [email-masked]
Status:

At the end of section 4.1.1.2, it says that the signatureAlgorithm "should
contain the same algorithm identifier as the signature field". This has
been explained to me offline as the fact that they really are talking about
the same thing. Thus, the word "should" is wrong and makes it seem like
there is an acceptable case where the identifiers might differ. I believe
this must be changed to read "must contain...".

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Tue, 30 Dec 1997 14:02:09 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

> I would like to hear other opinions.  Does anyone else think this
> problem may discourage people allowing their certs to be publicly
> posted?  Have the email or directory working groups discussed this
> issue?

     Certs has to be made available to those who need them to
     do what they were intended to do.  To achieve this availability
     without making public important information like E-mail addresses
     and personal details is the challenge here.

     Making certs publicly available is not a security issue in
     the conventional sense, any average E-mail user who subscribes
     to a an ISP will tell you that they do not want their E-mail
     boxes filled with Junk and porno E-mail every day.

     As long as there is no Law to Stop unwanted harassing E-mail
     from spammers the solution SHOULD come Engineering i.e
     "do not provide spammers with lists of E-mail addresses
     posted publicly for FREE".

> Hal

Adel Jaber/Certicom Corp

Date:         Tue, 30 Dec 1997 13:28:29 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

Andrew Csinger writes:
> Although somewhat off-topic, I think it's important to note in passing
> that
>
> PKI is ultimately the <bold><italic>solution</italic></bold> to the
> problem of SPAM,

Not likely. Just because you can then verify that one of
Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
does you any good to know where it came from.

Perry

Date:         Tue, 30 Dec 1997 08:13:09 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

<x-rich>Although somewhat off-topic, I think it's important to note in passing
that

PKI is ultimately the <bold><italic>solution</italic></bold> to the
problem of SPAM, and is not likely

to be any part of the cause.  It will be important, perhaps, to keep
this

vision in front of us as we build the market for PKI, to avoid

mis-perceptions in the short run.  As you point out, issues like this
could

slow down the penetration of PKI technologies if not handled with
delicacy.

Andrew

At 10:22 12/30/97 -0500, Hal Lockhart wrote:

>At 01:30 PM 12/29/97 -0500, you wrote:

>>>It seems to me that publicly accessible directories with certificates
in

>>>them, especially those with email addresses conveniently located in
the

>>>subjectAltName field will provide an irresistible source of targets
to

>>>Spammers.  The reason for raising this issue on this list, is that it
seems

>>>to me that if this does happen it could greatly retard the deployment
and

>>>acceptance of an Internet PKI.

...

>>I think that the solution to the spam problem is likely to be
legislative.

...

>I am afraid you are dreaming, I see too many practical problems with
any

>kind of legal approach to work.  The parallel between email and fax is
very

>weak.  Spam will only stop if it stops working or becomes too
expensive.

...

>I would like to hear other opinions.  Does anyone else think this
problem

>may discourage people allowing their certs to be publicly posted?  Have
the

>email or directory working groups discussed this issue?

>

>Hal

>

>=================================================================

>Harold W. Lockhart Jr.            Platinum Solutions Inc.

>Chief Technical Architect         8 New England Executive Park

>Email: [email-masked]            Burlington, MA 01803 USA

>Voice: (781)273-6406              Fax: (781)229-2969

>=================================================================

--------------------------------------------------------------

Andrew Csinger, Director                   Xcert Software Inc.

1001-701 West Georgia Street    P.O. Box 10145, Pacific Centre

Vancouver, B.C.                                 Canada V7Y 1C6

tel:     1-604-640-6210                fax:     1-604-640-6220

http://www.xcert.com                  email: [email-masked]

           **** Internet Security Technologies ****

"Every  information  object known to modern man is a candidate

 for PKI-based ACL"                          - Young Etheridge

--------------------------------------------------------------
</x-rich>

Date:         Tue, 30 Dec 1997 11:18:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

>>I don't think this is very important however since there are already many
>>ways for a spammer to get addresses, USEnet, mailing lists etc. 10 million
>>addresses can be had for fifty bucks.
>
>This is like saying "bread comes from the supermarket."  The people selling
>lists need a source.

Unfortunately USEnet is simply too rich a source.

Most folks with X509 certs will be making them available through
LDAP or some Web dialogue. Folk could try to download the whole
directory but it would take them rather longer than they might
expect... I suspect most other companies would employ a similar
scheme.

>I am afraid you are dreaming, I see too many practical problems with any
>kind of legal approach to work.  The parallel between email and fax is very
>weak.  Spam will only stop if it stops working or becomes too expensive.

You think that the unworkability of a legislative scheme has some
effect on the readiness of the US congress to impose it?

Its hard to think of a less popular group whose political contributions
are dispensable.

        Phill

Date:         Tue, 30 Dec 1997 10:22:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

At 01:30 PM 12/29/97 -0500, you wrote:
>>It seems to me that publicly accessible directories with certificates in
>>them, especially those with email addresses conveniently located in the
>>subjectAltName field will provide an irresistible source of targets to
>>Spammers.  The reason for raising this issue on this list, is that it seems
>>to me that if this does happen it could greatly retard the deployment and
>>acceptance of an Internet PKI.
>
>
>If this really is a concern we could include the SHA-1 hash of the email
>address in the cert rather than the address itself.

This is an intriguing idea, which sounds bizarre at first, but I can't
really think of anything wrong with it.

>I don't think this is very important however since there are already many
>ways for a spammer to get addresses, USEnet, mailing lists etc. 10 million
>addresses can be had for fifty bucks.

This is like saying "bread comes from the supermarket."  The people selling
lists need a source.

As far as the others go, the key difference is that today if you just send
email directly to other people, your address will not be collected.  Even
if you join a mailing list, your address will usually not be noted unless
you send a message to the list. (Yes, I know that some listservers allow
queries, but I believe this practice is declining.)

In contrast, if your cert is publicly posted, it will be simple to harvest it.

The latest trend being to flood
>mail servers with randomly chosen addresses in the hope that one or
>two in a thousand will get through.

I had not heard of this.  It seems like this would be trivial to block.  I
would be surprised if this tactic lasts for long.

Obviously, you do not literally mean "random".  It is fascinating to think
what the optimum strategy for guessing email names would be.  The address
space is very large, even assuming 8 character names, of order 10^13.

>I proposed a similar scheme for a refusal list. People could sign up on
>it and the list could be freely distributed to spammers without the danger
>that it would be used as a source of addresses. The problem is that
>the folk selling pyramid schemes, junk investments and the favourite
>- software to send SPAM have no interest in refusal lists.

I agree that no scheme that depends on the source can work.

>I think that the solution to the spam problem is likely to be legislative.
>The direct mail industry can fight it through the courts, libertarians
>can flame but the junk email is likely to disappear as completely as
>the junk fax did. At the very least the adverts for spamming services
>would go.

I am afraid you are dreaming, I see too many practical problems with any
kind of legal approach to work.  The parallel between email and fax is very
weak.  Spam will only stop if it stops working or becomes too expensive.

But this is getting pretty far off topic and I apologize to the rest of the
list.  We can debate this off-line if you wish.

I would like to hear other opinions.  Does anyone else think this problem
may discourage people allowing their certs to be publicly posted?  Have the
email or directory working groups discussed this issue?

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 30 Dec 1997 01:00:53 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] Peter Fjelbye/PEF/PBS/DK tr¾ffes ikke.
To: [email-masked]
Status:

Jeg er ikke til at tr¾ffe fra den 19-12-97 til den 04-01-98.

Jeg vil svare pŒ din besked nŒr jeg kommer tilbage.

Date:         Mon, 29 Dec 1997 13:38:33 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] Searching_for_representatives
To: [email-masked]
Status:

Dear Friend!

We are offering an exclusive, unprecedented opportunity to earn money,
and even start your own marketing business in the field of online gambling.

We are a legitimate highly regarded firm, which has now developed a
technologically advanced web product that is a completely unique and
new introduction to the Internet - the first 3D multi-player on line casino.

We are searching for representatives, who are well connected and have
proven marketing abilities, to cooperate with us in marketing our unique product.

Get more information at : http://www.casino-on.net/market

Best Regards,

Casino On Net
Marketing Department
CASSAVA ENTERPRISES LTD.

-----------------------------------------------------
This email is for adults only! It concerns you only
if the Internet qambling is legal in your country.
-----------------------------------------------------

Date:         Mon, 29 Dec 1997 15:18:17 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Definition of terms
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave,
I think your comments bring some needed clarity to this discussion.  But, I
want to challenge an assumptions in your first assertion and the second
assertion itself.

The assertion about who is a relying party, appears to assume a reciprocal
relationship between the subject of a CA's certificate and reliance on
other certificates issued by that CA.  In other words, you assume that
because a CA issues a certificate about or "to" me, I must trust it to
certify others.   And, the only way I rely on certificates issued by a
different CA is if "my" CA cross-certifies the other CA.  Clearly these are
false.  Any CA can obtain a copy of a *public* key of mine (or even
generates one at its own initiative) and issue a certificate with me as
subject.  That is insufficient reason for me to extend any trust as a
relying party to that CA.  (In fact, if it did this without my consent or
cooperation, that may be reason to *NOT* trust it.)  Conversely, I can
decide to grant my trust as a relying party any CA that satisfies my
requirements (e.g., because its public key is widely
known/published/built-in to my software), even if it has not issued a
certificate to or about me.  This is exactly what users of the current
generation of SSL-enabled browsers now do.  These flawed reciprocal trust
assumptions seem to pervade a lot of PKI discussions.   Is it stated
explicitly anywhere?

I think the assertion that cross certification should *NEVER* be transitive
is too strong.  It is a matter of a particular chain of CA's policies and
relying party policies.  If a set of CAs have cross-certification policies
that consistently permit transitive trust (of more than one step), and a
relying party wants to rely on such chains of cross-certificates, I don't
see any reason for PKIX to prohibit it.

-Gene

Date:         Mon, 29 Dec 1997 15:34:59 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

>> If this really is a concern we could include the SHA-1 hash of the email
>> address in the cert rather than the address itself.
>
>Continue with this line of thinking, and you're liable to end up with
>SPKI. And that wouldn't do at all :-)

As I have said before, SPKI is a great forum to develop new
ideas in PKI without the encumberance of design decisions
made in X.509 that may have been overtaken by events.

Exciting new ideas having been developed the real world
will then roll them out as X.509v3 attributes.

Hallam's law: Any communication format that has both
a dominant established userbase and an extension
mechanism is most likely to remain dominant.

Take a look at Visual Basic which may not be the
prettiest approach to program design but has swallowed
every significant feature of almost every language
imaginable with the exception of simplicity.

I don't think we should be affraid of using ideas just
because they come from the anti-ASN-1 brigade.
I see the SPKI/PKIX divide as essentially reflecting
the separation my Oxford Tutor Tony Hoare proposed
between developing programming language features
and designing a programming language.

        Phill

Date:         Mon, 29 Dec 1997 19:01:32 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

Phillip M Hallam-Baker wrote:
>
> >It seems to me that publicly accessible directories with certificates in
> >them, especially those with email addresses conveniently located in the
> >subjectAltName field will provide an irresistible source of targets to
> >Spammers.  The reason for raising this issue on this list, is that it seems
> >to me that if this does happen it could greatly retard the deployment and
> >acceptance of an Internet PKI.
>
> If this really is a concern we could include the SHA-1 hash of the email
> address in the cert rather than the address itself.

Continue with this line of thinking, and you're liable to end up with
SPKI. And that wouldn't do at all :-)

Cheers,

Ben.

--
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Date:         Mon, 29 Dec 1997 13:30:13 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

>It seems to me that publicly accessible directories with certificates in
>them, especially those with email addresses conveniently located in the
>subjectAltName field will provide an irresistible source of targets to
>Spammers.  The reason for raising this issue on this list, is that it seems
>to me that if this does happen it could greatly retard the deployment and
>acceptance of an Internet PKI.

If this really is a concern we could include the SHA-1 hash of the email
address in the cert rather than the address itself.

I don't think this is very important however since there are already many
ways for a spammer to get addresses, USEnet, mailing lists etc. 10 million
addresses can be had for fifty bucks. The latest trend being to flood
mail servers with randomly chosen addresses in the hope that one or
two in a thousand will get through.

I proposed a similar scheme for a refusal list. People could sign up on
it and the list could be freely distributed to spammers without the danger
that it would be used as a source of addresses. The problem is that
the folk selling pyramid schemes, junk investments and the favourite
- software to send SPAM have no interest in refusal lists.

I think that the solution to the spam problem is likely to be legislative.
The direct mail industry can fight it through the courts, libertarians
can flame but the junk email is likely to disappear as completely as
the junk fax did. At the very least the adverts for spamming services
would go.

        Phill

Date:         Mon, 29 Dec 1997 10:43:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

Sorry if this is not appropriate for this list, but I was just wondering
(as I clear the daily load of garbage from my inbox) if anybody has thought
about this?

It seems to me that publicly accessible directories with certificates in
them, especially those with email addresses conveniently located in the
subjectAltName field will provide an irresistible source of targets to
Spammers.  The reason for raising this issue on this list, is that it seems
to me that if this does happen it could greatly retard the deployment and
acceptance of an Internet PKI.

Comments anyone?

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Sat, 27 Dec 1997 21:43:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP Change Request
To: [email-masked]
Status:

Steve,

Comments inline.

At 10:53 AM 12/16/97 +0000, Stephen Farrell wrote:
> . . .
>The current protocol almost supports the above. Changes which would
>support the above could be:
>
>1. The standard response message should include a MessageId field. This
>allows the client to reference a response previously received which
>contains a path deemed unacceptable by the OCSP client. Note that this
>does not affect caching of responses. (A HREF would also suffice.)

A MessageId field sounds like a useful request extension.  It would however
predictably extend the complexity of an OCSP server such it must maintain
this state information in addition to, for example, nonce information.

>2. The standard response should include the base64 encoding of the entire
>path and set of CRLs used to verify the certificate. There is very little
>overhead involved as the OCSP server must possess all the relevant
>items.

I agree the OCSP server may have this information on hand, but its
inclusion in the default case would be overkill for environments with
well-defined trust paths.  Also, I hadn't seen OCSP as an alternate CRL
retrieval mechanism.  In some instances OCSP deployment, there may not be
any CRLs to send back.

>3. A request extension should be defined which means “give me the next
>path for response <<MessageId>>“. The response should contain an
>alternate certification path (+ CRLs) for the initial request. Of course the
>second response contains a different MessageId so that iteration is
>supported. Again this response can be cached without problems. (Or
>nothing is needed if a HREF is present.)

Might I ask that a draft of this proposed use of OCSP extensibility be
drawn up, roughly in line with the briefing of this approach to extensions
as discussed in D.C.?

>Some further requirements which could be proposed (though I'’m luke-warm
>about these myself):
>
>1. Allow the OCSP client to supply a set of partial paths in the request
>(might
>be too much data though).
>2. Allow the OCSP client to specify which root CAs are acceptable to it.
(This
>may also affect the key which the OCSP server uses to sign the response!)
>
>In addition I’'d note that the OCSP server should be chosen by (e.g.
>configured into) the OCSP client. Using a cert extension to name the OCSP
>server seems to open up security holes - e.g. it would allow the OCSP server
>to masquerade as a CA to any of its clients..

The contents of the certificate would be trusted to the extent the
signature on the certificate is trusted.

>
>A final comment. I question the utility of a policy OID in the request. As
>this is
>apparently not intended to be a value from a certificatePolicies extension it
>is
>not clear who will ever define OIDs so that interoperability won’'t be
>impeded.

Which is why I didn't make them part of the standard response syntax.

>I’'d suggest either, a) change this to a request extension with a string
>syntax
>(as the global uniqueness of the OID gains nothing), or, b) limit this to be
>an
>OID which represents the policy OID input to the certificate validation
>algorithm as given in X.509.

I was intending to make some non-normative statements in the base OCSP
document identifying policy OIDs as one example of request extension.

>
>Regards,
>Stephen.
>
>--
>==========================================================================
>Stephen FARRELL......................................tel:  +353-1-676 9089
>Software and Systems Engineering Ltd......................................
>Fitzwilliam Court....................................fax:  +353-1-676 7984
>Leeson Close.................................email: [email-masked]
>Dublin 2...........................................www: http://www.sse.ie/
>IRELAND................................................"A Siemens Company"
>==========================================================================
>
>

Date:         Mon, 22 Dec 1997 11:46:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Definition of terms
To: [email-masked]
Status:

> From: Tim Moses <[email-masked]>
> Subject:      [IETF-PKIX] Definition of terms
> To: [email-masked]
>
> Dave - Thanks for your thoughtful response.  I understand your concern
> over the choice of the term "subscriber community".  Apart from
> anything, it seems to suggest that money has to change hands, which
> isn't necessarily the case at all.  I suppose I felt a little discomfort
> with your suggestion, too: I wanted something that had a "friendly"
> singular form ("subscriber", as opposed to "verifiable entity"), and
> something that reflected the "relationship", rather than the "procedure"
> (vis "relying party", as opposed to "entity that forms certificate
> chains starting at a particular authority").
>
>  [...]
>
> So, the definition of cross-certification becomes:
>
> Authority A cross-certifies Authority B if the subject community of A is
                                               1)-------
> extended (potentially with restrictions) to include all, or a sub-set,
> of the subject community of B.  But, the relying party community of A is
       2)-------                         3)-------------
> not similarly extended.
>
> The subject community of an authority is the set of end-entities whose
> certificates will validate correctly, according to the X.509 certificate
> processing rules, by any relying party who forms certificate paths
> starting from that authority.
>
> The relying party community of an authority is the set of end-entities
> who form certificate paths starting from that authority.

Tim,
  I'm not too worried about fine nuances in the language, those can
be worked out later if anyone has issues with them.  I have two other,
more basic concerns.

a) there are clearly two communities that must be distinguished, but
   I am having a hard time distinguishing from your definition which
   name applies to which community.

   Assume for concreteness two (root) CAs - MISSI and Entrust, and
   two users dave@MISSI and tim@Entrust, and assume that MISSI issues
   a unilateral cross-cert to Entrust.

   My intuitive understanding of the words "subject" or "subscriber"
   lead me to think that for MISSI:
     subject community = { dave }
     relying party (or verifiable) community = { dave, tim }

   and for Entrust:
     subject community = { tim }
     rp community = { tim }

   But if I understand your definition above, it appears to be the
   subject community, not the rp community, which is extended by the
   act of issuing a cross cert.  That seems like a counter-intuitive
   use of the terms subject/subscriber/congregation/etc.  I don't have
   any preference for using subject vice subscriber; I just think that
   either of those terms should refer to the community which is not
   extended by unilateral cross-certification.  And that relying party
   or verifiable should refer to the community which is extended.

b) Whatever words are chosen, I object to the fact that community
   underlined 1)-- in your definition is the same as community 2)--.
   I believe that cross-certification should *never* be a transitive
   process: if MISSI wants to verify users under Entrust and VeriSign,
   MISSI MUST issue cross-certs to both.  If MISSI issues a cross-cert
   to VeriSign, and VeriSign issues one to Entrust, that should never
   be a sufficient condition for dave@MISSI to be able to validate
   a signature from tim@Entrust.

   Communities 2) and 3) should be use one word (subscriber/subject/...),
   and community 1) should be the other word (relying party/...).

Date:         Mon, 22 Dec 1997 10:12:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      [IETF-PKIX] Definition of terms
To: [email-masked]
Status:

Dave - Thanks for your thoughtful response.  I understand your concern
over the choice of the term "subscriber community".  Apart from
anything, it seems to suggest that money has to change hands, which
isn't necessarily the case at all.  I suppose I felt a little discomfort
with your suggestion, too: I wanted something that had a "friendly"
singular form ("subscriber", as opposed to "verifiable entity"), and
something that reflected the "relationship", rather than the "procedure"
(vis "relying party", as opposed to "entity that forms certificate
chains starting at a particular authority").  The following thoughts
occurred to me (though I think my tongue might have been in my cheek at
the time):

Congregation (too religious?);
Constituency (too political?);
Target community (too military?); and
Subject community.

I quite like "subject community", although I can hear the objections
already.  I mean "subject" in the way a monarchist would use the word,
not in the way a linguist would use it (or messrs Bell and Lapadula, for
that matter).  A composite trust structure could be considered atomic by
a relying party that consumes an X.509 certificate processing function.
In this case all verifiable entities would be subjects of the trust
structure, even though they are identified in the "subject" field of a
certificate issued by a CA other than the one where the relying party
starts its paths.  The monarchist would think of this as imperialism,
and would thoroughly approve.

So, the definition of cross-certification becomes:

Authority A cross-certifies Authority B if the subject community of A is
extended (potentially with restrictions) to include all, or a sub-set,
of the subject community of B.  But, the relying party community of A is
not similarly extended.

The subject community of an authority is the set of end-entities whose
certificates will validate correctly, according to the X.509 certificate
processing rules, by any relying party who forms certificate paths
starting from that authority.

The relying party community of an authority is the set of end-entities
who form certificate paths starting from that authority.

This process may also be called "unilateral cross-certification".  If
the process is also performed by Authority B on Authority A, then the
process can be called "mutual cross-certification".  Unless qualified,
the term "cross-certification" should be taken to mean "unilateral
cross-certification".

What do you think? Best regards.  Tim.

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Fri, 19 Dec 1997 15:28:39 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Joseph Johnen <[email-masked]>
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

At 03:55 AM 12/19/97 -0500, you wrote:
>Dear Fellow On-Line Marketer,
>
>Are you getting a satisfactory response from your
>marketing efforts on the Internet?
>
>If you are getting a satisfactory response
>that's great!
>
>However if little or no response have been your
>results- please read the following.
>
>It seems like an eternity since we placed any
>classified ads for our networking program, but
>its really been only been 14 days.
>
>Two weeks ago failure, now success! Why? We have
>changed our way of doing things. In the past 14
>days we have pre built a down line of 150 people.
>
>Did 150 people respond to your classifieds in the
>last 14 days? No? Then this is your opportunity
>to join us. We are going to give you an offer
>you can't refuse.
>
>Here's the pitch: I will pre build you a group
>before I ask you to join anything.
>
>Only after 25 people have joined following you will
>you be asked to provide any information.
>
>Now comes the exciting part. It is something that
>nobody else on the Internet offers. Imagine a down
>line building group that actually communicates with
>its members. What a concept. When is the last time
>your up line contacted you.
>
>Consider these benefits: We won't ask you to:
>
>1. Do any work or promotion
>2. Spend any time or effort
>3. Join any program or invest any money now
>4. Get a web page
>5. Place Classified ads
>6. Get an 800 number
>7. Send out any information at this time
>8. Talk to anybody
>
>Get the picture. We will do it all! We are the
>only - no effort down line builder on the net!
>
>We lied. We do require one thing from you. Just
>e-mail us with 2 little words............
>
>                       "I'M IN"
>
>
>Think about this. Just say "I'M IN" and I will
>build that foundational down line for you. This
>is like selling you MLM insurance without asking
>you to put up any money.
>
>Go ahead and say............I'M IN
>It doesn't obligate you in any way except to say
>you want to take a serious look.
>
>Thanks for taking a look. If you received this and
>are offended by the offer or intrusion. Please
>accept my apologies. Type "remove" in the subject
>field and return this letter to me and I will remove
>you from my email list.
>
>
>Jboan
>
>P.S.
>
>We pride ourselves in communication with our members.
>We believe personal service is lacking on the
>Internet. Too cold and impersonal. If you want to
>be part of something new, different, and better.
>Just say ......."I'M IN"
>
>

Date:         Fri, 19 Dec 1997 18:16:50 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Defintion of terms
To: [email-masked]
Status:

Tim:

I want to be sure I am interpreting you right.  I believe you are proposing
that cross-certification is any situation in which one CA certifies
another, including, for example, the case where an organizational CA
certifies a subordinate CA in that organization's own private hierarchy?
Therefore cross-certificate is a synonym for CA-certificate.  Right?

Warwick

At 11:40 AM 12/19/97 -0500, Tim Moses wrote:
>Colleagues - Here is my proposal ...
>
>Authority A cross-certifies Authority B if the subscriber community of A
>is extended (potentially with restrictions) to include all, or a
>sub-set, of the subscriber community of B.  But, the relying party
>community of A is not so extended.
>
>The subscriber community of an authority is the set of end-entities
>whose certificates will validate correctly, according to the X.509
>certificate processing rules, by any relying party who forms certificate
>paths starting from that authority.
>
>The relying party community of an authority is the set of end-entities
>who form certificate paths starting from that authority.
>
>Whether A and B are in different organizations should not be a
>consideration, as the definition of an organization is imprecise.  If
>B's subscriber community is extended in a similar fashion, then the term
>'mutual cross-certification' applies.  I agree that extending a
>hierarchy does not need a new term.  So ...
>
>1) no term needed.
>2) unilateral cross-certification.
>3) no term needed (its either 2 or 4 as appropriate).
>4) mutual cross-certification.
>5) no term needed (its either 2 or 4 as appropriate).
>
>The term 'cross-certification' is in common usage.  And, I believe when
>people use it, they have something very similar to what I describe above
>in their minds.  If we omitted to provide a rigorous definition in the
>standard, let's correct that now.
>
>Best regards.  Tim.
>
>
>
>--------------------------------------------------------------
>Tim Moses, Entrust Technologies,
>Tel: 613 247 3183,
>email: [email-masked].
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Fri, 19 Dec 1997 13:25:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Defintion of terms
To: [email-masked]
Status:

>Colleagues - Here is my proposal ...
>
>Authority A cross-certifies Authority B if the subscriber community of A
>is extended (potentially with restrictions) to include all, or a
>sub-set, of the subscriber community of B.  But, the relying party
>community of A is not so extended.

This strikes me as a precisely defining a vague notion of the term.

This definition specifies an outcome rather than a procedure. Since
'Certification' is a well defined proceedure in the PKIX vocabulary I
would expect any term of the form 'x-Certification' to be a more
specialized variant of the basic certification proceedure.

Put another way the term is defined in the manner of a requirement
while many people would expect it to refer to an implementation.

The problem becomes more clear when one considers the noun
form of the verb. If I know what certification, cross-certification
and certificate mean then the meaning of 'cross-certificate' should
be self explanatory. I don't think the proposed definition achieves
this.

Where is the term used in the PKIX specs?

        Phill

Date:         Fri, 19 Dec 1997 12:34:41 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Defintion of terms
To: [email-masked]
Status:

> From: Tim Moses <[email-masked]>
>
> Colleagues - Here is my proposal ...
>
> Authority A cross-certifies Authority B if the subscriber community of A
> is extended (potentially with restrictions) to include all, or a
> sub-set, of the subscriber community of B.  But, the relying party
> community of A is not so extended.
>
> The subscriber community of an authority is the set of end-entities
> whose certificates will validate correctly, according to the X.509
> certificate processing rules, by any relying party who forms certificate
> paths starting from that authority.
>
> The relying party community of an authority is the set of end-entities
> who form certificate paths starting from that authority.

Tim,

That proposal makes a lot of sense to me, except for the names of
the communities, and what seems to be a logical flaw in the first
sentence.

The "subscriber community" of Ford sounds superficially to be those
users who have certs issued under Ford's root, rather than those certs
which can be validated by beginning at Ford's root.  If Ford cross
certifies GM, it sounds counter-intuitive that GM users become
"subscribers" of Ford.

I would re-word the proposal to use "subscriber" and something like
"verifiable" communities:

  Authority A cross-certifies Authority B if the **verifiable** community
  of A is extended (potentially with restrictions) to include all, or a
  sub-set, of the **subscriber** community of B.  But, the **subscriber**
  community of A is not so extended.

Does that revision make sense?

> The term 'cross-certification' is in common usage.  And, I believe when
> people use it, they have something very similar to what I describe above
> in their minds.  If we omitted to provide a rigorous definition in the
> standard, let's correct that now.

Yes, we should.

Date:         Fri, 19 Dec 1997 11:40:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      [IETF-PKIX] Defintion of terms
To: [email-masked]
Status:

Colleagues - Here is my proposal ...

Authority A cross-certifies Authority B if the subscriber community of A
is extended (potentially with restrictions) to include all, or a
sub-set, of the subscriber community of B.  But, the relying party
community of A is not so extended.

The subscriber community of an authority is the set of end-entities
whose certificates will validate correctly, according to the X.509
certificate processing rules, by any relying party who forms certificate
paths starting from that authority.

The relying party community of an authority is the set of end-entities
who form certificate paths starting from that authority.

Whether A and B are in different organizations should not be a
consideration, as the definition of an organization is imprecise.  If
B's subscriber community is extended in a similar fashion, then the term
'mutual cross-certification' applies.  I agree that extending a
hierarchy does not need a new term.  So ...

1) no term needed.
2) unilateral cross-certification.
3) no term needed (its either 2 or 4 as appropriate).
4) mutual cross-certification.
5) no term needed (its either 2 or 4 as appropriate).

The term 'cross-certification' is in common usage.  And, I believe when
people use it, they have something very similar to what I describe above
in their minds.  If we omitted to provide a rigorous definition in the
standard, let's correct that now.

Best regards.  Tim.

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Thu, 18 Dec 1997 12:34:44 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Mack:

I understand your issues, and in the banking community, there may be very
limited corss certification.

I was simply trying to point out that the issuance of a cross certificate
from CA_a to CA_b need not cause every certificate issued by CA_b become
valid to the community that consider CA_a to be a trusted root.  If there
is an easily identified subset of CA_b's community and CA_a trusts CA_b
correctly validate the membership in that subset, then cross certification
is an appropriate mechanism.  Trust is the center of this issue.  You
correctly point out that bankers like to minimize the number of people (and
orgianizations) that they need to trust.  It greatly simplifies the risk
analysis and risk management.

Russ

At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
>For: IETF-PKIX Mailing list
>
>From: "Russ Housley"<[email-masked]>
>
>> Mike:
>>
>>This is not necessarily so.  The use of extensions can limit the scope of
>>the "tree" that becomes valid as a result of cross-certification.  For
>>example, name constraints could result in a small subset of the
>>certificates issued by a CA being considered valid in the context path that
>>includes a cross certificate.
>>
>>Russ
>
>Russ,
>
>I have to voice my agreement with Mike that cross-certification
>is not manageable (technical banking term - "scary".))
>
>An example, the trusted relationships between UNIX nodes.  One can
>make the point that the Rhost kind of trust is similar to the
>cross-certification model.  Rhost type of trust has done nothing
>but get lots of people into lots and lots of trouble.
>
>Cross certification may look OK to field commanders in military
>applications.  Ya know -"Well that's Sam's group - he and I
>played hockey together - Let's trust those guys."
>
>Some people think banks trust each other through their Am Bnks Ass
>number (like on the checks).  Anyone who has gotten a bounced check
>knows this is not the case.  Knowing the "naming" and "addressing"
>(name constraints!) does not increase the level of trust.
>
>Keeping naming constraints current - or even manageable - is the
>full time task for lots of people in the mainframe world.
>Keeping that trust (usually in one place - like RACF or ACF2)
>is a full time job that often goes horribly wrong.
>
>
>So, for financial transactions, we are left with on-line status
>verification.  Is there any bank out there that wants to cross
>certify? With whom?
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Date:         Fri, 19 Dec 1997 03:55:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] How's Business ?
To: [email-masked]
Status:

Dear Fellow On-Line Marketer,

Are you getting a satisfactory response from your
marketing efforts on the Internet?

If you are getting a satisfactory response
that's great!

However if little or no response have been your
results- please read the following.

It seems like an eternity since we placed any
classified ads for our networking program, but
its really been only been 14 days.

Two weeks ago failure, now success! Why? We have
changed our way of doing things. In the past 14
days we have pre built a down line of 150 people.

Did 150 people respond to your classifieds in the
last 14 days? No? Then this is your opportunity
to join us. We are going to give you an offer
you can't refuse.

Here's the pitch: I will pre build you a group
before I ask you to join anything.

Only after 25 people have joined following you will
you be asked to provide any information.

Now comes the exciting part. It is something that
nobody else on the Internet offers. Imagine a down
line building group that actually communicates with
its members. What a concept. When is the last time
your up line contacted you.

Consider these benefits: We won't ask you to:

1. Do any work or promotion
2. Spend any time or effort
3. Join any program or invest any money now
4. Get a web page
5. Place Classified ads
6. Get an 800 number
7. Send out any information at this time
8. Talk to anybody

Get the picture. We will do it all! We are the
only - no effort down line builder on the net!

We lied. We do require one thing from you. Just
e-mail us with 2 little words............

                       "I'M IN"

Think about this. Just say "I'M IN" and I will
build that foundational down line for you. This
is like selling you MLM insurance without asking
you to put up any money.

Go ahead and say............I'M IN
It doesn't obligate you in any way except to say
you want to take a serious look.

Thanks for taking a look. If you received this and
are offended by the offer or intrusion. Please
accept my apologies. Type "remove" in the subject
field and return this letter to me and I will remove
you from my email list.

Jboan

P.S.

We pride ourselves in communication with our members.
We believe personal service is lacking on the
Internet. Too cold and impersonal. If you want to
be part of something new, different, and better.
Just say ......."I'M IN"

Date:         Thu, 18 Dec 1997 18:19:45 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX/ECDSA - Duplicate OIDs
To: [email-masked]
Status:

> From: Adrian De Leon <[email-masked]>
>
> Gentlemen:
>
> It appears that some duplicate OBJECT IDENTIFER values have been
> assigned in the 21 Nov 97 IETF PKIX IPKI - ECDSA draft.  These
> are:
>
> For an ECDSA signature:
> iso(1) member-body(2) us(840) ansi-X9-62(10045) ecdsa-with-SHA1(1)
> -> { 1  2  840  10045  1 }
>
> (same value as in MISPC)
>
> The duplicate is:
> id-fieldType OBJECT IDENTIFER ::= { ansi-X9-62  fieldType(1) }
>
> Which I take to be equivalent to:
> iso(1) member-body(2) us(840) ansi-X9-62(10045) id-fieldType(1)
> -> { 1  2  840  10045  1 }
>
> Since MISPC agrees w/ the use of this OID to identify an ECDSA
> signature,
> may I presume that id-fieldType will be changed to something else?

X9.62 defines:

  id-fieldType             OID ::= { ansi-X9-62 fieldType(1) }
  prime-field              OID ::= { id-fieldType 1 }
  characteristic-two-field OID ::= { id-fieldType 2 }

and it defines the public key id to go into SubjectPublicKeyInfo:

  id-publicKeyType         OID ::= { ansi-X9-62 keyType(2) }
  id-ecPublicKey           OID ::= { id-publicKeyType 1 }

but it does not define any AlgorithmIDs for specifying ECDSA (with SHA1
or any other hash).

Presumably X9.62 is the definitive document, so it should be
up to the PKIX internet-draft and the MISPC to switch to an unused
algorithm id, if X9.62 isn't going to define one for ECDSA.

Date:         Thu, 18 Dec 1997 11:34:19 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Suggestions for Key Usage Profile
To: [email-masked]
Status:

Folks,

Sorry to bother you all again, but based on the previous discussions on
Key Usage, I had expected more response to my proposal (below).  Can I
consider the silence to be general acceptance?

Have I not yet made the case as to why this is important?

Dave S.

Simonetti David wrote:
>
> Tim (et al),
>
> As you stated at the meeting last week with respect to the key usage
> profile, I
> agree that PKIX should not restrict the bit combinations.  However, I
> think the previous discussions on this topic proved obvious that there
> are multiple interpretations of these bits.
>
> In an attempt to clarify the meaning of several of the bits, I suggest
> the following editorial changes to PKIX-1:
>
> Section 4.2.1.3, paragraph beginning with "The digitalSignature bit is
> asserted...", add the following, "The digitalSignature bit should be set
> when the key is for use in ephemeral applications, e.g., for a single
> session authentication application such as SSL."
>
> Paragraph beginning with "The nonRepudiation bit is asserted...", add
> the following, "The nonRepudiation bit should be set when when the key
> is used to sign an object which may require the validation of the
> signature at a future time."
>
> I also suggest adding, "If the key may be used for both digitalSignature
> and nonRepudiation applications, both bits may be set."
>
> Finally, after the descriptions of encipherOnly and decipherOnly I
> suggest adding the following:
>
> "The encipherOnly and decipherOnly key usages are intended to provide
> support for key agreement schemes where separate shared secret keys are
> used in each direction of communication.  In such a scheme, a user has
> more than one set of key pairs and bits 7 (encipherOnly) and 8
> (decipherOnly) are used to distinguish between the two types.  The
> originator of a message would use the recipient's public key certificate
> with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> encryption key.  The recipient would use the originator's certificate
> with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> encryption key.  Typically the originator would pass his own certificate
> with bits 4 and 8 along with the message."
>
> Regards,
>
> Dave Simonetti

Date:         Wed, 17 Dec 1997 22:36:48 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] account-authority digitial signature .... fyi
To: [email-masked]
Status:

possibility of some convergence between model 3 and  ocsp. i believe
model 2 will handle majority of payment instructions (ala x9.59 in various
modes as check, debit, credit, etc). I thot that I might at least expose
some
of the ocsp community to the model ... but I need to do some more work
also.

Date:         Thu, 18 Dec 1997 20:05:34 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

-----Original Message-----
From: Mack Hicks <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, 18 December 1997 8:24
Subject: [IETF-PKIX] NO SUBJECT

:For: IETF-PKIX Mailing list
:
:From: "Russ Housley"<[email-masked]>
:
:> Mike:
:>
:>This is not necessarily so.  The use of extensions can limit the scope of
:>the "tree" that becomes valid as a result of cross-certification.  For
:>example, name constraints could result in a small subset of the
:>certificates issued by a CA being considered valid in the context path
that
:>includes a cross certificate.
:>
:>Russ
:
:Russ,
:
:I have to voice my agreement with Mike that cross-certification
:is not manageable (technical banking term - "scary".))

I also have to agree.

Within closed communities such as the postal communities and others this can
be usefull.

Within open, communities, one has to understand the business need, its not a
technical issue (anyones technology will do this after all its only a
cert?).

snip
:Cross certification may look OK to field commanders in military
:applications.  Ya know -"Well that's Sam's group - he and I
:played hockey together - Let's trust those guys."

I see this as another example of a closed community.

snip
:
:So, for financial transactions, we are left with on-line status
:verification.  Is there any bank out there that wants to cross
:certify? With whom?

In the end of the day the relying party will make the trust decision, and
technical Xcert solutions dont realy help this decision.

Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 1 (????/----) (0001DD70)

Date:         Wed, 17 Dec 1997 19:31:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] account-authority digitial signature .... fyi
To: [email-masked]
Status:

Lynn:

What, if anything, do you want PKIX to do to accodate your models?

Russ

At 06:52 AM 12/16/97 -0800, you wrote:
>This is public-key model that i've been working on to handle
>the "non-push" implementation for X9.59. This has been
>cross-posted to x9a10, x9f5, and spki mailing lists. X9.59 is
>designed to be used for any account-based transaction (check,
>debit, credit, etc).
>
>Three digital signature models are described; the original "offline"
>model and two newer "online" models. It is expected that the two
>"online" models become the prevailing modes of operations for much
>of electronic commerce
>
>Digital Signature Model 1:
>--------------------------
>The traditional PKI infrastructure talks about issuing certificates
>that are signed by a certificate authority which attest to the:
>     validity of the public key
>     preferably checking validity of the private key
>     possibly some identity information of the entity
>        that the certificate is issued to.
>The associated PKI-use model has an entity "digitally signing" a
>document with their private key and "pushing"
>     the transaction/document
>     the digital signature
>     a copy of their digital certificate
>to another party. The receiving party presumably will validate the
>authenticity of the digital-signature and the originator's public key
>via the contents of the associated digital certificate.  Originally
>the contents of the digital certificate was assumed to be sufficient
>such that digital signature validation could be performed without any
>additional electronic transmissions. As the methodology matured, it
>became apparent that more and more complex verification mechanisms
>were needed, if nothing else various status could have changed between
>the time that the certificate was originally manufactured and the
>current moment. Certificate revokation lists (CRLs) were one such
>development in an attempt to partially address the issue of current
>real-time certificate status in the offline verification model.
>
>Digital Signature Model 2 (or account-based PKI):
>------------------------------------------------
>This is a proposed implementation for the X9.59 framework. An
>account-holder registers their public-key (and verification of their
>private-key use) with the account authority. In a transaction the
>account-holder digitally signs a transaction and pushes the
>transaction, the digital signature, and the account number.
>Eventually the transaction arrives at the account authority and the
>digital signature is verified using the public key registered in the
>account record.  The account authority maintains the status of the
>holder's public key as part of the overall account management
>process. The transaction therefore requires neither a certificate nor
>some complex status methodology (like CRLs) since the account
>authority maintains current validity status as part of account
>management.
>This is effectively the X9.59 check and credit-card models where the
>receiving entity/merchant does a real-time authorization with the
>account issuing institution. The consumer's digital signature is
>forwarded by the merchant to the issuing institution; the issuing
>institution authenticates the digital signature using the registered
>public-key in the account record.  No signed certificate attesting to
>the validity of the public key is required since the public-key is on
>file in the account record.
>An account-authority performs the majority of the same functions
>performed by a certificate authority, but the processing costs are
>absorbed by the standard business process ... not by charging for the
>issuing of a certificate. It is possible that an account-authority
>might also wish to become a certificate authority since it potentially
>could be undertaken at less then 5% additional business costs.
>
>Digital Signature Model 3 (positive authentication):
>---------------------------------------------------
>This is actually a slight variation on #2, although it bears some
>superficial resemblance to #1. The initial designs for positive
>authentication PKI, used the credit-card authorization model to
>replace CRLs. However they kept the rest of the infrastructure; the
>originator's certificate was still pushed around with the transaction.
>The receiver validated the CA's signature on the certificate, then
>sent off a certificate status request and validated the CA's signature
>a second time on the status response (and then validated the original
>digital signature).
>Model #3 looks very much like model #2 in that the originator's
>certificate is not pushed around with the transaction. However, rather
>than sending the digital signature in the authorization request, just
>the certificate identifier (account number) is sent to the CA. The CA
>signs a status response that includes information regarding the
>real-time validity of the account along with a copy of the account's
>public key. In effect the real time status response becomes a
>mini-certificate. The entity that will act on the transaction now only
>has to verify the CA's signature on the status response (i.e.
>mini-certificate, it doesn't also have to verify the CA's signature on
>a certificate manufactured at some point in the past). It then uses
>the public-key returned in the status response to validate the
>originator's digital signature.
>Superficially this resembles digital certificate model #1 but the
>actual operation is much more like model #2. Including the account's
>public-key in the real-time status response creates, in effect, a
>mini-certificate. It also eliminates a redundant/superfluous
>validation of the CA's digital signature (on both the manufactured
>digital certificate and the real-time status responses).
>The biggest operational difference between #2 and #3 is that the
>account authority verifies the originator's digital signature in #2
>and in #3 it just returns the value of the account's public key for
>the requester to validate a digital signature.  If the requester can
>send the document or even the secure hash of the document to the
>account authority along with a copy of the digital signature, then the
>account authority can verify the digital signature. If not, the
>request just identifies the account and the mini-certificate is
>returned allowing the requester to validate the digital signature.
>The positive authentication model presents a number of revenue
>opportunities for the CA to charge for various levels of detail
>returned in real-time status responses (and/or approval levels
>associated with the transaction).
>Conclusion
>----------
>Digital signature model #1 was originally developed to allow "offline"
>verification of a digital signature. A manufactured certificate was
>pushed along with the signed document and the digital signature could
>be verified using just the contents of the certificate that was passed
>along with the document.
>Offline signature verification using a certificate manufactured
>several months in the past (and by implication relying on status that
>was several months stale) turned out to be inadequate for various
>kinds of transactions. This has led to the definition of more
>complicated processes in the certificate-push model in an attempt to
>provide more timely status and verification.
>There has also been the implicit assumption that only the certificate
>authority is performing registration services for digital signature
>processes. As the concept of digital signatures have become more
>acceptable, it has also becoming apparent that existing business
>processes (already performing account registration functions) can be
>simply extended to add public-key registration.
>Revisiting the PKI basic architecture, it became apparent that there
>were several optimizations possible if it was recognized there were
>significant numbers of online PKI operations (compared to earlier
>models that started out assuming offline PKI and later tried to graft
>online features afterwards).
>The offline validation and certificate push model is still valid for
>some types of transactions and shouldn't be precluded. However, real
>online validation (models #2 and #3) can eliminate some number of
>superfluous operations.
>It should be noted that the "offline" validation is different than the
>"offline" purchasing referred to in X9.59. X9.59 assumes that the
>consumer can be offline and transmits an order and payment
>instructions via methods like email (not requiring real-time, online
>interaction with the merchant).  In the validation process, there is
>an issue whether the merchant is also offline at the point that it
>approves the transaction.  If the merchant is offline, then it needs a
>consumer certificate to validate (and authorize) the consumer
>transaction. If the merchant is online, then either model #2 or model
>#3 is used (and it is not necessary for the consumer to push the
>certificate with the transaction). Furthermore, in the case of model
>#2, either the merchant can perform its own PKI registration function
>and/or it can rely on a financial account infrastructure to have
>implemented a PKI registration function.
>It is expected that digital signature models #2 and #3 become the
>prevalent modes of operation for at least financial transactions.
>
>Denial of service attack addenda
>--------------------------------
>There is a hypothetical case (that can be made for certificate pushing
>in the online world) which is associated with anonymous denial of
>service attacks. The existing Internet infrastructure provides
>significant opportunities for electronic terrorists to anonymously
>(and/or under assumed identity) launch denial of service attacks
>(flooding a web site with enormous number of bogus requests). These
>are undertaken with the assumption that it is nearly impossible to
>trace the source of the attack.
>One of the techniques for dealing with denial of service attacks is to
>recognize and eliminate bogus requests as soon as possible. If a
>certificate is pushed with a request then some preliminary screening
>of requests can be performed during initial processing and possibly
>eliminate some number of bogus transactions.
>The downside is that public key operations are extremely expensive;
>preliminary screening of a request using the certificate (and still
>doing the online validation later) could be more expensive than
>allowing bogus transactions through and recognizing them via the
>standard mechanism.
>Most of these are simple band-aid solutions. The real problem is that
>existing Internet backbone operation makes it simple to impersonate a
>network address. As a result it is usually very difficult to trace
>back to the originator of an electronic attack.
>

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Content-identifier: 002A73498479E2A1
Conversion: Allowed
Original-encoded-information-types: IA5-Text
Priority: normal
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 002A73498479E2A1-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date:         Wed, 17 Dec 1997 13:43:58 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mack Hicks <[email-masked]>
Subject:      [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

For: IETF-PKIX Mailing list

From: "Russ Housley"<[email-masked]>

> Mike:
>
>This is not necessarily so.  The use of extensions can limit the scope of
>the "tree" that becomes valid as a result of cross-certification.  For
>example, name constraints could result in a small subset of the
>certificates issued by a CA being considered valid in the context path that
>includes a cross certificate.
>
>Russ

Russ,

I have to voice my agreement with Mike that cross-certification
is not manageable (technical banking term - "scary".))

An example, the trusted relationships between UNIX nodes.  One can
make the point that the Rhost kind of trust is similar to the
cross-certification model.  Rhost type of trust has done nothing
but get lots of people into lots and lots of trouble.

Cross certification may look OK to field commanders in military
applications.  Ya know -"Well that's Sam's group - he and I
played hockey together - Let's trust those guys."

Some people think banks trust each other through their Am Bnks Ass
number (like on the checks).  Anyone who has gotten a bounced check
knows this is not the case.  Knowing the "naming" and "addressing"
(name constraints!) does not increase the level of trust.

Keeping naming constraints current - or even manageable - is the
full time task for lots of people in the mainframe world.
Keeping that trust (usually in one place - like RACF or ACF2)
is a full time job that often goes horribly wrong.

So, for financial transactions, we are left with on-line status
verification.  Is there any bank out there that wants to cross
certify? With whom?

-   -    -    -    -    -    -    -    -    -    -    -    -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>

Date:         Wed, 17 Dec 1997 11:36:28 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] PKI Thesis
Comments: cc: SPKI List <[email-masked]>
To: [email-masked]
Status:

-----BEGIN PGP SIGNED MESSAGE-----

My apologies if you get this message twice (or even thrice)...

This is to announce that my PKI References page at
http://www.xcert.com/~marcnarc/PKI/ has undergone a major overhaul, and is
now (hopefully) easier to use.

Also, along with the new page, I've (finally) web-ified the thesis which
inspired it.  You can read A Survey of Public Key Infrastructures at
        http://www.xcert.com/~marcnarc/PKI/thesis/

It's already a bit dated (sigh).  In particular, the SDSI/SPKI section is
now completely inadequate.  Also, the PGP and SecureDNS parts could use a
little refreshening.  Still, IMHO, it's good reference for people who want
to learn the basics about PKI technologies.

Comments are very welcome.  I have a vague notion about turing the thesis
into a living "PKI FAQ" document, and would be happy to speak with anyone
who has ideas for, or who wants to help with, such a beast.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date:         Wed, 17 Dec 1997 10:40:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and Cross-certification
Comments: To: Mike Smith <[email-masked]>
Comments: cc: [email-masked], [email-masked]
To: [email-masked]
Status:

Mike:

This is not necessarily so.  The use of extensions can limit the scope of
the "tree" that becomes valid as a result of cross-certification.  For
example, name constraints could result in a small subset of the
certificates issued by a CA being considered valid in the context path that
includes a cross certificate.

Russ

At 12:49 PM 12/9/97 -0700, Mike Smith wrote:
>Mack:
>
>You are probably aware of the following point, but thought I'd mention it
anyway;  Some cross-certification of CA schemes bring in not just the tree
of the CA cross-certified, but all of the Ca trees they have
cross-certififed and all of the CA's those have cross-certified, ... etc.
Could be one CA cross cert could bring in all CA trees.
>
>Scary from a Bank's point of view, eh?
>
>Michael
>
>>>> Mack Hicks <[email-masked]> 12/09/97 10:58AM >>>
>
>Tim,
>
>From the last announcement by Entrust, IBM, and others, there is a
>perception that the cross-certification of CAs will handle the problem
>of trust generally.  This means that trees within each organization
>will trust trees within other organizations.
>
>Within the Banking industry, discussions uniformly have rejected this
>idea.  We have learned from long experience - with private networks,
>credit cards, funds transfer networks, and others - that the best
>way to manage the risk of a transaction, a connection, or a communication
>is to have on-line status checking.  This is also true with
>the checking of the status of digital certificates.
>
>The volume questions are interesting.  Bank of America processes about
>10% of the US paper checks every night -- over 22,000,000 pieces of paper
>at high water mark.  I think we can handle some multi-million certificate
>status requests.
>
>But we do not do things for free or manage risk of communication without
>authentication.  Therefore the on-line status check is for our customers.
>
>The NACHA Internet Council pilot of CA interoperability will demonstrate
>how Banks will trust each others certificates.
>
>We are using CRLs between banks--and I think CRLs have a place in high
>volume relationships between organizations. This risk of outdated CRLs
>can be managed by agreement and rules that NACHA would set.
>
>Tim wrote:
>
>>>1. Approximately how many OCSP responders are required to serve a
>>>community of one billion relying parties and subscribers?
>>>
>I expect that certificate holders would go to their agents.
>Therefore, the magnitude of OSCPs will be the magnitude of
>agents (essentially CAs or their repositories).
>
>>2. How do the relying parties come to trust the verification keys of the
>>>OCSP responders?
>>>
>By contracted relationship, since they are using the OCSP to THEIR
>agent - and the agent now deals with the trust to other repositories.
>Admittedly, this does make the same problem at the agent's level,
>but this is a less difficult problem since these agents are in this
>business.  They will have contracts and associations.
>
>>>3. How do the OCSP responders obtain revocation information from the
>>>single CA?
>>>
>Revocation information will be by OCSP at low volumes from agent to
>agent.  High volume agents will contract on risk distribution and
>may use CRL mechanisms.
>
>I do not know of a CA will offer its CRLs to all comers without
>authentication. (Talk about denial of service opportunities.)
>
>>>4. How current will the revocation information be when it is presented
>>>to the relying parties?
>>>
>If it is OCSP, it will be as current as represented by the agency.
>Between agencies, association rules and contracts will provide
>this assurance.
>
>
>For all the talk of CRLs, I would like to point out that CRLs
>make really good sense in a military application where the
>commanding officer (relying party) needs to make a decision
>based on available information (certificate, roots, last CRL).
>In a commercial context, we have left this model of behavior
>behind with the advent of telephony.
>
>
>
>Therefore, I state my earlier discussion:
>
>From PKIX 3, I expect that a PKIX compliant CA can
>
>a) Provide a place for CRL or OCSP
>b) Provide a reponse of
>   "I don't know you - go away"
>   for unauthenticated requests.
>c) The relying party should then not automatically trust
>   the certificate since there is no assurance that the
>   certificate is still valid.
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

    !
>

    !
>

    !
>

>

Date:         Wed, 17 Dec 1997 11:57:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] draft meeting minutes
Comments: To: [email-masked]
To: [email-masked]
Status:

Steve:

Following up Carlisle's comment, here is a change to my paragraph re
CMP/CRS that has been agreed with Carlisle:

>At the second PKIX WG meeting, a compromise approach was announced,... [
snip]...  CRS will continue to progress, specifying the mapping of
certificate management messages onto CMS and providing the vehicle for
developing common formats for other certificate management messages (i.e.,
messages other than certificate request)."

Please change the final clause to:

 and providing the vehicle for producing an RFC (or RFCs) that document
>agreed common formats for other certificate management messages (i.e.,
>messages other than certificate request)."

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 17 Dec 1997 11:48:33 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
To: [email-masked]
Status:

Bob:

I think I read you as essentially supporting my (3) option, i.e.:
(3) Issuance of a certificate by a CA in one organization to a CA in
another organization.  (You might substitute "domain" for "organization".)

Is this fair?  (If not pls propose a 1-sentence alternative.)

Warwick

At 01:05 PM 12/16/97 -0700, Bob Jueneman wrote:
>I agree with the thrust of Al's comments, but would like to throw in an
>additional comment.
>
>To me, the primary difference between a hierarchical and a peer relationship
>between CA's is not the network topology, but rather the degree of
>legal/policy control and the (partial) assumption of liability for the
>actions of the subordinate CAs.
>
>If I am operating a corporate level CA for XYZ Corp,  I might choose to go
>to a public CA such as VeriSign, GTE, etc., in order to have my CA's
>certificate signed by a recognized root key.  (Sooner or later, users are
>going to start to rebel about the number of root keys that browser vendors
>are gratuitously including in their software, and then maybe some order will
>arise from the current chaos.)
>
>As a condition for having my corporate certificate listed under say GTE's
>master certificate, I would expect that I would have to sign a binding
>agreement concerning policy, perhaps including auditing and other oversight
>functions which are intended to protect relying parties and the root CA from
>undue liability.
>
>I would also expect that a condition of receiving a certificate from GTE,
>there would be obligatory, contractual flowdown requirements that would
>govern whether or not my top-level corporate CA could issue certificates to
>subordinate CAs within my organization, and if so what policies and policy
>OIDs would be incorporated.
>
>Now, what does it mean if two top-level CAs cross-certify each other.  Does
>it mean that each will accept full financial liability for the other's
>errors and omissions, or for the failure of any of their subordinate CA's
>particular failures?  Not bloody likely!
>
>Instead, I believe that the primary use of cross-certification will be to
>ACCREDIT other CAs, in the sense of an ADVISORY rating service.  Is the
>German government going to undertake any liability for what VeriSign does?
>No.  But on the other hand, they might well represent to German consumers
>that VeriSign is a well-recognized CA, and appears to meet certain accepted
>standards of behavior with respect to their internal operations, auditing,
>and other controls. Likewise, VeriSign might cross-certify the German
>Government's CA, but without taking any responsibility for their actions.
>The differences in the legal regimes makes it very unlikely that any legal
>obligations will flow between the CAs.
>
>In the case that someone mentioned, The University of Maryland might either
>unilaterally or bilaterally certify Purdue, but again that will only imply
>that Maryland recognizes Purdue as a bona fide institution that conforms to
>a reasonable set of practices, but it would not imply any contractual or
>other liability relationship between the two institutions.
>
>In my mind, therefore, cross-certification is very much like a Standard and
>Poor's bond rating service, or maybe just a Dun and Bradstreet confirmation
>that a company exists and seems to meet the minimum criteria.  If VeriSign
>cross-certifies Billy Bob's CA and Bait Shoppe as a legitimate CA when they
>are obviously not legitimate, VeriSign might very well expect to get sued.
>But if Billy Bob is in fact a reasonably competent CA that only occasionally
>fails to exercise due diligence in issuing certificates, relying parties
>should expect to go against Billy Bob, and not VeriSign.  VeriSign completed
>their responsibility when they ascertained that Billy Bob was properly
>incorporated and had at least the trappings of a viable commercial service,
>but they should not be expected to cross-insure Billy Bob's operation.
>
>I would therefore disagree slightly with Al's comments in one particular
>area, where he says:
>
>>This contrasts with a peer-based architecture, in which one CA
>essentially tells another one "I'll accept your certificates if they
>have the following properties.  What else you do is your own business; I
>won't interfere, but things that interwork with my users must have the
>following properties."  The degree of control is much less.
>
>CA's don't accept other CA's certificates, at least normally -- relying
>parties accept certificates.  So the degree of control is even less that Al
>intimates. On the other hand, if the IT or MIS department of some
>organization essentially dictates to its users what kind of certificates are
>to be considered acceptable, then cross-certification may be a way of
>controlling that. But outside of the military I would expect that kind of
>operation to be the exception rather than the norm.
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are trying to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross the chasm in two leaps."
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 17 Dec 1997 09:01:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

Further to Charles and Bob's comments on policies and CPS:
>
Charles said:
>We have both, these are published in closed communities.

This is similar to what I am seeing among a number of our customers as
well. Especially in the enterprise CA community - the CPStypically
contains a significant amount of highly sensitive information which
corporations operating an enterprise CA have no need nor desire to make
publicly available, unless they have a business reason to do so. In my
opinion the way this will evolve is that very detailed CPS documents
have and continue to be produced by organizations. These will probably
be used mostly for audit, accreditation, internal process management,
quality assurance and consideration by other security domains when
establishing a cross-certification agreement with them. I think you
will, however, see very high level overviews of CPS documents published
eventually by many of CAs of this type.

In a public service CA environment, the business reasons to publish a
CPS are much more obvious and I believe you will see a much higher
percentage (but not all) of service providers publish at least some form
of a CPS.

On certificate policies I am aware of organizations which are defining
these but again most are not making this information publicly available
at least not at this time.

I would  note however, that draft certificate policies produced within
the Government of Canada (8 of them - 4 for encryption and 4 for digital
signature) were supplied to the ABA ISC at its October meeting as an
informational reference document. I understand that the same drafts were
made available to last week's ANSI X9.45 meeting for information.

Certificate policies are valuable for use within a single security
domain as well as between domains through cross-certification and as
more and more policy definitions become more widely disseminated, it is
my opinion that some adoption of  common ones, at least within industry
sectors, will emerge.
>
Bob said:
>:I'm not aware of any CAs that are actually including a policy OID in their
>:certificates to date -- if someone does know of some examples it might be
>:quite helpful -- maybe even a defacto practice.

Please remember that there is a community of CAs which are operated by
individual corporations which are not offering CA services to the
general public. These include corporate CAs primarily issuing
certificates for their own employees, banks offering services such as
home banking to their own banking customers, and many other scenarios as
well. There is no reason for these organizations to make their policies
and practices publicly known, other than to their own community of
interest (which includes CAs with which they cross certify). Just
because you aren't aware of it doesn't necessarily mean it isn't
happening.
>
>Charles said:
>Its just an OID.

I agree and as such it is merely a tool to convey, through its inclusion
in a certificate, the policy under which a CA issued a cert. It is
valuable in both end-entity certs and cross-certs. The technical, legal,
business and policy issues surrounding the issuance and use of these
OIDs are important but in the end they are only OIDs. PKIX is not the
best venue for determining the legal notice of an OID we should be
making sure that the tools are available within the certificate
structure to support such determinations by the legal community, but not
>try to make those determinations here.
>
>
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>

Date:         Wed, 17 Dec 1997 11:01:52 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stefan Kelm <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

Phillip,

> >I haven't done a recent search, but to the best of my knowledge, only
> >VeriSign has actually published a Certification Practice Statement, and I'm
> >not sure whether they intend to publish a separate Policy document in
> >addition, or not.
>
> Belsign certainly has (they licensed the VeriSign CPS).

a couple of the certification authorities being operated in Germany have
published detailed policies and CPSs. For instance, we (DFN-PCA) have done so.

> >I'm not aware of any CAs that are actually including a policy OID in their
> >certificates to date -- if someone does know of some examples it might be
> >quite helpful -- maybe even a defacto practice.
>
> Signet in Australia does. I would assume most would plan to.

The CAs within the European ICE-TEL Certification Infrastructure
(http://ice-tel.uni-c.dk/ice-ca/) do so, too.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

Date:         Wed, 17 Dec 1997 10:12:21 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 17 December 1997 4:47
Subject: Re: [IETF-PKIX] Critical extensions and Policy OIDs

:Michael,
:
:I think it is anyone's guess.  I don't know of anything in X.509 or in PKIX
:that particularly mandates the USE of the policy OID -- it could be the
ISDN
:number of an unpublished manuscript which resides on the planet Vogon, for
:all anyone knows.
:
:I haven't done a recent search, but to the best of my knowledge, only
:VeriSign has actually published a Certification Practice Statement, and I'm
:not sure whether they intend to publish a separate Policy document in
:addition, or not.

We have both, these are published in closed communities.

:
:I'm not aware of any CAs that are actually including a policy OID in their
:certificates to date -- if someone does know of some examples it might be
:quite helpful -- maybe even a defacto practice.

See our CA certificates in our path,ALL certs will have OIDS from 1st of
January.

:
:Certainly the INTENT of the policy OID as I understand it was to provide
:some kind of shorthand legal notice, in the form of an incorporation by
:reference.

Its just an OID.

Snip
:
:What still isn't clear is the extent to which a policy OID constitutes a
:representation or agreement between the subscriber and the CA, and/or the
:extent to which such a representation by the subscriber can be relied on by
:a relying party.

It is a staement by the CA, as to the certifiaction policy ( NOT practices
that are used)
most Certificate policies include policies regarding subscriber and relying
party policy.
These are enforced by agreements, that refernce the Certifiacet policy(s).

:
:Seems to me that the relying party wants to know two things:  (1)  Under
:what circumstances would the reliance on a digital signature verified by
:reference to a particular certificate constitute a commercially
UNREASONABLE
:transaction, and (2) (the flip side) when would reliance on the digital
:signature be considered the norm.

See above.

Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 4 (????/----) (0001DCAF)

Date:         Tue, 16 Dec 1997 17:21:10 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
To: [email-masked]
Status:

> From: Roland Lockhart <[email-masked]>
>
> The INTEGER precedent has been set in a number of places (PKCS-1, X9.57,
> etc.) and I think any change would lead to confusion and
> interoperability problems.

I'm convinced.

Both the proper encoding of INTEGERS and the use of INTEGERS in algorithm
definitions are well established.  'nuff said.

Date:         Tue, 16 Dec 1997 17:10:12 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
To: [email-masked]
Status:

Roland Lockhart wrote:
>
> Hi,
>
> I am not a regular on this mailing list and maybe I'm a bit late, but
> the OCTET STRING versus INTEGER debate was brought to my attention and
> I'd like to add my two cents.
>
> I oppose the issuing of new OIDs and parameter definitions. I believe
> that INTEGER encoding is absolutely the right way to respresent the
> quantities in question since they are in fact mathematical integers. The
> INTEGER encoding is perfectly suited because it unambiguously defines
> how to respresent the number, i.e., in two's complement form, fewest
> octets possible, with the most significant octet first.

I agree.

>
> I think the answer to the leading 00 octet issue is implied in the
> definition of an INTEGER: two's complement with the fewest octets
> possible. For example, under these rules the number +128 cannot be
> represented in a single octet, so it becomes two octets: 0x00, 0x80. The
> "Layman's Guide to a Subset of ASN.1, BER, and DER" by Burt Kaliski at
> RSA Labs has a good summary of all this. I do agree that the official
> ASN.1 specs are less clear than they could be on this point!
>

If you mean the former ASN.1 standards, X.208/209, I agree. But numerous
defects in these works have been corrected in the current standards,
ASN.1:1994.

> I am surprised that "most current software and certs are wrong". I have
> seen a few wrong ones and lots of right ones from various product
> vendors.
>
> Some ASN.1 compilers, including the one we use, cannot handle large
> INTEGERS (bigger than 32 bits). However, we've been able to work around
> this limitation quite easily.

Many of the vendors working on the SET protocol, which makes heavy use
of
X.509v3 and the ASN.1:1994 standards use an ASN.1
compiler/code-generator
from OSS (www.oss.com) that correctly supports these integer
requirements,
even for integer values which exceed the maximum integer representation
on a given machine. This is accomplished by adding a local directive,
--<HUGE>--, to the SET ASN.1. So, for these implementors, there is no
need for new identifiers.

>
> The INTEGER precedent has been set in a number of places (PKCS-1, X9.57,
> etc.) and I think any change would lead to confusion and
> interoperability problems.
>
> - cheers,
>   Roland Lockhart
>   Entrust Technologies Ltd.
>   Ottawa, Canada
>
> >
> >----------
> >From:  David P. Kemp[SMTP:[email-masked]]
> >Sent:  December 16, 1997 9:34 AM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
> >
> >Thanks to all who replied, either publicly or privately, to my question
> >on INTEGER encoding.
> >
> >The consensus was unanimous (a rare event!) that:
> >
> >  a) cryptographic bignums should *not* be typecast to signed integers at
> >     the ASN.1 coding interface, and therefore must always be encoded
> >     such that the MSBit is zero,
> >
> >  b) most current software and the certs floating around are wrong, and
> >
> >  c) it was a mistake to use INTEGER for cryptographic keys, parameters,
> >     signatures, etc, and that these fields should have been defined as
> >     OCTET STRING or BIT STRING when the algorithmIdentifiers were
> >     created.
> >
> >I will therefore correct the PKIX part 1 examples to add a leading 00
> >octet where needed, and hope that future algorithmIdentifier definitions
> >will use OCTET STRING instead of INTEGER.
> >
> >Is it too late for x9 to assign new OIDs for dsa and rsa using OCTET STRING
> >values, and have PKIX recommend support for the new algorithmIds?
> >
> >

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date:         Tue, 16 Dec 1997 16:13:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Roland Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
Comments: cc: Sharon Boeyen <[email-masked]>, Josanne Otway <[email-masked]>, Carlisle Adams <[email-masked]>
To: [email-masked]
Status:

Hi,

I am not a regular on this mailing list and maybe I'm a bit late, but
the OCTET STRING versus INTEGER debate was brought to my attention and
I'd like to add my two cents.

I oppose the issuing of new OIDs and parameter definitions. I believe
that INTEGER encoding is absolutely the right way to respresent the
quantities in question since they are in fact mathematical integers. The
INTEGER encoding is perfectly suited because it unambiguously defines
how to respresent the number, i.e., in two's complement form, fewest
octets possible, with the most significant octet first.

I think the answer to the leading 00 octet issue is implied in the
definition of an INTEGER: two's complement with the fewest octets
possible. For example, under these rules the number +128 cannot be
represented in a single octet, so it becomes two octets: 0x00, 0x80. The
"Layman's Guide to a Subset of ASN.1, BER, and DER" by Burt Kaliski at
RSA Labs has a good summary of all this. I do agree that the official
ASN.1 specs are less clear than they could be on this point!

I am surprised that "most current software and certs are wrong". I have
seen a few wrong ones and lots of right ones from various product
vendors.

Some ASN.1 compilers, including the one we use, cannot handle large
INTEGERS (bigger than 32 bits). However, we've been able to work around
this limitation quite easily.

The INTEGER precedent has been set in a number of places (PKCS-1, X9.57,
etc.) and I think any change would lead to confusion and
interoperability problems.

- cheers,
  Roland Lockhart
  Entrust Technologies Ltd.
  Ottawa, Canada

>
>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  December 16, 1997 9:34 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
>
>Thanks to all who replied, either publicly or privately, to my question
>on INTEGER encoding.
>
>The consensus was unanimous (a rare event!) that:
>
>  a) cryptographic bignums should *not* be typecast to signed integers at
>     the ASN.1 coding interface, and therefore must always be encoded
>     such that the MSBit is zero,
>
>  b) most current software and the certs floating around are wrong, and
>
>  c) it was a mistake to use INTEGER for cryptographic keys, parameters,
>     signatures, etc, and that these fields should have been defined as
>     OCTET STRING or BIT STRING when the algorithmIdentifiers were
>     created.
>
>I will therefore correct the PKIX part 1 examples to add a leading 00
>octet where needed, and hope that future algorithmIdentifier definitions
>will use OCTET STRING instead of INTEGER.
>
>Is it too late for x9 to assign new OIDs for dsa and rsa using OCTET STRING
>values, and have PKIX recommend support for the new algorithmIds?
>
>

Date:         Tue, 16 Dec 1997 15:00:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] draft meeting minutes
To: [email-masked]
Status:

Warwick,

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Sunday, December 14, 1997 2:33 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] draft meeting minutes
>
>Steve:
>
>Great minutes, as usual!  I have just a couple of suggested mods:

...

>>At the second PKIX WG meeting, a compromise approach was announced,
>>reconciling CRS and CMP...
>
>Following is a proposed revision of this entire paragraph:
>
>At the second PKIX WG meeting, a compromise approach was announced, aimed
>at reconciling differences between CRS and CMP.  In essence, a common
>certificate request message syntax has been agreed, and CMP will adopt this
>syntax as the certificate request payload type within that protocol
>(replacing the current certificate request payload format).  CRS will be
>revised to also reference that syntax.  This new, harmonized certificate
>request format will appear as a separate RFC.  It is not anticipated that
>this will delay the progression of CMP to proposed standard, since it is
>simply a protocol syntax change for alignment purposes plus a splitting of
>one document into two in the interests of facilitating future developments.
> CRS will continue to progress, specifying the mapping of certificate
>management messages onto CMS and providing the vehicle for developing
>common formats for other certificate management messages (i.e., messages
>other than certificate request)."

This reflects what occurred at the PKIX meeting except for the last half
of the last sentence.  "...providing the vehicle for developing common
formats for other certificate management messages..." gives the strong
impression that some or all of the remaining messages will change (as
the request message did).  I don't believe this was ever voiced in my
hearing and I am sure it was not mentioned to the WG.  All that was said
was that over time the remaining messages may migrate out of CMP into
other documents.

Note that with the cert request message we had two formats (CMP and PKCS
#10)  --  nobody wanted two formats so it was necessary that we
harmonize these into a single format.  The compromise made was that this
single format would be new (i.e., neither CMP nor PKCS #10).  We do not
have this situation with any of the other messages (i.e., there *is*
only a single format), so the underlying assumption that we need to
"develop common formats for these other messages" seems unfounded.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 16 Dec 1997 13:05:21 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
Comments: To: [email-masked]
To: [email-masked]
Status:

I agree with the thrust of Al's comments, but would like to throw in an
additional comment.

To me, the primary difference between a hierarchical and a peer relationship
between CA's is not the network topology, but rather the degree of
legal/policy control and the (partial) assumption of liability for the
actions of the subordinate CAs.

If I am operating a corporate level CA for XYZ Corp,  I might choose to go
to a public CA such as VeriSign, GTE, etc., in order to have my CA's
certificate signed by a recognized root key.  (Sooner or later, users are
going to start to rebel about the number of root keys that browser vendors
are gratuitously including in their software, and then maybe some order will
arise from the current chaos.)

As a condition for having my corporate certificate listed under say GTE's
master certificate, I would expect that I would have to sign a binding
agreement concerning policy, perhaps including auditing and other oversight
functions which are intended to protect relying parties and the root CA from
undue liability.

I would also expect that a condition of receiving a certificate from GTE,
there would be obligatory, contractual flowdown requirements that would
govern whether or not my top-level corporate CA could issue certificates to
subordinate CAs within my organization, and if so what policies and policy
OIDs would be incorporated.

Now, what does it mean if two top-level CAs cross-certify each other.  Does
it mean that each will accept full financial liability for the other's
errors and omissions, or for the failure of any of their subordinate CA's
particular failures?  Not bloody likely!

Instead, I believe that the primary use of cross-certification will be to
ACCREDIT other CAs, in the sense of an ADVISORY rating service.  Is the
German government going to undertake any liability for what VeriSign does?
No.  But on the other hand, they might well represent to German consumers
that VeriSign is a well-recognized CA, and appears to meet certain accepted
standards of behavior with respect to their internal operations, auditing,
and other controls. Likewise, VeriSign might cross-certify the German
Government's CA, but without taking any responsibility for their actions.
The differences in the legal regimes makes it very unlikely that any legal
obligations will flow between the CAs.

In the case that someone mentioned, The University of Maryland might either
unilaterally or bilaterally certify Purdue, but again that will only imply
that Maryland recognizes Purdue as a bona fide institution that conforms to
a reasonable set of practices, but it would not imply any contractual or
other liability relationship between the two institutions.

In my mind, therefore, cross-certification is very much like a Standard and
Poor's bond rating service, or maybe just a Dun and Bradstreet confirmation
that a company exists and seems to meet the minimum criteria.  If VeriSign
cross-certifies Billy Bob's CA and Bait Shoppe as a legitimate CA when they
are obviously not legitimate, VeriSign might very well expect to get sued.
But if Billy Bob is in fact a reasonably competent CA that only occasionally
fails to exercise due diligence in issuing certificates, relying parties
should expect to go against Billy Bob, and not VeriSign.  VeriSign completed
their responsibility when they ascertained that Billy Bob was properly
incorporated and had at least the trappings of a viable commercial service,
but they should not be expected to cross-insure Billy Bob's operation.

I would therefore disagree slightly with Al's comments in one particular
area, where he says:

>This contrasts with a peer-based architecture, in which one CA
essentially tells another one "I'll accept your certificates if they
have the following properties.  What else you do is your own business; I
won't interfere, but things that interwork with my users must have the
following properties."  The degree of control is much less.

CA's don't accept other CA's certificates, at least normally -- relying
parties accept certificates.  So the degree of control is even less that Al
intimates. On the other hand, if the IT or MIS department of some
organization essentially dictates to its users what kind of certificates are
to be considered acceptable, then cross-certification may be a way of
controlling that. But outside of the military I would expect that kind of
operation to be the exception rather than the norm.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

Date:         Tue, 16 Dec 1997 14:11:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

Bob writes:

>I haven't done a recent search, but to the best of my knowledge, only
>VeriSign has actually published a Certification Practice Statement, and I'm
>not sure whether they intend to publish a separate Policy document in
>addition, or not.

Belsign certainly has (they licensed the VeriSign CPS).

>I'm not aware of any CAs that are actually including a policy OID in their
>certificates to date -- if someone does know of some examples it might be
>quite helpful -- maybe even a defacto practice.

Signet in Australia does. I would assume most would plan to.

>Corporate lawyers being what they are, I would expect that a Policy issued
>by a CA would be long on defenses against any possible liability on their
>part, and rather short on any possible defenses on the part of the
>subscriber or subject, unless market demands eventually dictate such
>language, or unless a particular strong customer shows up with sufficient
>leverage to force particular language (same thing, I guess.)

Accepting liability is a perfectly reasonable business decision,
the purpose of lawyers is to allow liability to be predicted and
understood, not to eliminate it.

VeriSign is issuing insurance with its certificates which both
provides assurance to certain parties that the certificate can
be relied upon and controls liability. This does not appear
to meet your expectations.

>What still isn't clear is the extent to which a policy OID constitutes a
>representation or agreement between the subscriber and the CA, and/or the
>extent to which such a representation by the subscriber can be relied on by
>a relying party.

That would depend on the nature of the agreement,
various national laws and a body of precedent and
statute yet to be established.

>It seems somewhat unlikely that a CA would actually assume responsibility
of
>the subscriber's use of the issued certs -- at best they would take
>responsibility for the correct identification of the subscriber and the
>binding of the subscriber's public key to the name or other attributes, but
>they aren't about to get into the underwriting business -- at least under
>present business model's.

I would guess that if there were a 'per use' liability
connected with a cert that there would have to be a
'per use' charging model in most cases but I would
not make a stronger statement.

A bank issuing SET certificates is essentially a CA
that assumes responsibility for the subscribers use
of the cert - this is profitable since every transaction
carries insurance.

            Phill

Date:         Tue, 16 Dec 1997 11:19:13 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
Comments: To: [email-masked]
To: [email-masked]
Status:

Michael,

I think it is anyone's guess.  I don't know of anything in X.509 or in PKIX
that particularly mandates the USE of the policy OID -- it could be the ISDN
number of an unpublished manuscript which resides on the planet Vogon, for
all anyone knows.

I haven't done a recent search, but to the best of my knowledge, only
VeriSign has actually published a Certification Practice Statement, and I'm
not sure whether they intend to publish a separate Policy document in
addition, or not.

I'm not aware of any CAs that are actually including a policy OID in their
certificates to date -- if someone does know of some examples it might be
quite helpful -- maybe even a defacto practice.

Certainly the INTENT of the policy OID as I understand it was to provide
some kind of shorthand legal notice, in the form of an incorporation by
reference.

Corporate lawyers being what they are, I would expect that a Policy issued
by a CA would be long on defenses against any possible liability on their
part, and rather short on any possible defenses on the part of the
subscriber or subject, unless market demands eventually dictate such
language, or unless a particular strong customer shows up with sufficient
leverage to force particular language (same thing, I guess.)

What still isn't clear is the extent to which a policy OID constitutes a
representation or agreement between the subscriber and the CA, and/or the
extent to which such a representation by the subscriber can be relied on by
a relying party.

Seems to me that the relying party wants to know two things:  (1)  Under
what circumstances would the reliance on a digital signature verified by
reference to a particular certificate constitute a commercially UNREASONABLE
transaction, and (2) (the flip side) when would reliance on the digital
signature be considered the norm.

Hopefully the difference between these two states would be very small --
almost binary. If there is a lot of gray area in between, either the lawyers
will get rich or electronic commerce will fail to flourish (more likely the
later).

As I understand the problem, disclosure forms in banking can be enforced by
the bank, but the existence of a contract between the bank and one of its
depositors does not form the basis of a suit by some third party who does
not have contractual privity with the depositor (e.g., the subscriber).

It seems somewhat unlikely that a CA would actually assume responsibility of
the subscriber's use of the issued certs -- at best they would take
responsibility for the correct identification of the subscriber and the
binding of the subscriber's public key to the name or other attributes, but
they aren't about to get into the underwriting business -- at least under
present business model's.

Bob

>
>>>> Mike Smith <[email-masked]> 12/12 9:07 AM >>>
>Bob:
>
>Isn't the policy OID referring to the CA's disclosure of practices under
which they will operate AND
>under which they assume responsibility for the subscriber's use of issued
certs?  Don't some act as
>disclosure forms as in bank lending, wherein they govern actions of the
subscribers?
>
>Michael
>
>

Date:         Tue, 16 Dec 1997 12:49:22 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Denis Pinkas wrote:

<snip>
>As a consequence we currently do not define what are hierarchical CAs
>and we do NOT make a difference between hierarchically-based and
>peer-based CAs.
>
>If we were going to introduce the distinction we would need to provide
>more text to address name subordination on various name formats. I
>wonder if this is still appropriate at this time.
>
>(... text deleted)
>
>Denis

I do not believe that name subordination is a requirement for
hierarchically-based CAs.  (I certainly hope it isn't, since we don't
require it for CAs in MISSI :-)

To me, a CA hierarchy is one in which a superior node can constrain what
a subordinate node does - e.g., what policy OIDs it can issue, what
extensions it must/must not/can optionally populate, and maybe (but not
necessarily) what name subordination rules it must follow.

This contrasts with a peer-based architecture, in which one CA
essentially tells another one "I'll accept your certificates if they
have the following properties.  What else you do is your own business; I
won't interfere, but things that interwork with my users must have the
following properties."  The degree of control is much less.

This can be important in an Internet PKI.  Suppose an ISP wanted to
purchase CA workstations from - oh, pick on somebody here - GTE
Internetworking (in honor of our illustrious co-chair) and set up a
hierarchy of CAs for use within that ISP and its customers.  They might
want to set up a strict hierarchy such that the root CA was at the top
of all users' trust chains, and certs were only valid if they derived
from that root CA.  Further, the ISP will allow users to interwork with
certificates from other services only if there were a valid
cross-certificate in place, signed by the ISP's root CA.  This
cross-certificate might be issued to, say, VeriSign (in honor of the
other illustrious co-chair), allowing the ISP's users to interwork with
users under a VeriSign CA so long as the proper policy OIDs, etc. were
present.  The degree of control the ISP exerts over VeriSign is clearly
less than the degree of control it exerts over its own CAs, and this is
significant.

                        Al Arsenault

- Speaking only for myself. My opinions do not necessarily reflect those
of my employer.

>

Date:         Tue, 16 Dec 1997 12:14:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Lowry <[email-masked]>
Subject:      Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
To: [email-masked]
Status:

I disagree that INTEGER is incorrect.  It is correct by
definition.  Those quantities are, in fact, integers.
I do not support the issuing of new OIDs and parameter definitions.

The observation that the encoding of INTEGER is general and typically
results in an inefficient encoding (one additional byte) when applied
to cryptographic integers shouldn't cause any panic.  If efficient
encoding were paramount then ... but I won't go down that path ...  :-)

Other notes:
        It is a rare machine that can handle interesting (e.g. large)
        bignums as signed or unsigned native integers.  I know of
        no one who has made the mistake of typecasting - probably because they
        don't have the right machine.  Have you got a machine with
        2048-bit integers ?   Even 1024 would suffice for me ...

        I don't know what "most current software and the certs" are.
        I suspect that your observation is that folks who try to
        write an ASN.1 DER encoder/decoder have their work cut out
        for them.  They have no excuses though - there are several
        publically available encoder/decoders that they could have
        used as a reference or just plain used.

At 09:34 AM 12/16/97 -0500, David P. Kemp wrote:
>Thanks to all who replied, either publicly or privately, to my question
>on INTEGER encoding.
>
>The consensus was unanimous (a rare event!) that:
>
>  a) cryptographic bignums should *not* be typecast to signed integers at
>     the ASN.1 coding interface, and therefore must always be encoded
>     such that the MSBit is zero,
>
>  b) most current software and the certs floating around are wrong, and
>
>  c) it was a mistake to use INTEGER for cryptographic keys, parameters,
>     signatures, etc, and that these fields should have been defined as
>     OCTET STRING or BIT STRING when the algorithmIdentifiers were
>     created.
>
>I will therefore correct the PKIX part 1 examples to add a leading 00
>octet where needed, and hope that future algorithmIdentifier definitions
>will use OCTET STRING instead of INTEGER.
>
>Is it too late for x9 to assign new OIDs for dsa and rsa using OCTET STRING
>values, and have PKIX recommend support for the new algorithmIds?
>
>

Date:         Tue, 16 Dec 1997 16:51:05 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
To: [email-masked]
Status:

Arsenault, Al W. wrote:

> Warwick, et alia:
>
>         I believe that the term "cross-certification" should stay in the
> document, and that its usage should be essentially that defined by
> Warwick as (3); i.e.,
>
> >(3) Issuance of a certificate by a CA in one organization to a CA in
> >another organization.  (You might substitute "domain" for "organization".)
>
>         and I would substitute "domain" for "organization" because I think that
> it's a more generic term.
>
>         Looking at (2)  Any case of issuance of a certificate by one CA for
> another, this seems to not be sufficient.  To me, there are two cases of
> CA-certificates.  One is hierarchically-based; i.e., a Root CA issues a
> certificate for one of its subordinate CA's.

The notion of hierarchical CAs was originally introduced by ISO, however
... at this time the only naming allowed was the use of distinguished
names and we had a rule to specify subordinate names. In PKIX we now
recognize other name types.

The only places where the terms "subordinate" and "hierarchy" are used
(in "part 1") are in section 1.2.2. with :

A "subordinate CA" is one that is not a root CA for the end entity in
question.
" ... a root CA is at the top of any hierarchy".

As a consequence we currently do not define what are hierarchical CAs
and we do NOT make a difference between hierarchically-based and
peer-based CAs.

If we were going to introduce the distinction we would need to provide
more text to address name subordination on various name formats. I
wonder if this is still appropriate at this time.

(... text deleted)

Denis

--

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Tue, 16 Dec 1997 06:52:30 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] account-authority digitial signature .... fyi
To: [email-masked]
Status:

This is public-key model that i've been working on to handle
the "non-push" implementation for X9.59. This has been
cross-posted to x9a10, x9f5, and spki mailing lists. X9.59 is
designed to be used for any account-based transaction (check,
debit, credit, etc).

Three digital signature models are described; the original "offline"
model and two newer "online" models. It is expected that the two
"online" models become the prevailing modes of operations for much
of electronic commerce

Digital Signature Model 1:
--------------------------
The traditional PKI infrastructure talks about issuing certificates
that are signed by a certificate authority which attest to the:
     validity of the public key
     preferably checking validity of the private key
     possibly some identity information of the entity
        that the certificate is issued to.
The associated PKI-use model has an entity "digitally signing" a
document with their private key and "pushing"
     the transaction/document
     the digital signature
     a copy of their digital certificate
to another party. The receiving party presumably will validate the
authenticity of the digital-signature and the originator's public key
via the contents of the associated digital certificate.  Originally
the contents of the digital certificate was assumed to be sufficient
such that digital signature validation could be performed without any
additional electronic transmissions. As the methodology matured, it
became apparent that more and more complex verification mechanisms
were needed, if nothing else various status could have changed between
the time that the certificate was originally manufactured and the
current moment. Certificate revokation lists (CRLs) were one such
development in an attempt to partially address the issue of current
real-time certificate status in the offline verification model.

Digital Signature Model 2 (or account-based PKI):
------------------------------------------------
This is a proposed implementation for the X9.59 framework. An
account-holder registers their public-key (and verification of their
private-key use) with the account authority. In a transaction the
account-holder digitally signs a transaction and pushes the
transaction, the digital signature, and the account number.
Eventually the transaction arrives at the account authority and the
digital signature is verified using the public key registered in the
account record.  The account authority maintains the status of the
holder's public key as part of the overall account management
process. The transaction therefore requires neither a certificate nor
some complex status methodology (like CRLs) since the account
authority maintains current validity status as part of account
management.
This is effectively the X9.59 check and credit-card models where the
receiving entity/merchant does a real-time authorization with the
account issuing institution. The consumer's digital signature is
forwarded by the merchant to the issuing institution; the issuing
institution authenticates the digital signature using the registered
public-key in the account record.  No signed certificate attesting to
the validity of the public key is required since the public-key is on
file in the account record.
An account-authority performs the majority of the same functions
performed by a certificate authority, but the processing costs are
absorbed by the standard business process ... not by charging for the
issuing of a certificate. It is possible that an account-authority
might also wish to become a certificate authority since it potentially
could be undertaken at less then 5% additional business costs.

Digital Signature Model 3 (positive authentication):
---------------------------------------------------
This is actually a slight variation on #2, although it bears some
superficial resemblance to #1. The initial designs for positive
authentication PKI, used the credit-card authorization model to
replace CRLs. However they kept the rest of the infrastructure; the
originator's certificate was still pushed around with the transaction.
The receiver validated the CA's signature on the certificate, then
sent off a certificate status request and validated the CA's signature
a second time on the status response (and then validated the original
digital signature).
Model #3 looks very much like model #2 in that the originator's
certificate is not pushed around with the transaction. However, rather
than sending the digital signature in the authorization request, just
the certificate identifier (account number) is sent to the CA. The CA
signs a status response that includes information regarding the
real-time validity of the account along with a copy of the account's
public key. In effect the real time status response becomes a
mini-certificate. The entity that will act on the transaction now only
has to verify the CA's signature on the status response (i.e.
mini-certificate, it doesn't also have to verify the CA's signature on
a certificate manufactured at some point in the past). It then uses
the public-key returned in the status response to validate the
originator's digital signature.
Superficially this resembles digital certificate model #1 but the
actual operation is much more like model #2. Including the account's
public-key in the real-time status response creates, in effect, a
mini-certificate. It also eliminates a redundant/superfluous
validation of the CA's digital signature (on both the manufactured
digital certificate and the real-time status responses).
The biggest operational difference between #2 and #3 is that the
account authority verifies the originator's digital signature in #2
and in #3 it just returns the value of the account's public key for
the requester to validate a digital signature.  If the requester can
send the document or even the secure hash of the document to the
account authority along with a copy of the digital signature, then the
account authority can verify the digital signature. If not, the
request just identifies the account and the mini-certificate is
returned allowing the requester to validate the digital signature.
The positive authentication model presents a number of revenue
opportunities for the CA to charge for various levels of detail
returned in real-time status responses (and/or approval levels
associated with the transaction).
Conclusion
----------
Digital signature model #1 was originally developed to allow "offline"
verification of a digital signature. A manufactured certificate was
pushed along with the signed document and the digital signature could
be verified using just the contents of the certificate that was passed
along with the document.
Offline signature verification using a certificate manufactured
several months in the past (and by implication relying on status that
was several months stale) turned out to be inadequate for various
kinds of transactions. This has led to the definition of more
complicated processes in the certificate-push model in an attempt to
provide more timely status and verification.
There has also been the implicit assumption that only the certificate
authority is performing registration services for digital signature
processes. As the concept of digital signatures have become more
acceptable, it has also becoming apparent that existing business
processes (already performing account registration functions) can be
simply extended to add public-key registration.
Revisiting the PKI basic architecture, it became apparent that there
were several optimizations possible if it was recognized there were
significant numbers of online PKI operations (compared to earlier
models that started out assuming offline PKI and later tried to graft
online features afterwards).
The offline validation and certificate push model is still valid for
some types of transactions and shouldn't be precluded. However, real
online validation (models #2 and #3) can eliminate some number of
superfluous operations.
It should be noted that the "offline" validation is different than the
"offline" purchasing referred to in X9.59. X9.59 assumes that the
consumer can be offline and transmits an order and payment
instructions via methods like email (not requiring real-time, online
interaction with the merchant).  In the validation process, there is
an issue whether the merchant is also offline at the point that it
approves the transaction.  If the merchant is offline, then it needs a
consumer certificate to validate (and authorize) the consumer
transaction. If the merchant is online, then either model #2 or model
#3 is used (and it is not necessary for the consumer to push the
certificate with the transaction). Furthermore, in the case of model
#2, either the merchant can perform its own PKI registration function
and/or it can rely on a financial account infrastructure to have
implemented a PKI registration function.
It is expected that digital signature models #2 and #3 become the
prevalent modes of operation for at least financial transactions.

Denial of service attack addenda
--------------------------------
There is a hypothetical case (that can be made for certificate pushing
in the online world) which is associated with anonymous denial of
service attacks. The existing Internet infrastructure provides
significant opportunities for electronic terrorists to anonymously
(and/or under assumed identity) launch denial of service attacks
(flooding a web site with enormous number of bogus requests). These
are undertaken with the assumption that it is nearly impossible to
trace the source of the attack.
One of the techniques for dealing with denial of service attacks is to
recognize and eliminate bogus requests as soon as possible. If a
certificate is pushed with a request then some preliminary screening
of requests can be performed during initial processing and possibly
eliminate some number of bogus transactions.
The downside is that public key operations are extremely expensive;
preliminary screening of a request using the certificate (and still
doing the online validation later) could be more expensive than
allowing bogus transactions through and recognizing them via the
standard mechanism.
Most of these are simple band-aid solutions. The real problem is that
existing Internet backbone operation makes it simple to impersonate a
network address. As a result it is usually very difficult to trace
back to the originator of an electronic attack.

Date:         Tue, 16 Dec 1997 09:34:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
To: [email-masked]
Status:

Thanks to all who replied, either publicly or privately, to my question
on INTEGER encoding.

The consensus was unanimous (a rare event!) that:

  a) cryptographic bignums should *not* be typecast to signed integers at
     the ASN.1 coding interface, and therefore must always be encoded
     such that the MSBit is zero,

  b) most current software and the certs floating around are wrong, and

  c) it was a mistake to use INTEGER for cryptographic keys, parameters,
     signatures, etc, and that these fields should have been defined as
     OCTET STRING or BIT STRING when the algorithmIdentifiers were
     created.

I will therefore correct the PKIX part 1 examples to add a leading 00
octet where needed, and hope that future algorithmIdentifier definitions
will use OCTET STRING instead of INTEGER.

Is it too late for x9 to assign new OIDs for dsa and rsa using OCTET STRING
values, and have PKIX recommend support for the new algorithmIds?

Date:         Tue, 16 Dec 1997 09:01:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
To: [email-masked]
Status:

Warwick, et alia:

        I believe that the term "cross-certification" should stay in the
document, and that its usage should be essentially that defined by
Warwick as (3); i.e.,

>(3) Issuance of a certificate by a CA in one organization to a CA in
>another organization.  (You might substitute "domain" for "organization".)

        and I would substitute "domain" for "organization" because I think that
it's a more generic term.

        Looking at (2)  Any case of issuance of a certificate by one CA for
another, this seems to not be sufficient.  To me, there are two cases of
CA-certificates.  One is hierarchically-based; i.e., a Root CA issues a
certificate for one of its subordinate CA's.  The other is more
peer-based; i.e., a CA for the University of Maryland issues a
certificate for the CA for Purdue University, stating under what
conditions Maryland people may accept Purdue-issued certificates.
Warwick's definition (2) does not make this distinction between
hierarchical and peer-to-peer CA certificates, and I personally believe
that it is an important distinction to preserve.

        Why do I think that the distinction needs to be preserved?  First,
because the trust properties - specifically, issues of transitivity -
are different. In the hierarchical case, I as a subordinate CA have to
trust what my superior CA does - if I don't I shouldn't be her
subordinate.  Similarly, as a Root CA, I trust (and constrain) what my
subordinate can do. Such a relationship does not exist in a peer-to-peer
relationship.  There, I decide that I will choose to trust you for
certain actions, under certain circumstances.  (Note that there is no
requirement that cross-certificates be issued in both directions;
one-way cross-certification is perfectly logical in some scenarios.)

        Second, the certificate path validations with cross-certificates can
get almost arbitrarily complex if transitive trust is permitted - it can
degenerate to almost  a "web of trust" model.  Applications should be
aware of this when trying to construct certificate paths.

                        Al Arsenault
        - Speaking for myself.  My opinions do not necessarily represent those
of my employer.
>

Date:         Tue, 16 Dec 1997 10:53:25 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Farrell <[email-masked]>
Subject:      [IETF-PKIX] OCSP Change Request
To: [email-masked]
Status:

Hi All,

The OCSP draft is very close to solving a number or problems which
we've seen arise when developing certificate handling applications. Basically
whilst the code to verify a certification path is relatively simple, the code
to
find a certification path and related CRLs is very hard! (Consider delta-CRLs,
NULL-DNs + many alternate names, etc.)

I'd like to suggest we supplement the current OCSP draft so as to allow the
OCSP
client to choose whether or not to blindly believe the OCSP server whilst at
the same time allowing the OCSP client programmer to avoid the complexity
of writing path traversal and CRL (esp. delta CRL) handling code.

Specifically, I'm asking for support for the following requirements:

1. OCSP servers which are not CAs (e.g. just a certificate validation engine
and LDAP client) to be fully supported.
2. The OCSP protocol should provide a means to relieve OCSP clients from the
burden of certificate path traversal and CRL checking whilst allowing the
client to
(re-)verify the certification path itself (or archive the path & CRLs used).
3. The OCSP client should be able to indicate in the request (as an
extension) that a previously returned path is not acceptable, and that the
OCSP server should respond with the ãnextä path (if any) for the certificate.

Consequences:

The current protocol almost supports the above. Changes which would
support the above could be:

1. The standard response message should include a MessageId field. This
allows the client to reference a response previously received which
contains a path deemed unacceptable by the OCSP client. Note that this
does not affect caching of responses. (A HREF would also suffice.)
2. The standard response should include the base64 encoding of the entire
path and set of CRLs used to verify the certificate. There is very little
overhead involved as the OCSP server must possess all the relevant
items.
3. A request extension should be defined which means ãgive me the next
path for response <<MessageId>>ã. The response should contain an
alternate certification path (+ CRLs) for the initial request. Of course the
second response contains a different MessageId so that iteration is
supported. Again this response can be cached without problems. (Or
nothing is needed if a HREF is present.)

Some further requirements which could be proposed (though I'âm luke-warm
about these myself):

1. Allow the OCSP client to supply a set of partial paths in the request
(might
be too much data though).
2. Allow the OCSP client to specify which root CAs are acceptable to it. (This
may also affect the key which the OCSP server uses to sign the response!)

In addition Iâ'd note that the OCSP server should be chosen by (e.g.
configured into) the OCSP client. Using a cert extension to name the OCSP
server seems to open up security holes - e.g. it would allow the OCSP server
to masquerade as a CA to any of its clients..

A final comment. I question the utility of a policy OID in the request. As
this is
apparently not intended to be a value from a certificatePolicies extension it
is
not clear who will ever define OIDs so that interoperability wonâ't be
impeded.

Iâ'd suggest either, a) change this to a request extension with a string
syntax
(as the global uniqueness of the OID gains nothing), or, b) limit this to be
an
OID which represents the policy OID input to the certificate validation
algorithm as given in X.509.

Regards,
Stephen.

--
==========================================================================
Stephen FARRELL......................................tel:  +353-1-676 9089
Software and Systems Engineering Ltd......................................
Fitzwilliam Court....................................fax:  +353-1-676 7984
Leeson Close.................................email: [email-masked]
Dublin 2...........................................www: http://www.sse.ie/
IRELAND................................................"A Siemens Company"
==========================================================================

Date:         Tue, 16 Dec 1997 09:56:05 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] Terminology - Cross-Certification
To: [email-masked]
Status:

Warwick Ford wrote:
>
> I believe the term "cross-certification" continues to be an ill-defined and
> confused term in PKI.  Prior to publication of the PKIX Proposed Standards,
> we maybe have one last chance to square this away.

I agree.

> While precise definitions of cross-certification are hard to find,
> different interpretations that I have encountered include:
>
> (1) In an essentially-hierarchical CA structure, issuance of a certificate
> that is not in accordance with that hierarchy.
>
> (2) Any case of issuance of a certificate by one CA for another.
>
> (3) Issuance of a certificate by a CA in one organization to a CA in
> another organization.  (You might substitute "domain" for "organization".)
> Note that (2) and (3) are different, since, in the general case, an
> organization has a structure of multiple CAs.
>
> (4) The situation in which any two CAs issue certificates for each other.
>
> (5) The situation in which two CAs, each in a different organization, issue
> certificates for each other.
>
> Note that X.509 is of no help - it is highly ambiguous.
>
> With a view to us firming-up a common terminology, following are some
> suggestions:
>
> I don't think (1) is a good interpretation of "cross-certification", and I
> don't think this needs its own term at all, e.g., in Secure Electronic
> Commerce we just spoke of "hierarchical structure with additional links".
>
> I suggest that (2) would most appropriately be called CA-certification,
> since the result is a "CA-certificate", a defined term in X.509.

Yes. It is defined as " A certificate for one CA issued by another CA."
(see Amendment 1 to ISO/IEC 9594-8:1995 (E) Section 3.3. See
ftp://ftp.bull.com/pub/OSIdirectory/Certificates/Certificates1Dec.DOC

> I believe (3) represents the most common interpretation of
> "cross-certification" in the public's mind.  (Although, to avoid confusion
> we called this "inter-domain certification" in Secure Electronic Commerce.)
>
> I think that (4) and (5) bring in a separate issue, which is not of much
> practical significance anyway.  I believe that it is coincidental if two
> organizations find they can both issue certificates simultaneously in both
> directions between precisely the same two CAs, one in each organization.
> Where this does prove to be a practical requirement, and can be achieved, I
> believe we have the special case of "mutual CA-certification", "mutual
> inter-domain certification" or "mutual cross-certification" as applicable.
>
> My preference would be to avoid the term "cross-certification" entirely,
> and instead adopt:
> (1) - no term needed -,
> (2) "CA-certification",
> (3) "inter-domain certification",
> (4) "mutual CA-certification", and
> (5) "mutual inter-domain certification".
>
> If we keep using "cross-certification", then I suggest we settle on it
> being (3).

My preference would be for (2) (i.e. CA-certification), since what is
"inter-domain certification" may be hard to define and agree upon.

> In PKIX, this presents a minor problem, since it would seem that the
> PKIX-CMP usage of the term is (2).  Changing the PKIX-CMP term to
> "CA-certification" is possible, and probably a good idea, before
> publication as Proposed Standard.

I support this conclusion.

Denis

--

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Mon, 15 Dec 1997 13:42:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] draft meeting minutes
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]
Status:

Steve, on the LDAP piece, just a minor rewording proposal. LDAPv2
profile is completed and both PKIX WG and IETF last calls completed. It
needs to be forwarded to IESG for approval. LDAP v3 profile is a
subsequent activity to begin sometime in early '98.

"" LDAP issues revolve around v2 vs. v3 usage""

I propose replacing this sentence with :  LDAP v2 profile completed both
last calls and is to be forwarded to IESG for approval.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>

Date:         Mon, 15 Dec 1997 12:47:57 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Terminology - Cross-Certification
To: [email-masked]
Status:

I believe the term "cross-certification" continues to be an ill-defined and
confused term in PKI.  Prior to publication of the PKIX Proposed Standards,
we maybe have one last chance to square this away.

While precise definitions of cross-certification are hard to find,
different interpretations that I have encountered include:

(1) In an essentially-hierarchical CA structure, issuance of a certificate
that is not in accordance with that hierarchy.

(2) Any case of issuance of a certificate by one CA for another.

(3) Issuance of a certificate by a CA in one organization to a CA in
another organization.  (You might substitute "domain" for "organization".)
Note that (2) and (3) are different, since, in the general case, an
organization has a structure of multiple CAs.

(4) The situation in which any two CAs issue certificates for each other.

(5) The situation in which two CAs, each in a different organization, issue
certificates for each other.

Note that X.509 is of no help - it is highly ambiguous.

With a view to us firming-up a common terminology, following are some
suggestions:

I don't think (1) is a good interpretation of "cross-certification", and I
don't think this needs its own term at all, e.g., in Secure Electronic
Commerce we just spoke of "hierarchical structure with additional links".

I suggest that (2) would most appropriately be called CA-certification,
since the result is a "CA-certificate", a defined term in X.509.

I believe (3) represents the most common interpretation of
"cross-certification" in the public's mind.  (Although, to avoid confusion
we called this "inter-domain certification" in Secure Electronic Commerce.)

I think that (4) and (5) bring in a separate issue, which is not of much
practical significance anyway.  I believe that it is coincidental if two
organizations find they can both issue certificates simultaneously in both
directions between precisely the same two CAs, one in each organization.
Where this does prove to be a practical requirement, and can be achieved, I
believe we have the special case of "mutual CA-certification", "mutual
inter-domain certification" or "mutual cross-certification" as applicable.

My preference would be to avoid the term "cross-certification" entirely,
and instead adopt:
(1) - no term needed -,
(2) "CA-certification",
(3) "inter-domain certification",
(4) "mutual CA-certification", and
(5) "mutual inter-domain certification".

If we keep using "cross-certification", then I suggest we settle on it
being (3).

In PKIX, this presents a minor problem, since it would seem that the
PKIX-CMP usage of the term is (2).  Changing the PKIX-CMP term to
"CA-certification" is possible, and probably a good idea, before
publication as Proposed Standard.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 15 Dec 1997 11:58:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Suggestions for Key Usage Profile
To: [email-masked]
Status:

> From: Simonetti David <[email-masked]>
>
> Tim (et al),
>
> As you stated at the meeting last week with respect to the key usage
> profile, I
> agree that PKIX should not restrict the bit combinations.  However, I
> think the previous discussions on this topic proved obvious that there
> are multiple interpretations of these bits.
     [...]

All,

I agree with Dave S's suggested clarifications to the keyUsage extension.

Dave Kemp

Date:         Mon, 15 Dec 1997 11:51:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      [IETF-PKIX] Suggestions for Key Usage Profile
Comments: To: Tim Polk <[email-masked]>
To: [email-masked]
Status:

Tim (et al),

As you stated at the meeting last week with respect to the key usage
profile, I
agree that PKIX should not restrict the bit combinations.  However, I
think the previous discussions on this topic proved obvious that there
are multiple interpretations of these bits.

In an attempt to clarify the meaning of several of the bits, I suggest
the following editorial changes to PKIX-1:

Section 4.2.1.3, paragraph beginning with "The digitalSignature bit is
asserted...", add the following, "The digitalSignature bit should be set
when the key is for use in ephemeral applications, e.g., for a single
session authentication application such as SSL."

Paragraph beginning with "The nonRepudiation bit is asserted...", add
the following, "The nonRepudiation bit should be set when when the key
is used to sign an object which may require the validation of the
signature at a future time."

I also suggest adding, "If the key may be used for both digitalSignature
and nonRepudiation applications, both bits may be set."

Finally, after the descriptions of encipherOnly and decipherOnly I
suggest adding the following:

"The encipherOnly and decipherOnly key usages are intended to provide
support for key agreement schemes where separate shared secret keys are
used in each direction of communication.  In such a scheme, a user has
more than one set of key pairs and bits 7 (encipherOnly) and 8
(decipherOnly) are used to distinguish between the two types.  The
originator of a message would use the recipient's public key certificate
with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
encryption key.  The recipient would use the originator's certificate
with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
encryption key.  Typically the originator would pass his own certificate
with bits 4 and 8 along with the message."

Regards,

Dave Simonetti

Date:         Mon, 15 Dec 1997 08:16:20 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Deepak Nadig <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on IPKI Part V: Time Stamp Protocols
Comments: To: Robert Zuccherato <[email-masked]>
To: [email-masked]
Status:

Robert,

I have answered your questions below.

At 09:16 AM 12/15/97 -0500, Robert Zuccherato wrote:
>Deepak;
>
>Thanks for your comments on our time stamp document.  My responses are
>below.
>
>>----------
>>From:         Deepak Nadig[SMTP:[email-masked]]
>>Sent:         Saturday, December 06, 1997 6:52 PM
>>To:   [email-masked]
>>Subject:      Comments on IPKI Part V: Time Stamp Protocols
>>
>>Hi,
>>
>>The following are my comments on the specification.
>>
>>1. [Page 2, Section 2.2]
>>
>>    The semantics of a 'valid request' should be described. I can only
>>derive that a valid request is one that can be decoded properly. Is
>>there more ?
>
>A valid request is one that can be decoded properly, has the correct
>form, has the correct TSA name.  This will be made more clear.
>>
>>2. [Page 2, Section 2.4]
>>
>>    It looks like the TMP is restricted to timestamp messages. Shouldn't
>>the TMP timestamp any data, and leave the contents of the data to be
>>defined by the application ? If the concern is the size of the data,
>>then TMP should recommend that the sizes be made small by sending the
>>Digest of the data (I would recommend the use of PKCS DetachedDigest
>>type here), instead of the data itself.
>
>I believe that is what the document currently says.  I will review it to
>see if we can make this clearer.
>>
>>3. [Page 2, Section 4]
>>
>>    I recommend that the request message should carry a Nonce that is
>>reflected in the response. This is to prevent replay attacks.
>
>Agreed.
>>
>>4. [Page 2, Section 4]
>>
>>   I would recommend that the messages also carry a version field in
>>them. In general, this applies to other PKI protocol messages (like
>>OCSP, etc.) as well.
>
>Fair enough.
>>
>>5. [Page 2, Section 4]
>>
>>   Following (2), messageImprint should be an open type.
>>
>>6. [Page 3, Section 4]
>>
>>   Please consider using PKCS SignedData for defining the response
>>message. Is there a reason why it is not used ?
>
>Is there a reason why we should use PKCS SignedData instead of what we
>have defined?

The PKCS SignedData is already used in many protocols to carry Signed Data.
I recommended this to allow existing implementations to reuse that component.

Please note that you may need to define a profile (specific PKCS #9
attributes) for SignedData that carries Time Stamp Protocols data.

What you have defined is fine; I was trying to reduce the number of
representations of data structures that carry signed data.

>>
>>7. [Page 3, Section 7]
>>
>>   Applications using TMP should also be concerned about the the amount
>>of time it is willing to wait for a response. A 'man in the middle' can
>>introduce delays in the request message, to determine the time that the
>>application sees in the response.
>
>This could be included under "Security Considerations".

Yes. That would be the best place for it.

Regards
Deepak
----------------------------------------------------------------------------
Deepak Nadig                                                    email: [email-masked]
Payment Protocols Group                                 Phone: 415-463-1217
Internet Commerce Division, VeriFone                    Fax:   415-462-6369

Date:         Mon, 15 Dec 1997 09:16:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on IPKI Part V: Time Stamp Protocols
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Deepak;

Thanks for your comments on our time stamp document.  My responses are
below.

>----------
>From:  Deepak Nadig[SMTP:[email-masked]]
>Sent:  Saturday, December 06, 1997 6:52 PM
>To:    [email-masked]
>Subject:       Comments on IPKI Part V: Time Stamp Protocols
>
>Hi,
>
>The following are my comments on the specification.
>
>1. [Page 2, Section 2.2]
>
>    The semantics of a 'valid request' should be described. I can only
>derive that a valid request is one that can be decoded properly. Is
>there more ?

A valid request is one that can be decoded properly, has the correct
form, has the correct TSA name.  This will be made more clear.
>
>2. [Page 2, Section 2.4]
>
>    It looks like the TMP is restricted to timestamp messages. Shouldn't
>the TMP timestamp any data, and leave the contents of the data to be
>defined by the application ? If the concern is the size of the data,
>then TMP should recommend that the sizes be made small by sending the
>Digest of the data (I would recommend the use of PKCS DetachedDigest
>type here), instead of the data itself.

I believe that is what the document currently says.  I will review it to
see if we can make this clearer.
>
>3. [Page 2, Section 4]
>
>    I recommend that the request message should carry a Nonce that is
>reflected in the response. This is to prevent replay attacks.

Agreed.
>
>4. [Page 2, Section 4]
>
>   I would recommend that the messages also carry a version field in
>them. In general, this applies to other PKI protocol messages (like
>OCSP, etc.) as well.

Fair enough.
>
>5. [Page 2, Section 4]
>
>   Following (2), messageImprint should be an open type.
>
>6. [Page 3, Section 4]
>
>   Please consider using PKCS SignedData for defining the response
>message. Is there a reason why it is not used ?

Is there a reason why we should use PKCS SignedData instead of what we
have defined?
>
>7. [Page 3, Section 7]
>
>   Applications using TMP should also be concerned about the the amount
>of time it is willing to wait for a response. A 'man in the middle' can
>introduce delays in the request message, to determine the time that the
>application sees in the response.

This could be included under "Security Considerations".

        Robert.
>
>

Date:         Sun, 14 Dec 1997 22:40:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] draft meeting minutes
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]
Status:

Steve,

At 09:09 AM 12/11/97 -0500, you wrote:
> . . .
>OCSP
>
>Mike Myers provided a status review for this I-D, and responded to
>comments that have appeared on the WG list over the last few weeks.  A
>number of modifications will be made as a result of these comments
>Mike described a schedule for revisions and (new) comments to bring
>OCSP to WG last call in time for the next (LA) IETF meeting.  Included
>in the revisions will be a better characterization of the contexts in
>which OCSP are expected to operate, since that range of environments
>has grown since OCSP was initially designed.

I would add the following text to the above:

"To better accomodate this diversity, a document structure was proposed
that established a base OCSP document and syntax and one or more
supplementary texts that build upon the base syntax."

Mike

Date:         Sun, 14 Dec 1997 20:53:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] ISC Meeting Notice - January 11-12 San Francisco
To: [email-masked]
Status:

<x-rich><excerpt>For the information of ietf-pkix subscribers....

============================================================================

PRELIMINARY MEETING NOTICE

============================================================================

Please correspond with:

  Michael S. Baum, Esq.

  One Alewife Center, Suite 350

  Cambridge, MA 02140 USA

  V: +1 617.661.1234

  F: +1 617.661.0716

  E: [email-masked]

Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE - JAN. 11-12, 1998
- SF

Dear Committee Member and Prospective Members:

You are cordially invited to participate in a meeting of the Information
Security Committee, Section of Science & Technology, American Bar
Association, on Sunday-Monday, January 11-12, 1998, at the Fairmont Hotel
in San Francisco. The Committee will continue its advancement of public
key infrastructure legal and control issues, and will include further
work on CA accreditation, commercial key recovery guidelines, PKI
evidentiary issues, digital signature legislative initiatives, and CA /
user liability, among other matters.

Consistent with Section policy, ISC meeting participants must be members
of both the ABA and the ABA Section of Science and Technology.  Please
contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
988.5628, or email: [email-masked] for membership information.
You can become a paid member of the ABA and the ISC at the January 11-12
meeting -- and affiliate ABA membership is available for non-lawyers.

Meeting details appear below. I look forward to seeing you in San
Francisco.

Sincerely,

Michael S. Baum

Chair, Information Security Committee

Section of Science & Technology, ABA

---------------

<center>INFORMATION SECURITY COMMITTEE

Section of Science & Technology, ABA

January 11-12, 1998

</center>

Agenda

(In extended sessions, breaks will be taken as needed.)

January 11, 1998 - Sunday

 8:30- 9:00     Greetings, coffee, administrative matters

 9:00- 9:30     Introductions, meeting logistics, general announcements

 9:30-10:30     Updates by Work Groups

10:30-12:00     WG breakouts

12:00-13:00     Lunch speaker: Andreas Mitrakas, Ph.D., Erasmus University,
Netherlands

13:00-17:00     WG breakouts

17:00-???       Watering hole discussions; possible continuation of WG
meetings

January 12, 1998 - Monday

 8:30-09:00     Breakfast, et cetera

 9:00-09:30     Administration update

 9:30-12:00     Breakout sessions; Legislative WG conference call

12:00-13:00     Lunch speaker: Congresswoman Eshoo (tentative)

13:00-16:00     WG wrap-ups

15:00-17:00     WG presentations

Additional proposed agenda items, and speakers should be emailed to
Michael Baum ([email-masked]).

---------------------------------------

<center>Information Security Committee - San Francisco

Electronic Commerce Division, Section of Science and Technology

MEETING DETAILS

January 11-12, 1998

</center>

Members are urged to participate in one of the work groups that will be
presenting/meeting during the ISC's meeting. Please contact Ruven
Schwartz, Esq. ([email-masked]) for further information.

**Accreditation Work Group

Contacts:       Charlie Merrill, Esq. ([email-masked])

                Rick Hornbeck ([email-masked])

                Lynn McNulty ([email-masked])

The Accreditation Work Group (About 50 technologists and attorneys in
three sections: Process, Technical Standards, and Legal and Business
Standards) will continue work on its draft document, "Accreditation:
Evaluation of CAs and PKI", with a view toward distributing a draft on
the Internet for industry comments shortly after the end of the year.

**Comparative Law Work Group

Contacts:       Serge Parisien, Esq. ([email-masked])

                Suzanne Thibodeau  ([email-masked])

The Comparative Law work group will continue its exploration of the
requirements for PKI in civil law and other legal jurisdictions. It will
also continue efforts to harmonize legal infrastructure with the common
law.

**Digital Signatures Laws & Regulations

Contacts:       Kenneth Allen, Esq. ([email-masked])

                Dan Greenwood, Esq. ([email-masked])

                Dale Juffernbruch, Esq. ([email-masked])

The Legislative and Regulatory Working Group will hold its periodic
conference call, to discuss updates to legislation and regulation
regarding electronic authentication. The Leg./Reg. Working Group will
also continue to explore the relationship between legislation in this
area and accreditation of Certification Authorities; further pursue the
evidentiary effects of electronic authentication, and discuss litigation,
to the extent any exists.

**Evidentiary Work Group

Contacts:       Gary Fresen, Esq. ([email-masked])

                Serge Parisien, Esq. ([email-masked])

The Evidentiary Work Group will continue its drafting of the judicial
tutorial (a tutorial for judges to admit technology into evidence) and
report on its coordination activities with record management standards
authorities. The working group members will also assist the other working
groups on their evidentiary issues.

**Global Trade Work Group

Contacts:       Joseph Alhadeff ([email-masked])

Lisa Kinard ([email-masked])

Linda Macintosh ([email-masked])

The Global Trade Work Group identifies and collaborates with trade groups
whose work influences secure global trade and reports critical issues
back to the ISC. The WG is developing an overall framework to structure
and analyze secure trade issues; and is preparing an issues statement
concerning cooperation between legal, business and technological
professionals to reduce secure electronic international trade barriers.

**Key Recovery Work Group (KRWG)

Contacts:       Emily Frye, Esq. ([email-masked])

                Dwight Olson, Esq. ([email-masked])

The KRWG concentrates its efforts in two ways.  First, it monitors
proposed legislation and regulations, both here and abroad, that address
key recovery.  The KRWG offers comments where it thinks they would be
appropriate.  The KRWG's larger work is a document addressing the
framework and operation of a key recovery center. Work is in the advanced
outline stage and will focus on fleshing out draft text.

**Liability Work Group

Contacts:       Maureen Adamache, Esq. ([email-masked])

                Elise Reed ([email-masked])

The Liability Work Group will continue its work with the Accreditation
Group on the liability issues, including preparing liability policy
statements and also suitable clauses for inclusion in  PKI/CA-user and
PKI/CA cross-certification agreements. It will also continue its analyses
of the liability of application software providers, and for other
(non-digital signature, non-confidentiality encryption) applications of
public key cryptography. Finally, it will consider technical methods of
solving the legal problem of binding relying parties.

<paraindent><param>out,out</param>Attire for the meeting:

        Sunday-casual; Monday-business attire.

</paraindent>

<paraindent><param>out</param>First-time participants planning to attend
the January 11-12 meeting: Please contact Ruven Schwartz, ISC ViceChair,
at 612-687-8095 or [email-masked], for any questions, and
to coordinate work-product contributions for the upcoming meeting.

</paraindent>

Meeting Location:

        Crystal Room, Fairmont Hotel, on Nob Hill in San Francisco
<<[email-masked]>

Meals: TBD

Lodging: Many of you will already be in San Francisco for the RSA Data
Security Conference, and we recommend extending your stay to include
Sunday and Monday. For hotel information see <<www.hotelres.com/>.

RSVP: Please confirm your intention to participate to Ann Kowalsky,
Section Manager, Section of Science and Technology
([email-masked]) as soon as possible.

See you in San Francisco.

==============================================================

</excerpt><<<<<<<<

---------------------------------------------------------------------

Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140

   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716

---------------------------------------------------------------------
</x-rich>

Date:         Sun, 14 Dec 1997 20:52:54 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

I know we did not express things very well but, with the current model in
X.509 (like it or not), there are two quite distinct uses of cert policies
in certs:

1. A relying party may only find a chain acceptable to its purposes if
certain policies are declared by CAs.
2. A CA may only stand behind a cert if it is used, by a relying party, in
accordance with a certain policy stipulated by the CA.

In general, 1 is supported by noncritical Cert Policy extensions and by the
explicit policy indicator in the Policy Constraints extension; and 2 is
supported by critical Cert Policy extensions.  Don't mix these up.

The calculation of the intersection of the two sets at one point in the
validation algorithm is purely a performance expedient -- it so happens
that if there is a null intersection of these two sets at this point then
there is no way you can end up with a validated chain, hence you might as
well exit.

Warwick

At 05:06 PM 12/12/97 -0500, Rich Ankney wrote:
>Bill Burr said:
>> Note that no input to the cert. path processing procedure includes any
>> rules or way to understand what is implied by any policy.  Some
>application
>> simply sets, possibly under user control, the initial-policy-set of
>> policies that it will accept.  If we assume a general purpose certificate
>> path processing module, hopefully serving all the different applications
>> that may use certificates, it’s hard to envision how any automatic
>> enforcement of  critical policies can be accomplished in the cert. path
>> processing procedure.  I can’t believe that certificate path processing
>> module can reasonably check for anything except the initial-policy-set,
>if
>> it sees a certificate policy field that is flagged critical.  I for one
>at
>> least, certainly want to divorce the certificate path processing from any
>> obligation to understand the application, or we wind up with a different
>> cert. path processing module for every application, I’m afraid.  And
>X.509,
>> it seems to me is not really, nor should it be, an application standard.
>>
>
>Farther down in the description of path processing, X.509 states that, when
>a critical policy extension is encountered, that set of policies is
>intersected
>with the current value of "authority-constrained-policy-set", which is
>initialized
>to "any-policy".  This is checked vs. what the user input as
>"initial-policy-set"
>to make sure their intersection is not empty. The "authority-constrained-
>policy-set" is returned from the path-processing algorithm.  It seems to me
>that this will cause the behavior we (or at least I) want:  only critical
>policies are allowed to make it through path processing, and be returned to
>the caller, even if
>the user input "any-policy" initially.  I suspect that what should be
>returned
>is the intersection of the authority-constrained set and the
>user-constrained
>(initial) set, though; but that may be a flaw in X.509.
>
>Regards,
>Rich
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sun, 14 Dec 1997 16:42:18 +0200
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
Comments: To: [email-masked]
To: [email-masked]
Status:

David,

In your reply I didn't found any refernce to to use of the policy
constraints extention with the requireExplicitPolicy field.
>From section 4.2.1.12 of the Oct 14th draft of part 1:

   If the requireExplicitPolicy field is present, subsequent
   certificates must include an acceptable policy identifier. The value
   of requireExplicitPolicy indicates the number of additional
   certificates that may appear in the path before an explicit policy is
   required.  An acceptable policy identifier is the identifier of a
   policy required by the user of the certification path or the
   identifier of a policy which has been declared equivalent through
   policy mapping.

Thus if that extension apear in the certificate path (and it is critical),
any application without a specific policy requiremnt cannot accept that
certificate, which is, I belive what you want.

However there is another issue with critical certificate policies - what
an application should do when it encounters a combination of known and
unknown OIDs? In order to support your example an application should
reject that certificate.

Now let assume that in your example the organization starts replacing
software based keys, whith hardware token, and whishes to specify it
in a certificate policiy OID so that later it will be able to give
different access for people that have a hardware token (because their
key is more secure).

In a later stage, some of the application may be configured to accept only
hardware tokens' certificate.

But the first thing that will happen is that all the application will refuse
to accept the new certificate because they are unaware of that new extension.
Every single application will have to be reconfigured BEFORE the new
certificate are distributed.

If there is a need for a "critical" certificate policies (that is a certificate
policy that degrade the trust of that certificate) we should have a way
to put in the same certificate both "critical" OIDs and non-critical OID.

        Moshe Litvin

> Moshe,
>
> I respectively disagree with your analysis.  The paranthetical of PKIX-1
> is not a reference to cert path validation, but rather is a reference to
> how the application *uses* the certificate after validation (please
> let's not debate the merits applying requirements to the application).
> This is described in X.509 by the quotation I provided in my previous
> message.
>
> As an example of a use of a critical certificate policies extension,
> let's say that I'm a CA generating and signing certificates for my
> private community.  By signing the certificate I am vouching for the
> identity of the certificate subject.  I'm concerned about by my
> liability if an individual decides to misuse her/his certificate outside
> of my community, so within my certificate policy is a statement that the
> certificate may never be used for any purpose outside of the community.
> I then include the OID of that policy in the certificate policies
> extension of every certificate that I generate, and I indicate the
> extension as critical.
>
> X.509 states that the certifcate with this extension as critical "shall
> only be used for the purpose...implied by one of the indicated
> certificate policies."  As a result, an application that claims
> X.509-compliance cannot use this certificate for a purpose other than
> that stated in the registered certificate policy.  It's not entirely
> clear to me yet how an application can truely restrict the use of a
> certificate in this manner, but in any case, as the CA that generated
> the certificate, I can use this extension to (hopefully) limit my
> liability in case of certificate misuse.
>
> Dave Simonetti
>
> [email-masked] wrote:
> >
> > The Certificate Policies extension is not the only factor in validating
> > a certificate policie, two other factors are the path validation algorithm
> > and the policy constraints extention.
> >
> > According to the path validation algorithm, an application that has no
> > explicit policy requirements has almost nothing to do with the Certificate
> > Policies extension, unless there is a policy constraints extention.
> > (almost nothing because it should show the user the "User notice" policy,
> > but this is a should and not a must).
> >
> > In view of this the offending sentence:
> >
> > "(Applications without specific policy requirements are not required to list
> > acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> > POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> >
> > adds no information and is only a clarification of the path validation
> > algorithm.
> >
> > If a CA want to stop that behavour it can use a critical policy constraints
> > etension that contains the requireExplicitPolicy field.
> >
> > Moshe Litvin
> >
> > > Bob--
> > >  Being relatively new to this mailing list, I did not notice the sentence you
> > > quoted. Knowing the authors, I suspect they have a good reason for putting that
> > > line in there and I would like to hear it. However, I can't imagine that the
> > > reason is good enough to make up for the trouble it may cause! The lawyers at
> > > the clients I work with (large financial institutions, insurance companies,
> > > telecomms, etc.) would "have a cow" if they realized that their software may be
> > > "PKIX conformant" and still not support a critical extension that they are
> > > relying on to possibly limit their liability. What is the point of marking
> > > anything critical with that sentence in the document? Before I rave anymore,
> > > could one of the authors restate their reasoning for including that sentence?
> > > I'd like to hear the other side of the coin. Thanks.
> > >
> > > Dave Oshman
> > > Price Waterhouse LLP
> > > Electronic Commerce/Internet Security
> > >
> > >
> > >
> > >
> > >
> > > [email-masked] on 12/05/97 12:41:54 PM
> > > To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
> > > cc: [email-masked] @ Internet, [email-masked] @ Internet
> > > Subject: Critical extensions and Policy OIDs
> > >
> > > Dave,
> > >
> > > So that we are all on the same page, let me refer you to the Oct 14th draft
> > > of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> > >
> > > "Applications with specific policy requirements are expected to have a list
> > > of those policies which they will accept and to compare the policy OIDs in
> > > the certificate in that list. If this extension is critical, the path
> > > validation software must be able to interpret this extension, or must reject
> > > the certificate."
> > >
> > > So far so good, although the text tends to put too much emphasis on
> > > applications deciding on their own what policy requirements they require and
> > > will enforce, whereas I believe that such decisions will more often be made
> > > by the MIS department and conveyed in the root-level certificate (issued by
> > > the MIS department) which cross-certifies particular CAs and imposes any
> > > necessary policy constraints on subsequent certificates.
> > >
> > > Where the train jumps the track is in the following sentence of the
> > > paragraph:
> > >
> > > "(Applications without specific policy requirements are not required to list
> > > acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> > > POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> > >
> > > This takes the issue well beyond that of a rogue application.  It says that
> > > a PKIX standards-conforming application can ignore an attribute bearing a
> > > Critical marking with impunity -- it doesn't have to even notify the user
> > > that it saw something that it doesn't understand.
> > >
> > > I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
> > > help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
> > > Solo) to delete this sentence.
> > >
> > > I think that we are in agreement that if someone goes out and buys an
> > > application that is non-conforming, we aren't going to sic the Internet
> > > police on him. I'm not trying to prevent anyone from building rogue
> > > applications. However, if someone knowingly uses an application that does
> > > not conform to the standard, or does not implement the Critical attribute
> > > correctly, he has to accept the consequences of his actions, and both the CA
> > > and the subscriber should be relieved of any liability that might result
> > > from the relying party accepting some transaction that they should have
> > > rejected, based on the policy OID and the Critical flag.
> > >
> > > But if the standard itself says that such markings can be ignored with
> > > impunity and still be considered as conforming to the standard, then the CA
> > > and/or the subscriber haven't a leg to stand on, for they have no way to
> > > ensure that effective legal notice is provided to any potential relying
> > > party.
> > >
> > > This sentence must be removed or clarified considerably before the standard
> > > can be accepted, IMHO, for the concept of a Critical attribute is
> > > fundamental to the entire concept of legal notice which the certificate is
> > > supposed to provide.
> > >
> > > Bob
> > >
> > > Robert R. Jueneman
> > > Security Architect
> > > Novell, Inc.
> > > Network Services Division
> > > 122 East 1700 South
> > > Provo, UT 84604
> > > 801/861-7387
> > > [email-masked]
> > >
> > > "If you are trying to get to the moon, climbing a tree,
> > > although a step in the right direction, will not prove
> > > to be very helpful."
> > >
> > > "The most dangerous strategy is to cross the chasm in two leaps."
> > >
> > >
> > > >>> <[email-masked]> 12/04 2:29 PM >>>
> > > Bob, Mike,
> > >  I agree completely with the importance of obeying critical extensions. But
> > > I
> > > also believe that there will be "rogue applications" that may or may not
> > > handle
> > > these extensions properly dependent on the specific application. For
> > > example,
> > > if I have a certificate whose policy is explicitly for signing user
> > > certificates, someone may develop an application that allows me to use that
> > > certificate for applying for a credit card exclusively for CAs. The "relying
> > >
> > > party" in this case accepts the risk in using that certificate despite the
> > > policy under which it was issued. If used improperly by these rogue
> > > applications, Mike is correct in saying that all CA (or other) liability is
> > > relieved. Hopefully, the relying party would have a difficult fight in court
> > > if
> > > they wanted to blame the CA who issued that certificate. The point is that
> > > we
> > > can only write the specifications, we cannot enforce them.
> > >
> > > Cheers,
> > > Dave Oshman
> > >
> > > Price Waterhouse LLP
> > > Electronic Commerce/Internet Practice
> > > >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> > > >From:    Mike Smith <[email-masked]>
> > > >Subject: Re: digitalSignature vs. nonRepudiation
> > > >As usual, Bob, I find myself agreeing with your statements.
> > > >
> > > >A certificate is issued under a certain set of authority policies.  If
> > > someone
> > > wishes >to rely on a certificate issued under those policies, then the
> > > software
> > > they use must >be able to process all of the critical extensions established
> > >
> > > under that policy or >not honor the certificate.
> > > >
> > > >If someone does accept a certificate or signature issued with critical
> > > extensions >that are ignored or interpreted other than the intent of the
> > > issuing CA, then, it is >my belief, the reliant party (and, possibly the
> > > entity
> > > that modified the code to >accept or ignore the critical extensions) has
> > > just
>
> > > relieved the CA of any and all >liability regarding that critical extension
> > > and, quite possibly, the whole >certificate's issued purpose.
> > > >
> > > >Michael
> > > >
> > > >>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
> > > >Sharon and David,
> > > >
> > > >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> > > >as a result of my confusion and exasperation in trying to sort though all
> > > of
> > > >these different issues.  But if we can't agree on some relatively simple
> > > >meaning, I submit that using the fields will actually be WORSE than
> > > >deprecating them, for one person will think that they mean one thing, and
> > > >another person will interpret them differently.
> > > >
> > > >What good does it do to mark an attribute as critical, if the semantics are
> > > >as undefined or ambiguous as these are?
> > > >
> > > >And to bring up a somewhat different ubject that I mentioned before, but
> > > >never got closure on, I think that it is completely UNACCEPTABLE to say
> > > that
> > > >if some particular application does not have, understand, or chose to
> > > >implement a security policy, it should be free to simply ignore the
> > > critical
> > > >marking on a Policy OID constraint. This simply turns the definition of
> > > >critical on its head.  The critical usage is provided primarily to protect
> > > >the CA and/or the subject of the certificate from unreasonable reliance on
> > > >the certificate, and to provide a means for IT administrators to centrally
> > > >control what kinds of policies are to be enforced.
> > > >
> > > >Bob
> > >
> > >
>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>

Date:         Sat, 13 Dec 1997 23:33:01 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] draft meeting minutes
Comments: To: [email-masked]
To: [email-masked]
Status:

Steve:

Great minutes, as usual!  I have just a couple of suggested mods:

At 09:09 AM 12/11/97 -0500, Stephen Kent wrote:
>PKIX WG Meeting Minutes (12/8+10/97)
>
>Approximately xxx attendees participated in the two PKIX WG session at

xxx = 360

>Certificate Request Syntax (PKCS7/10 focus)
>
>A proposal was made to move work on this to S/MIME WG, and Schiller
>and Housley (S/MIME WG chair) have no objections.  However, this work
>is not S/MIME-specific and several PKIX and S/MIME WG members believe
>that this work item should remain in PKIX, as it is more general.  The
>fundamental question is whether CRS is a completely separate protocol,
>focused on S/MIME, or if it is a profile for Part 3.  Not resolved,

Replace "Not resolved, but straw poll..." by:  "This was subsequently
resolved [See later item.]  A straw poll..."

>but straw poll of attendees showed a plurality of attendees in favor of
>keeping the work item in this WG, and only a single vote in favor of
>moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred
>with this and did not recommend adoption of CRS within that WG.

Add:  "...assuming PKIX would reconcile CRS/CMP differences and include a
specification for securely transporting commonly-agreed certificate
management messages over CMS (i.e., son-of-PKCS#7)."

>
>At the second PKIX WG meeting, a compromise approach was announced,
>reconciling CRS and CMP...

Following is a proposed revision of this entire paragraph:

At the second PKIX WG meeting, a compromise approach was announced, aimed
at reconciling differences between CRS and CMP.  In essence, a common
certificate request message syntax has been agreed, and CMP will adopt this
syntax as the certificate request payload type within that protocol
(replacing the current certificate request payload format).  CRS will be
revised to also reference that syntax.  This new, harmonized certificate
request format will appear as a separate RFC.  It is not anticipated that
this will delay the progression of CMP to proposed standard, since it is
simply a protocol syntax change for alignment purposes plus a splitting of
one document into two in the interests of facilitating future developments.
 CRS will continue to progress, specifying the mapping of certificate
management messages onto CMS and providing the vehicle for developing
common formats for other certificate management messages (i.e., messages
other than certificate request)."

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sat, 13 Dec 1997 14:59:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "CN=David Hemsath/OU=Endicott/O=IBM@IBMLMS01"@US.IBM.COM
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

                   Status Distribution December 13, 1997 09:06:12

The message regarding "Re: [IETF-PKIX] Critical extensions and Policy OIDs"
sent on December 13, 1997 09:06:12 was sent by

Status Recipient
          Type                To
          Native Name         [email-masked]
          Foreign Native Name [email-masked]\n\n\nINTERNET

Recipients

Status Reporters
          Type                From
          Name Domain         NOTES
          Native Name         CN=David Hemsath/OU=Endicott/O=IBM@IBMLMS01
          Foreign Native Name CN=David Hemsath/OU=Endicott/O=IBM\nIBMLMS01\n\n
          Organization        IBM
          Org Unit 1          Endicott
          Last Name           Hemsath
          First Name          David

Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Error delivering to D26NM061/26/M/IBM mail/hemsath; Cannot
write or create file (file or disk is read-only)

Date:         Fri, 12 Dec 1997 17:06:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

Bill Burr said:
> Note that no input to the cert. path processing procedure includes any
> rules or way to understand what is implied by any policy.  Some
application
> simply sets, possibly under user control, the initial-policy-set of
> policies that it will accept.  If we assume a general purpose certificate
> path processing module, hopefully serving all the different applications
> that may use certificates, itâs hard to envision how any automatic
> enforcement of  critical policies can be accomplished in the cert. path
> processing procedure.  I canât believe that certificate path processing
> module can reasonably check for anything except the initial-policy-set,
if
> it sees a certificate policy field that is flagged critical.  I for one
at
> least, certainly want to divorce the certificate path processing from any
> obligation to understand the application, or we wind up with a different
> cert. path processing module for every application, Iâm afraid.  And
X.509,
> it seems to me is not really, nor should it be, an application standard.
>

Farther down in the description of path processing, X.509 states that, when
a critical policy extension is encountered, that set of policies is
intersected
with the current value of "authority-constrained-policy-set", which is
initialized
to "any-policy".  This is checked vs. what the user input as
"initial-policy-set"
to make sure their intersection is not empty. The "authority-constrained-
policy-set" is returned from the path-processing algorithm.  It seems to me
that this will cause the behavior we (or at least I) want:  only critical
policies are allowed to make it through path processing, and be returned to
the caller, even if
the user input "any-policy" initially.  I suspect that what should be
returned
is the intersection of the authority-constrained set and the
user-constrained
(initial) set, though; but that may be a flaw in X.509.

Regards,
Rich

Date:         Fri, 12 Dec 1997 16:20:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
To: [email-masked]
Status:

At 04:38 PM 12/11/97 -0700, you wrote:
>At this point I confess to being somewhat bemused about the overall purpose
>of the policy OID.
>
>I think that part of the problem may be that we don't seem to have a clear
>understanding of the SUBJECT of a policy OID.  To whom does it apply - the
>issuer of the certificate, or the subject of the certificate?
>
>In other words, is the policy OID a shorthand form of a more or less legally
>binding REPRESENTATION made by the subject of a certificate to the issuer,
>or is the policy OID merely describing the behavior of the CA itself?
>
>My view is that the policy OID serves to protect up to three parties ø the
>CA, the subscriber, and the relying party.  It provides protection to the
>subscriber and/or the CA by providing appropriate legal notice or caveats
>and conditions to the relying  party, and it provides protection to the
>relying party (especially on a closed user group contractual situation) by
>at a minimum reminding the subscriber/signer of her obligations, and may
>also enforce those obligations in the application.
>
>For example, in some of the stuff I am presently working on (representing
>the key quality and process quality of a digital signature, among other
>things), it is necessary to know what properties the SIGNER is willing to
>guarantee, by some mechanism that is TBD ø either contractual or by
>technical enforcement means.
>
>Since there is no convenient way to encode these attributes in the current
>definition of the digital signature itself, I am using policy OIDs to
>indicate a representation or a commitment made by the subject/signer to the
>CA. Likewise, the next higher certificate would include a
>representation/commitment made by the subordinate CA to the higher level CA.
>
>So the question is, to whom does the policy OID in the lowest level
>certificate apply, in general?  And what, if anything, would a policy
>constraint attribute mean in the lowest level certificate? Does it even make
>in sense to turn on the policy constraint for the lowest level certificate?
>Whose behavior is supposedly being constrained?
>
>Alternatively, what is to be gained by having the ability to turn on the
>critical flag for an attribute, if the validating program used by the
>relying party is free to ignore it?
>
>If we only look at the problem from the perspective of the relying party,
>then do we lose the ability to apply any controls on the signing
>application?
>
>Ideally, I'd like the signing application to check the policy OID of the
>certificate that is to be used to validate the signature, and to either
>modify its behavior to conform to the policy, or to refuse to sign if it
>doesn't understand the policy or can't comply, assuming that the attribute
>is marked critical.
>
>Let me propose a strawman interpretation, just to have something for
>everyone to shoot at. This of course applies only to those applications
>which purport to be PKIX compliant.
>
>With respect to the originator:
>
>1.  If a policy OID constraint is included in a certificate that the
>end-user/signer has selected to be used to validate the signature, the
>signing application must be (pre-)configured as implementing, supporting,
>and/or conforming to that policy in order to sign.
>
>2.  If a policy OID is included and marked critical in a certificate which
>the signer has selected to be used to validate the signature, but the policy
>OID constraint is NOT imposed, then the signing application must either be
>configured as implementing, supporting, and/or conforming to that policy;
>OR, the text of any notices contained as policy OID parameters shall be
>presented to the human user for manual approval prior to signing.
>
>With respect to the relying party:
>
>3.  If a policy OID is included in a certificate that was not required by a
>policy OID constraint imposed by a higher level certificate, AND if that
>policy OID is marked critical, then the signature validation
>application/mechanism must either be (pre-)configured to require and/or be
>cognizant of that policy; OR, the text of any notices contained as policy
>OID parameters shall be made available to the human user during the process
>of validating the digital signature.
>
>Comments?
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.,
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
X.509 clause 12.2.2.6 contains the following statement about the
certificate policies field:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules
implied by one of the indicated certificate policies. The rules of a
particular policy may require the certificate-using system to process the
qualifier value in a particular way."

But later on, in clause 12.4.3, weâre told:

"The inputs to the certification path processing procedure are:
a)      a set of certificates comprising a certification path;

b)      a trusted public key value or key identifier (if the key is stored
internally to the certification path processing module), for use in
verifying the first certificate in the certification path;

c)      an initial-policy-set comprising one or more certificate policy
identifiers, indicating that any one of these policies would be acceptable
to the certificate user for the purposes of certification path processing;
this input can also take the special value any-policy;

d)      an initial-explicit-policy indicator value, which indicates if an
acceptable policy identifier needs to explicitly appear in the certificate
policies extension field of all certificates in the path;

e)      an initial-policy-mapping-inhibit indicator value, which indicates if
policy mapping is forbidden in the certification path; and

f)      the current date/time (if not available internally to the certification
path processing module)."

Note that no input to the cert. path processing procedure includes any
rules or way to understand what is implied by any policy.  Some application
simply sets, possibly under user control, the initial-policy-set of
policies that it will accept.  If we assume a general purpose certificate
path processing module, hopefully serving all the different applications
that may use certificates, itâs hard to envision how any automatic
enforcement of  critical policies can be accomplished in the cert. path
processing procedure.  I canât believe that certificate path processing
module can reasonably check for anything except the initial-policy-set, if
it sees a certificate policy field that is flagged critical.  I for one at
least, certainly want to divorce the certificate path processing from any
obligation to understand the application, or we wind up with a different
cert. path processing module for every application, Iâm afraid.  And X.509,
it seems to me is not really, nor should it be, an application standard.

So, it seems to me that weâre left with a rather unenforceable requirement
against applications or users, that they shall not include a policy in the
initial-policy-set unless the application is consistent with the policy.
But does it make any sense to talk about x.509 or PKIX conformance for
applications or users?  Not to me.  Law, business practice or contractual
relationsips may constrain my behavior as an end user, but never X.509 or
PKIX.

What if the special value "any-policy" is set?  We might want to prevent
automatically accepting a certificate with a critical certificate policy,
if "any-policy" is set, but not the specific policy OID.  But I canât think
of a more rigorous provision that seems practical or desirable.

This leaves folks who want to use the certificate policies field to enforce
something on the relying party pretty well left out.  Too bad.  I think
that we just have to accept that a certificate policy, even a critical
certificate policy, is a representation or a disclaimer made to a relying
party, which the relying party or application may or may not choose to
honor or accept, but the thatâs outside the scope of what we can expect to
enforce through X.509 or PKIX.
Regards,

Bill Burr

Date:         Fri, 12 Dec 1997 08:55:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and Cross-certification
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

Tim:

Well thought out reply to Mack.  I think the point you make about previously reported assumptions of "currency" is well made:  a responder may have "current" status on its own domain certificates in advance of the next CRL distribution cycle, but may have "latest" status based on published CRLs from its contracted CA domains.  In addition, some responders may only supply "latest" and no "current" status.

Michael

>>> Tim Moses <[email-masked]> 12/12/97 07:07AM >>>
Mack - Thanks for your response.  I have a couple of comments that you
may enjoy considering.

I have some acquaintance with the use of OCSP in the NACHA demonstrator.
 However, it isn't clear to me whether this use is typical of those that
the author intends to address with his protocol.  I think, perhaps, that
(depending upon the usage pattern) it will be common for each OCSP
responder to serve a relatively small number (maybe in the low
thousands) of relying parties.  Each of these responders will (in turn)
obtain its revocation status information from the issuing CA, using CRLs
or cached OCSP responses.  A responder that directly serves the relying
party community may issue "live" responses, but the latency of
disemmination of revocation information will be dominated by the latency
of the mechanism by which the issuing CA serves the responders.   Used
in this way, OCSP does not offer better latency performance than CRLs.

You suggest that OCSP offers a better "cultural fit" to the banking
world than CRLs do.  Is this conclusion based upon the fact that in the
military world relying parties have an "employee" relationship with
their authority, whereas in the banking world relying parties have a
"customer" relationship with their authority?  As a result, relying
parties in the banking world will be less tolerant of a revocation
status service which is inappropriately packaged.  So, the service
should give a simple, unequivocal, YES/NO reponse to the query: "is this
certificate still valid?"

At first glance, there appears to be a lot of merit to this point of
view.  But, on closer examination, it seems to rest on a few
assumptions.  First of all, it assumes that the interface to the service
must be a wire protocol, when in fact, it is equally appropriate for the
service interface to be a client-side API.  In the latter case, the
information that flows in the wire protocol, to allow the API to make
its determination, is invisible to the service consumer, and therefore,
it does not have to be a simple boolean indication.

Secondly, the OCSP protocol does not give an unqualified YES/NO
response.  It "says" YES (or NO), but before you can trust this answer
you must use this key identifier to find a public key, check that it is
a key for the right algorithm, check that its usage is suitable for
verifying OCSP responses, check that it is valid, check that it has not
been revoked, check the signature on the response and check that the
timestamp on the response post-dates the time of the transaction.  How
can we determine that this degree of "qualification" is absolutely
acceptable, and a different degree of qualification is absolutely
unacceptable?  It seems arbitrary.  Or did I misunderstand your point.

Looking forward to your reaction. Best regards.  Tim.

>----------
>From:  Mack Hicks[SMTP:[email-masked]]
>Sent:  Tuesday, December 09, 1997 12:58 PM
>To:    Tim Moses
>Cc:    [email-masked]
>Subject:       OCSP and Cross-certification
>
>
>Tim,
>
>From the last announcement by Entrust, IBM, and others, there is a
>perception that the cross-certification of CAs will handle the problem
>of trust generally.  This means that trees within each organization
>will trust trees within other organizations.
>
>Within the Banking industry, discussions uniformly have rejected this
>idea.  We have learned from long experience - with private networks,
>credit cards, funds transfer networks, and others - that the best
>way to manage the risk of a transaction, a connection, or a communication
>is to have on-line status checking.  This is also true with
>the checking of the status of digital certificates.
>
>The volume questions are interesting.  Bank of America processes about
>10% of the US paper checks every night -- over 22,000,000 pieces of paper
>at high water mark.  I think we can handle some multi-million certificate
>status requests.
>
>But we do not do things for free or manage risk of communication without
>authentication.  Therefore the on-line status check is for our customers.
>
>The NACHA Internet Council pilot of CA interoperability will demonstrate
>how Banks will trust each others certificates.
>
>We are using CRLs between banks--and I think CRLs have a place in high
>volume relationships between organizations. This risk of outdated CRLs
>can be managed by agreement and rules that NACHA would set.
>
>Tim wrote:
>
>>>1. Approximately how many OCSP responders are required to serve a
>>>community of one billion relying parties and subscribers?
>>>
>I expect that certificate holders would go to their agents.
>Therefore, the magnitude of OSCPs will be the magnitude of
>agents (essentially CAs or their repositories).
>
>>2. How do the relying parties come to trust the verification keys of the
>>>OCSP responders?
>>>
>By contracted relationship, since they are using the OCSP to THEIR
>agent - and the agent now deals with the trust to other repositories.
>Admittedly, this does make the same problem at the agent's level,
>but this is a less difficult problem since these agents are in this
>business.  They will have contracts and associations.
>
>>>3. How do the OCSP responders obtain revocation information from the
>>>single CA?
>>>
>Revocation information will be by OCSP at low volumes from agent to
>agent.  High volume agents will contract on risk distribution and
>may use CRL mechanisms.
>
>I do not know of a CA will offer its CRLs to all comers without
>authentication. (Talk about denial of service opportunities.)
>
>>>4. How current will the revocation information be when it is presented
>>>to the relying parties?
>>>
>If it is OCSP, it will be as current as represented by the agency.
>Between agencies, association rules and contracts will provide
>this assurance.
>
>
>For all the talk of CRLs, I would like to point out that CRLs
>make really good sense in a military application where the
>commanding officer (relying party) needs to make a decision
>based on available information (certificate, roots, last CRL).
>In a commercial context, we have left this model of behavior
>behind with the advent of telephony.
>
>
>
>Therefore, I state my earlier discussion:
>
>From PKIX 3, I expect that a PKIX compliant CA can
>
>a) Provide a place for CRL or OCSP
>b) Provide a reponse of
>   "I don't know you - go away"
>   for unauthenticated requests.
>c) The relying party should then not automatically trust
>   the certificate since there is no assurance that the
>   certificate is still valid.
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Date:         Fri, 12 Dec 1997 09:07:58 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

Bob:

Isn't the policy OID referring to the CA's disclosure of practices under which they will operate AND under which they assume responsibility for the subscriber's use of issued certs?  Don't some act as disclosure forms as in bank lending, wherein they govern actions of the subscribers?

Michael

>>> Bob Jueneman <[email-masked]> 12/11/97 04:38PM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found

*********************************************************

Date:         Fri, 12 Dec 1997 09:07:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and Cross-certification
Comments: To: Mack Hicks <[email-masked]>
To: [email-masked]
Status:

Mack - Thanks for your response.  I have a couple of comments that you
may enjoy considering.

I have some acquaintance with the use of OCSP in the NACHA demonstrator.
 However, it isn't clear to me whether this use is typical of those that
the author intends to address with his protocol.  I think, perhaps, that
(depending upon the usage pattern) it will be common for each OCSP
responder to serve a relatively small number (maybe in the low
thousands) of relying parties.  Each of these responders will (in turn)
obtain its revocation status information from the issuing CA, using CRLs
or cached OCSP responses.  A responder that directly serves the relying
party community may issue "live" responses, but the latency of
disemmination of revocation information will be dominated by the latency
of the mechanism by which the issuing CA serves the responders.   Used
in this way, OCSP does not offer better latency performance than CRLs.

You suggest that OCSP offers a better "cultural fit" to the banking
world than CRLs do.  Is this conclusion based upon the fact that in the
military world relying parties have an "employee" relationship with
their authority, whereas in the banking world relying parties have a
"customer" relationship with their authority?  As a result, relying
parties in the banking world will be less tolerant of a revocation
status service which is inappropriately packaged.  So, the service
should give a simple, unequivocal, YES/NO reponse to the query: "is this
certificate still valid?"

At first glance, there appears to be a lot of merit to this point of
view.  But, on closer examination, it seems to rest on a few
assumptions.  First of all, it assumes that the interface to the service
must be a wire protocol, when in fact, it is equally appropriate for the
service interface to be a client-side API.  In the latter case, the
information that flows in the wire protocol, to allow the API to make
its determination, is invisible to the service consumer, and therefore,
it does not have to be a simple boolean indication.

Secondly, the OCSP protocol does not give an unqualified YES/NO
response.  It "says" YES (or NO), but before you can trust this answer
you must use this key identifier to find a public key, check that it is
a key for the right algorithm, check that its usage is suitable for
verifying OCSP responses, check that it is valid, check that it has not
been revoked, check the signature on the response and check that the
timestamp on the response post-dates the time of the transaction.  How
can we determine that this degree of "qualification" is absolutely
acceptable, and a different degree of qualification is absolutely
unacceptable?  It seems arbitrary.  Or did I misunderstand your point.

Looking forward to your reaction. Best regards.  Tim.

>----------
>From:  Mack Hicks[SMTP:[email-masked]]
>Sent:  Tuesday, December 09, 1997 12:58 PM
>To:    Tim Moses
>Cc:    [email-masked]
>Subject:       OCSP and Cross-certification
>
>
>Tim,
>
>From the last announcement by Entrust, IBM, and others, there is a
>perception that the cross-certification of CAs will handle the problem
>of trust generally.  This means that trees within each organization
>will trust trees within other organizations.
>
>Within the Banking industry, discussions uniformly have rejected this
>idea.  We have learned from long experience - with private networks,
>credit cards, funds transfer networks, and others - that the best
>way to manage the risk of a transaction, a connection, or a communication
>is to have on-line status checking.  This is also true with
>the checking of the status of digital certificates.
>
>The volume questions are interesting.  Bank of America processes about
>10% of the US paper checks every night -- over 22,000,000 pieces of paper
>at high water mark.  I think we can handle some multi-million certificate
>status requests.
>
>But we do not do things for free or manage risk of communication without
>authentication.  Therefore the on-line status check is for our customers.
>
>The NACHA Internet Council pilot of CA interoperability will demonstrate
>how Banks will trust each others certificates.
>
>We are using CRLs between banks--and I think CRLs have a place in high
>volume relationships between organizations. This risk of outdated CRLs
>can be managed by agreement and rules that NACHA would set.
>
>Tim wrote:
>
>>>1. Approximately how many OCSP responders are required to serve a
>>>community of one billion relying parties and subscribers?
>>>
>I expect that certificate holders would go to their agents.
>Therefore, the magnitude of OSCPs will be the magnitude of
>agents (essentially CAs or their repositories).
>
>>2. How do the relying parties come to trust the verification keys of the
>>>OCSP responders?
>>>
>By contracted relationship, since they are using the OCSP to THEIR
>agent - and the agent now deals with the trust to other repositories.
>Admittedly, this does make the same problem at the agent's level,
>but this is a less difficult problem since these agents are in this
>business.  They will have contracts and associations.
>
>>>3. How do the OCSP responders obtain revocation information from the
>>>single CA?
>>>
>Revocation information will be by OCSP at low volumes from agent to
>agent.  High volume agents will contract on risk distribution and
>may use CRL mechanisms.
>
>I do not know of a CA will offer its CRLs to all comers without
>authentication. (Talk about denial of service opportunities.)
>
>>>4. How current will the revocation information be when it is presented
>>>to the relying parties?
>>>
>If it is OCSP, it will be as current as represented by the agency.
>Between agencies, association rules and contracts will provide
>this assurance.
>
>
>For all the talk of CRLs, I would like to point out that CRLs
>make really good sense in a military application where the
>commanding officer (relying party) needs to make a decision
>based on available information (certificate, roots, last CRL).
>In a commercial context, we have left this model of behavior
>behind with the advent of telephony.
>
>
>
>Therefore, I state my earlier discussion:
>
>From PKIX 3, I expect that a PKIX compliant CA can
>
>a) Provide a place for CRL or OCSP
>b) Provide a reponse of
>   "I don't know you - go away"
>   for unauthenticated requests.
>c) The relying party should then not automatically trust
>   the certificate since there is no assurance that the
>   certificate is still valid.
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Old-To: [email-masked]
Date:         Wed, 10 Dec 1997 09:49:07 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Thane E. Plambeck" <[email-masked]>
Subject:      [IETF-PKIX] Announcing the cert-talk X.509 mailing list
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]
Status:

+----------------------------------------------------------------------+
This message was addressed to:  [email-masked]
+----------------------------------------------------------------------+

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

-------------------------------------------------------------------------
This message was sent by a majordomo-based automatic list manager.
Subscriptions to and archives of this list are available to any person
or organization.  For further information send a mail message to
[email-masked]' with 'help' (no quotations)
contained in the body of your message.

Date:         Thu, 11 Dec 1997 16:38:23 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical extensions and Policy OIDs
Comments: To: [email-masked], [email-masked]
To: [email-masked]
Status:

At this point I confess to being somewhat bemused about the overall purpose
of the policy OID.

I think that part of the problem may be that we don't seem to have a clear
understanding of the SUBJECT of a policy OID.  To whom does it apply - the
issuer of the certificate, or the subject of the certificate?

In other words, is the policy OID a shorthand form of a more or less legally
binding REPRESENTATION made by the subject of a certificate to the issuer,
or is the policy OID merely describing the behavior of the CA itself?

My view is that the policy OID serves to protect up to three parties ¯ the
CA, the subscriber, and the relying party.  It provides protection to the
subscriber and/or the CA by providing appropriate legal notice or caveats
and conditions to the relying  party, and it provides protection to the
relying party (especially on a closed user group contractual situation) by
at a minimum reminding the subscriber/signer of her obligations, and may
also enforce those obligations in the application.

For example, in some of the stuff I am presently working on (representing
the key quality and process quality of a digital signature, among other
things), it is necessary to know what properties the SIGNER is willing to
guarantee, by some mechanism that is TBD ¯ either contractual or by
technical enforcement means.

Since there is no convenient way to encode these attributes in the current
definition of the digital signature itself, I am using policy OIDs to
indicate a representation or a commitment made by the subject/signer to the
CA. Likewise, the next higher certificate would include a
representation/commitment made by the subordinate CA to the higher level CA.

So the question is, to whom does the policy OID in the lowest level
certificate apply, in general?  And what, if anything, would a policy
constraint attribute mean in the lowest level certificate? Does it even make
in sense to turn on the policy constraint for the lowest level certificate?
Whose behavior is supposedly being constrained?

Alternatively, what is to be gained by having the ability to turn on the
critical flag for an attribute, if the validating program used by the
relying party is free to ignore it?

If we only look at the problem from the perspective of the relying party,
then do we lose the ability to apply any controls on the signing
application?

Ideally, I'd like the signing application to check the policy OID of the
certificate that is to be used to validate the signature, and to either
modify its behavior to conform to the policy, or to refuse to sign if it
doesn't understand the policy or can't comply, assuming that the attribute
is marked critical.

Let me propose a strawman interpretation, just to have something for
everyone to shoot at. This of course applies only to those applications
which purport to be PKIX compliant.

With respect to the originator:

1.  If a policy OID constraint is included in a certificate that the
end-user/signer has selected to be used to validate the signature, the
signing application must be (pre-)configured as implementing, supporting,
and/or conforming to that policy in order to sign.

2.  If a policy OID is included and marked critical in a certificate which
the signer has selected to be used to validate the signature, but the policy
OID constraint is NOT imposed, then the signing application must either be
configured as implementing, supporting, and/or conforming to that policy;
OR, the text of any notices contained as policy OID parameters shall be
presented to the human user for manual approval prior to signing.

With respect to the relying party:

3.  If a policy OID is included in a certificate that was not required by a
policy OID constraint imposed by a higher level certificate, AND if that
policy OID is marked critical, then the signature validation
application/mechanism must either be (pre-)configured to require and/or be
cognizant of that policy; OR, the text of any notices contained as policy
OID parameters shall be made available to the human user during the process
of validating the digital signature.

Comments?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.,
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

>>> "Simonetti David" <[email-masked]> 12/11/97 08:26:46 >>>
Moshe,

I respectively disagree with your analysis.  The paranthetical of PKIX-1
is not a reference to cert path validation, but rather is a reference to
how the application *uses* the certificate after validation (please
let's not debate the merits applying requirements to the application).
This is described in X.509 by the quotation I provided in my previous
message.

As an example of a use of a critical certificate policies extension,
let's say that I'm a CA generating and signing certificates for my
private community.  By signing the certificate I am vouching for the
identity of the certificate subject.  I'm concerned about by my
liability if an individual decides to misuse her/his certificate outside
of my community, so within my certificate policy is a statement that the
certificate may never be used for any purpose outside of the community.
I then include the OID of that policy in the certificate policies
extension of every certificate that I generate, and I indicate the
extension as critical.

X.509 states that the certifcate with this extension as critical "shall
only be used for the purpose...implied by one of the indicated
certificate policies."  As a result, an application that claims
X.509-compliance cannot use this certificate for a purpose other than
that stated in the registered certificate policy.  It's not entirely
clear to me yet how an application can truely restrict the use of a
certificate in this manner, but in any case, as the CA that generated
the certificate, I can use this extension to (hopefully) limit my
liability in case of certificate misuse.

Dave Simonetti

[email-masked] wrote:
>
> The Certificate Policies extension is not the only factor in validating
> a certificate policie, two other factors are the path validation algorithm
> and the policy constraints extention.
>
> According to the path validation algorithm, an application that has no
> explicit policy requirements has almost nothing to do with the Certificate
> Policies extension, unless there is a policy constraints extention.
> (almost nothing because it should show the user the "User notice" policy,
> but this is a should and not a must).
>
> In view of this the offending sentence:
>
> "(Applications without specific policy requirements are not required to
list
> acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
>
> adds no information and is only a clarification of the path validation
> algorithm.
>
> If a CA want to stop that behavour it can use a critical policy
constraints
> etension that contains the requireExplicitPolicy field.
>
> Moshe Litvin
>
> > Bob--
> >  Being relatively new to this mailing list, I did not notice the
sentence you
> > quoted. Knowing the authors, I suspect they have a good reason for
putting that
> > line in there and I would like to hear it. However, I can't imagine that
the
> > reason is good enough to make up for the trouble it may cause! The
lawyers at
> > the clients I work with (large financial institutions, insurance
companies,
> > telecomms, etc.) would "have a cow" if they realized that their software
may be
> > "PKIX conformant" and still not support a critical extension that they
are
> > relying on to possibly limit their liability. What is the point of
marking
> > anything critical with that sentence in the document? Before I rave
anymore,
> > could one of the authors restate their reasoning for including that
sentence?
> > I'd like to hear the other side of the coin. Thanks.
> >
> > Dave Oshman
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Security
> >
> >
> >
> >
> >
> > [email-masked] on 12/05/97 12:41:54 PM
> > To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
> > cc: [email-masked] @ Internet, [email-masked] @ Internet
> > Subject: Critical extensions and Policy OIDs
> >
> > Dave,
> >
> > So that we are all on the same page, let me refer you to the Oct 14th
draft
> > of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> >
> > "Applications with specific policy requirements are expected to have a
list
> > of those policies which they will accept and to compare the policy OIDs
in
> > the certificate in that list. If this extension is critical, the path
> > validation software must be able to interpret this extension, or must
reject
> > the certificate."
> >
> > So far so good, although the text tends to put too much emphasis on
> > applications deciding on their own what policy requirements they require
and
> > will enforce, whereas I believe that such decisions will more often be
made
> > by the MIS department and conveyed in the root-level certificate (issued
by
> > the MIS department) which cross-certifies particular CAs and imposes any
> > necessary policy constraints on subsequent certificates.
> >
> > Where the train jumps the track is in the following sentence of the
> > paragraph:
> >
> > "(Applications without specific policy requirements are not required to
list
> > acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> > POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> >
> > This takes the issue well beyond that of a rogue application.  It says
that
> > a PKIX standards-conforming application can ignore an attribute bearing
a
> > Critical marking with impunity -- it doesn't have to even notify the
user
> > that it saw something that it doesn't understand.
> >
> > I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate
your
> > help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk,
and
> > Solo) to delete this sentence.
> >
> > I think that we are in agreement that if someone goes out and buys an
> > application that is non-conforming, we aren't going to sic the Internet
> > police on him. I'm not trying to prevent anyone from building rogue
> > applications. However, if someone knowingly uses an application that
does
> > not conform to the standard, or does not implement the Critical
attribute
> > correctly, he has to accept the consequences of his actions, and both
the CA
> > and the subscriber should be relieved of any liability that might result
> > from the relying party accepting some transaction that they should have
> > rejected, based on the policy OID and the Critical flag.
> >
> > But if the standard itself says that such markings can be ignored with
> > impunity and still be considered as conforming to the standard, then the
CA
> > and/or the subscriber haven't a leg to stand on, for they have no way to
> > ensure that effective legal notice is provided to any potential relying
> > party.
> >
> > This sentence must be removed or clarified considerably before the
standard
> > can be accepted, IMHO, for the concept of a Critical attribute is
> > fundamental to the entire concept of legal notice which the certificate
is
> > supposed to provide.
> >
> > Bob
> >
> > Robert R. Jueneman
> > Security Architect
> > Novell, Inc.
> > Network Services Division
> > 122 East 1700 South
> > Provo, UT 84604
> > 801/861-7387
> > [email-masked]
> >
> > "If you are trying to get to the moon, climbing a tree,
> > although a step in the right direction, will not prove
> > to be very helpful."
> >
> > "The most dangerous strategy is to cross the chasm in two leaps."
> >
> >
> > >>> <[email-masked]> 12/04 2:29 PM >>>
> > Bob, Mike,
> >  I agree completely with the importance of obeying critical extensions.
But
> > I
> > also believe that there will be "rogue applications" that may or may not
> > handle
> > these extensions properly dependent on the specific application. For
> > example,
> > if I have a certificate whose policy is explicitly for signing user
> > certificates, someone may develop an application that allows me to use
that
> > certificate for applying for a credit card exclusively for CAs. The
"relying
> >
> > party" in this case accepts the risk in using that certificate despite
the
> > policy under which it was issued. If used improperly by these rogue
> > applications, Mike is correct in saying that all CA (or other) liability
is
> > relieved. Hopefully, the relying party would have a difficult fight in
court
> > if
> > they wanted to blame the CA who issued that certificate. The point is
that
> > we
> > can only write the specifications, we cannot enforce them.
> >
> > Cheers,
> > Dave Oshman
> >
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Practice
> > >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> > >From:    Mike Smith <[email-masked]>
> > >Subject: Re: digitalSignature vs. nonRepudiation
> > >As usual, Bob, I find myself agreeing with your statements.
> > >
> > >A certificate is issued under a certain set of authority policies.  If
> > someone
> > wishes >to rely on a certificate issued under those policies, then the
> > software
> > they use must >be able to process all of the critical extensions
established
> >
> > under that policy or >not honor the certificate.
> > >
> > >If someone does accept a certificate or signature issued with critical
> > extensions >that are ignored or interpreted other than the intent of the
> > issuing CA, then, it is >my belief, the reliant party (and, possibly the
> > entity
> > that modified the code to >accept or ignore the critical extensions) has
> > just
> > relieved the CA of any and all >liability regarding that critical
extension
> > and, quite possibly, the whole >certificate's issued purpose.
> > >
> > >Michael
> > >
> > >>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
> > >Sharon and David,
> > >
> > >My tongue in cheek suggestion that we deprecate the keyUsage field was
made
> > >as a result of my confusion and exasperation in trying to sort though
all
> > of
> > >these different issues.  But if we can't agree on some relatively
simple
> > >meaning, I submit that using the fields will actually be WORSE than
> > >deprecating them, for one person will think that they mean one thing,
and
> > >another person will interpret them differently.
> > >
> > >What good does it do to mark an attribute as critical, if the semantics
are
> > >as undefined or ambiguous as these are?
> > >
> > >And to bring up a somewhat different ubject that I mentioned before,
but
> > >never got closure on, I think that it is completely UNACCEPTABLE to say
> > that
> > >if some particular application does not have, understand, or chose to
> > >implement a security policy, it should be free to simply ignore the
> > critical
> > >marking on a Policy OID constraint. This simply turns the definition of
> > >critical on its head.  The critical usage is provided primarily to
protect
> > >the CA and/or the subject of the certificate from unreasonable reliance
on
> > >the certificate, and to provide a means for IT administrators to
centrally
> > >control what kinds of policies are to be enforced.
> > >
> > >Bob
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

From: Xiaoyi Liu <[email-masked]>
Subject: sorry for the broadcasting ...
To: [email-masked]
Date: Thu, 11 Dec 1997 13:41:53 -0800 (PST)
Status:

Hi,

I intended to send a private email to Mike but it was accidently send out
to the pkix mailing list. Please ignore it and accept my appology.

Xiaoyi

Date: Thu, 11 Dec 1997 15:29:49 -0500
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: Charles Moore <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Critical extensions and Policy OIDs
Status:

Charles,

You should direct your comment to X.509, not PKIX-1, since that is where
the requirement originates.  It is only when the extension is made
critical that there is any implication to the application.  PKIX-1 does
not provide a recommendation for criticality.

Dave Simonetti

Charles Moore wrote:
> 
> -----Original Message-----
> From: Simonetti David <[email-masked]>
> To: [email-masked] <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: Friday, 12 December 1997 2:54
> Subject: Re: Critical extensions and Policy OIDs
> 
> :Moshe,
> :
> :I respectively disagree with your analysis.  The paranthetical of PKIX-1
> :is not a reference to cert path validation, but rather is a reference to
> :how the application *uses* the certificate after validation (please
> :let's not debate the merits applying requirements to the application).
> 
> But that is the issue, and PKIX should not try and standardise applications.
> 
> Stick to providing standardised services that let end users make policy
> decisions.

From: Xiaoyi Liu <[email-masked]>
Subject: Re: [IETF-PKIX] 7/10 draft update
To: [email-masked]
Date: Thu, 11 Dec 1997 12:40:24 -0800 (PST)
Cc: [email-masked] (Xiaoyi Liu)
Status:

Mike,

I have to go back to California for some customer issues. In the second
pkix meeting (I could not stay the whole meeting since my flight left at
6:00 45 pm), my impression is that basicly CMP agreed to update their doc
to reference CRS and we are going to have a common certificate request
message. If this is true, we have a success.

I am going to read the draft (sorry for not doing this quick enough since
I had to work on commit and bugfix the customer needed) and send you my
comment. 

Please update me the progress of the draft status.

Thanks

XIaoyi

From: "Charles Moore" <[email-masked]>
To: "Simonetti David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Critical extensions and Policy OIDs
Date: Fri, 12 Dec 1997 06:00:08 +1000
Status:

-----Original Message-----
From: Simonetti David <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, 12 December 1997 2:54
Subject: Re: Critical extensions and Policy OIDs

:Moshe,
:
:I respectively disagree with your analysis.  The paranthetical of PKIX-1
:is not a reference to cert path validation, but rather is a reference to
:how the application *uses* the certificate after validation (please
:let's not debate the merits applying requirements to the application).

But that is the issue, and PKIX should not try and standardise applications.

Stick to providing standardised services that let end users make policy
decisions.

Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s (????/----) (0001DBD2)

Date: Thu, 11 Dec 1997 09:26:52 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 9 Dec 1997 [email-masked] wrote:
> 
> Marc,
> 
> My interpretation of your requirement implies the CA operate in a fashion
> that enables the "false revocation" attack Carlisle earlier identified.  I
> may be misunderstanding your requiremment however.  May I ask that you
> express it more precisely?
> 
> Mike
> 

I don't remember the specifics about Carlisle's attack, and the archive on
ftp.tandem.com seems to end in September.  Could you give me a brief
refresher?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Thu, 11 Dec 1997 10:26:46 -0500
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: [email-masked]
CC: [email-masked]
Subject: Re: Critical extensions and Policy OIDs

Moshe,

I respectively disagree with your analysis.  The paranthetical of PKIX-1
is not a reference to cert path validation, but rather is a reference to
how the application *uses* the certificate after validation (please
let's not debate the merits applying requirements to the application). 
This is described in X.509 by the quotation I provided in my previous
message.

As an example of a use of a critical certificate policies extension,
let's say that I'm a CA generating and signing certificates for my
private community.  By signing the certificate I am vouching for the
identity of the certificate subject.  I'm concerned about by my
liability if an individual decides to misuse her/his certificate outside
of my community, so within my certificate policy is a statement that the
certificate may never be used for any purpose outside of the community. 
I then include the OID of that policy in the certificate policies
extension of every certificate that I generate, and I indicate the
extension as critical.

X.509 states that the certifcate with this extension as critical "shall
only be used for the purpose...implied by one of the indicated
certificate policies."  As a result, an application that claims
X.509-compliance cannot use this certificate for a purpose other than
that stated in the registered certificate policy.  It's not entirely
clear to me yet how an application can truely restrict the use of a
certificate in this manner, but in any case, as the CA that generated
the certificate, I can use this extension to (hopefully) limit my
liability in case of certificate misuse.

Dave Simonetti

[email-masked] wrote:
> 
> The Certificate Policies extension is not the only factor in validating
> a certificate policie, two other factors are the path validation algorithm
> and the policy constraints extention.
> 
> According to the path validation algorithm, an application that has no
> explicit policy requirements has almost nothing to do with the Certificate
> Policies extension, unless there is a policy constraints extention.
> (almost nothing because it should show the user the "User notice" policy,
> but this is a should and not a must).
> 
> In view of this the offending sentence:
> 
> "(Applications without specific policy requirements are not required to list
> acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> 
> adds no information and is only a clarification of the path validation
> algorithm.
> 
> If a CA want to stop that behavour it can use a critical policy constraints
> etension that contains the requireExplicitPolicy field.
> 
> Moshe Litvin
> 
> > Bob--
> >  Being relatively new to this mailing list, I did not notice the sentence you
> > quoted. Knowing the authors, I suspect they have a good reason for putting that
> > line in there and I would like to hear it. However, I can't imagine that the
> > reason is good enough to make up for the trouble it may cause! The lawyers at
> > the clients I work with (large financial institutions, insurance companies,
> > telecomms, etc.) would "have a cow" if they realized that their software may be
> > "PKIX conformant" and still not support a critical extension that they are
> > relying on to possibly limit their liability. What is the point of marking
> > anything critical with that sentence in the document? Before I rave anymore,
> > could one of the authors restate their reasoning for including that sentence?
> > I'd like to hear the other side of the coin. Thanks.
> >
> > Dave Oshman
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Security
> >
> >
> >
> >
> >
> > [email-masked] on 12/05/97 12:41:54 PM
> > To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
> > cc: [email-masked] @ Internet, [email-masked] @ Internet
> > Subject: Critical extensions and Policy OIDs
> >
> > Dave,
> >
> > So that we are all on the same page, let me refer you to the Oct 14th draft
> > of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> >
> > "Applications with specific policy requirements are expected to have a list
> > of those policies which they will accept and to compare the policy OIDs in
> > the certificate in that list. If this extension is critical, the path
> > validation software must be able to interpret this extension, or must reject
> > the certificate."
> >
> > So far so good, although the text tends to put too much emphasis on
> > applications deciding on their own what policy requirements they require and
> > will enforce, whereas I believe that such decisions will more often be made
> > by the MIS department and conveyed in the root-level certificate (issued by
> > the MIS department) which cross-certifies particular CAs and imposes any
> > necessary policy constraints on subsequent certificates.
> >
> > Where the train jumps the track is in the following sentence of the
> > paragraph:
> >
> > "(Applications without specific policy requirements are not required to list
> > acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> > POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> >
> > This takes the issue well beyond that of a rogue application.  It says that
> > a PKIX standards-conforming application can ignore an attribute bearing a
> > Critical marking with impunity -- it doesn't have to even notify the user
> > that it saw something that it doesn't understand.
> >
> > I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
> > help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
> > Solo) to delete this sentence.
> >
> > I think that we are in agreement that if someone goes out and buys an
> > application that is non-conforming, we aren't going to sic the Internet
> > police on him. I'm not trying to prevent anyone from building rogue
> > applications. However, if someone knowingly uses an application that does
> > not conform to the standard, or does not implement the Critical attribute
> > correctly, he has to accept the consequences of his actions, and both the CA
> > and the subscriber should be relieved of any liability that might result
> > from the relying party accepting some transaction that they should have
> > rejected, based on the policy OID and the Critical flag.
> >
> > But if the standard itself says that such markings can be ignored with
> > impunity and still be considered as conforming to the standard, then the CA
> > and/or the subscriber haven't a leg to stand on, for they have no way to
> > ensure that effective legal notice is provided to any potential relying
> > party.
> >
> > This sentence must be removed or clarified considerably before the standard
> > can be accepted, IMHO, for the concept of a Critical attribute is
> > fundamental to the entire concept of legal notice which the certificate is
> > supposed to provide.
> >
> > Bob
> >
> > Robert R. Jueneman
> > Security Architect
> > Novell, Inc.
> > Network Services Division
> > 122 East 1700 South
> > Provo, UT 84604
> > 801/861-7387
> > [email-masked]
> >
> > "If you are trying to get to the moon, climbing a tree,
> > although a step in the right direction, will not prove
> > to be very helpful."
> >
> > "The most dangerous strategy is to cross the chasm in two leaps."
> >
> >
> > >>> <[email-masked]> 12/04 2:29 PM >>>
> > Bob, Mike,
> >  I agree completely with the importance of obeying critical extensions. But
> > I
> > also believe that there will be "rogue applications" that may or may not
> > handle
> > these extensions properly dependent on the specific application. For
> > example,
> > if I have a certificate whose policy is explicitly for signing user
> > certificates, someone may develop an application that allows me to use that
> > certificate for applying for a credit card exclusively for CAs. The "relying
> >
> > party" in this case accepts the risk in using that certificate despite the
> > policy under which it was issued. If used improperly by these rogue
> > applications, Mike is correct in saying that all CA (or other) liability is
> > relieved. Hopefully, the relying party would have a difficult fight in court
> > if
> > they wanted to blame the CA who issued that certificate. The point is that
> > we
> > can only write the specifications, we cannot enforce them.
> >
> > Cheers,
> > Dave Oshman
> >
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Practice
> > >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> > >From:    Mike Smith <[email-masked]>
> > >Subject: Re: digitalSignature vs. nonRepudiation
> > >As usual, Bob, I find myself agreeing with your statements.
> > >
> > >A certificate is issued under a certain set of authority policies.  If
> > someone
> > wishes >to rely on a certificate issued under those policies, then the
> > software
> > they use must >be able to process all of the critical extensions established
> >
> > under that policy or >not honor the certificate.
> > >
> > >If someone does accept a certificate or signature issued with critical
> > extensions >that are ignored or interpreted other than the intent of the
> > issuing CA, then, it is >my belief, the reliant party (and, possibly the
> > entity
> > that modified the code to >accept or ignore the critical extensions) has
> > just
> > relieved the CA of any and all >liability regarding that critical extension
> > and, quite possibly, the whole >certificate's issued purpose.
> > >
> > >Michael
> > >
> > >>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
> > >Sharon and David,
> > >
> > >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> > >as a result of my confusion and exasperation in trying to sort though all
> > of
> > >these different issues.  But if we can't agree on some relatively simple
> > >meaning, I submit that using the fields will actually be WORSE than
> > >deprecating them, for one person will think that they mean one thing, and
> > >another person will interpret them differently.
> > >
> > >What good does it do to mark an attribute as critical, if the semantics are
> > >as undefined or ambiguous as these are?
> > >
> > >And to bring up a somewhat different ubject that I mentioned before, but
> > >never got closure on, I think that it is completely UNACCEPTABLE to say
> > that
> > >if some particular application does not have, understand, or chose to
> > >implement a security policy, it should be free to simply ignore the
> > critical
> > >marking on a Policy OID constraint. This simply turns the definition of
> > >critical on its head.  The critical usage is provided primarily to protect
> > >the CA and/or the subject of the certificate from unreasonable reliance on
> > >the certificate, and to provide a means for IT administrators to centrally
> > >control what kinds of policies are to be enforced.
> > >
> > >Bob
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

Date: Thu, 11 Dec 1997 09:09:31 -0500 (EST)
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes

Folks,

	Attached are the DRAFT minutes from the two days of PKIX meetings
at the 40th IETF.  I would appreciate it if those who were presenters at
the meetings could review the minutes and send me corrections before Xmas.

Thanks,

Steve
-----------------------------------------------------------

PKIX WG Meeting Minutes (12/8+10/97)

Approximately xxx attendees participated in the two PKIX WG session at
the 40th IETF.  Several of the PKIX I-Ds have been through working
group last call and have moved on to the IESG for review, but a few
issues remain and must be resolved prior to IESG approval and IETF
last call.

Part 1 (Certificate/CRL Profile)

This draft completed WG last call, but a few issues remain to be
resolved.  Issues relating to use of algorithm OIDs and some ASN.1
errors have been resolved, and the authors have avoided inclusion of
some legal language that was previously proposed.

Unresolved issues:
	- There is disagreement about wildcarding in names (e.g., DNS
and RFC 822).  A small group met to resolve this issue after the (2nd)
meeting.  That group suggested disallowing use of asterisks in these
name forms as a means of conveying the notion that the name was a
placeholder for a set of names.  Instead, a new document will be
created to describe name form conventions, on a per-application
context basis, with explicitly declared semantics, in support of the
requirements that motivated use of wildcard name forms.
	- We are using '88 ASN.1, but BMP string is a new ASN.1
construct, so this is a technical matter (but does not affect bit on
the wire format).
	- There is a related issue is use of UTF8, a new ('98 ASN.1)
character set encoding, an alternative to BMP.  This appears to be an
issue at the IESG last call level of approval, but is not an issue
among PKIX members.
	- For key usage, we propose to stay with what X.509 says,
despite disagreements over whether it is the "right" interpretation.
	- Should CRLDistributionPoint be critical, non-critical, or at
the discretion of the CA?  Currently, it cannot be marked critical,
but this can cause problems.  The concern is that if marked critical,
then a client without support for this would reject the certificate,
even if the user was willing to ignore this extension, as required by
X.509. Not resolved.

Part 2 (split into LDAP, FTP, HTTP, OCSP)

No problems with FTP or HTTP.  LDAP issues revolve around v2 vs. v3
usage.  We agree to add a new work item to deal with v3, since current
LDAP use in PKIX is based on v2.  There was a suggestion to add a work
item to develop a minimal schema for PKIX use of LDAP.  This is a
possible overlap with the LDAP WG, so coordination is required.  Later
during the week the LDAP WG chair was contacted and it was determined
that creation of a schema for use with PKIX was within the purview of
the PKIX WG. See slides for additional details.

Part 3 (Certificate Management Protocol)

No issues here other than the character set concerns raised under Part 1.

Certificate Request Syntax (PKCS7/10 focus)

A proposal was made to move work on this to S/MIME WG, and Schiller
and Housley (S/MIME WG chair) have no objections.  However, this work
is not S/MIME-specific and several PKIX and S/MIME WG members believe
that this work item should remain in PKIX, as it is more general.  The
fundamental question is whether CRS is a completely separate protocol,
focused on S/MIME, or if it is a profile for Part 3.  Not resolved,
but straw poll of attendees showed a plurality of attendees in favor of
keeping the work item in this WG, and only a single vote in favor of
moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred
with this and did not recommend adoption of CRS within that WG.

At the second PKIX WG meeting, a compromise approach was announced,
reconciling CRS and CMP.  In essence, CRS will be revised and will
define a common request syntax, and CMP will adopt this syntax as the
certificate payload type within that protocol (replacing the current
certificate payload format).  The Security AD approved the progression
to IETF last call with a modified version of CMP, reflecting this
change.  This new, harmonized certificate request format will appear
as a separate RFC.  CMS will make use of the same format and that
protocol will progress as a separate RFC as well.

Time-Stamping and Notary Protocols

These are new, potential work items, discussed on a preliminary basis
in Munich.  Two presentations: Rob Zuccherato (Entrust) on time
stamping and notary functions, and Stewart Haber (Surety) on time
stamping. See slides for additional details.

Entrust- Timestamping service described here deals exclusively with
establishing existence of data (really a hash of data) at a point in
time.  Basic notary service for data demonstrates that a requester
posses data (not just a hash of the data) at a given time.  A
certificate notary service requires validation of a certificate chain
for the requester, including CRLs and ARLs.  There is also a fancy
data notarization service, encompassing data validity, and a combined
service of data possession and validity.  Some folks note that
validation of data (and certificates) is outside the scope of what
real world notaries do in the U.S. (but Latin Notaires do have broader
functions).

Surety- Stewart provided an overview of timestamping problem and
solution space, with a focus on the hash tree technology developed
(patented) and offered by Surety as a service.  The current Surety
service offers a 1 second granularity,

At least one WG member argued that the notary and timestamping
functions are not completely PKI-specific, and we should try to avoid
duplication of efforts like the PKIX/SPKI situation.  Another member
noted that there is a new I-D for time stamping via NTP, that raises
possible overlap concerns as well.  One possible outcome is a split of
time stamping vs. notary functions.  Certificate path validation, a
part of the described notary service, does make sense for PKIX,
consistent with X.509 validation procedures.

A straw poll during the second PKIX meeting showed a strong sentiment
that this WG amend its charter to include development of a standard for
time stamping, but there was not strong support for adding a work item
to develop notary functions (other than certificate path validation).

OCSP

Mike Myers provided a status review for this I-D, and responded to
comments that have appeared on the WG list over the last few weeks.  A
number of modifications will be made as a result of these comments
Mike described a schedule for revisions and (new) comments to bring
OCSP to WG last call in time for the next (LA) IETF meeting.  Included
in the revisions will be a better characterization of the contexts in
which OCSP are expected to operate, since that range of environments
has grown since OCSP was initially designed.

Date: Thu, 11 Dec 1997 08:59:17 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: Critical extensions and Policy OIDs

The Certificate Policies extension is not the only factor in validating
a certificate policie, two other factors are the path validation algorithm
and the policy constraints extention.

According to the path validation algorithm, an application that has no
explicit policy requirements has almost nothing to do with the Certificate
Policies extension, unless there is a policy constraints extention.
(almost nothing because it should show the user the "User notice" policy,
but this is a should and not a must).

In view of this the offending sentence:

"(Applications without specific policy requirements are not required to list
acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"

adds no information and is only a clarification of the path validation 
algorithm.

If a CA want to stop that behavour it can use a critical policy constraints
etension that contains the requireExplicitPolicy field.

Moshe Litvin

> Bob--
>  Being relatively new to this mailing list, I did not notice the sentence you 
> quoted. Knowing the authors, I suspect they have a good reason for putting that 
> line in there and I would like to hear it. However, I can't imagine that the 
> reason is good enough to make up for the trouble it may cause! The lawyers at 
> the clients I work with (large financial institutions, insurance companies, 
> telecomms, etc.) would "have a cow" if they realized that their software may be 
> "PKIX conformant" and still not support a critical extension that they are 
> relying on to possibly limit their liability. What is the point of marking 
> anything critical with that sentence in the document? Before I rave anymore, 
> could one of the authors restate their reasoning for including that sentence? 
> I'd like to hear the other side of the coin. Thanks.
>  
> Dave Oshman
> Price Waterhouse LLP
> Electronic Commerce/Internet Security
> 
> 
> 
> 
> 
> [email-masked] on 12/05/97 12:41:54 PM
> To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
> cc: [email-masked] @ Internet, [email-masked] @ Internet 
> Subject: Critical extensions and Policy OIDs
> 
> Dave,
> 
> So that we are all on the same page, let me refer you to the Oct 14th draft
> of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> 
> "Applications with specific policy requirements are expected to have a list
> of those policies which they will accept and to compare the policy OIDs in
> the certificate in that list. If this extension is critical, the path
> validation software must be able to interpret this extension, or must reject
> the certificate."
> 
> So far so good, although the text tends to put too much emphasis on
> applications deciding on their own what policy requirements they require and
> will enforce, whereas I believe that such decisions will more often be made
> by the MIS department and conveyed in the root-level certificate (issued by
> the MIS department) which cross-certifies particular CAs and imposes any
> necessary policy constraints on subsequent certificates.
> 
> Where the train jumps the track is in the following sentence of the
> paragraph:
> 
> "(Applications without specific policy requirements are not required to list
> acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> 
> This takes the issue well beyond that of a rogue application.  It says that
> a PKIX standards-conforming application can ignore an attribute bearing a
> Critical marking with impunity -- it doesn't have to even notify the user
> that it saw something that it doesn't understand.
> 
> I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
> help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
> Solo) to delete this sentence.
> 
> I think that we are in agreement that if someone goes out and buys an
> application that is non-conforming, we aren't going to sic the Internet
> police on him. I'm not trying to prevent anyone from building rogue
> applications. However, if someone knowingly uses an application that does
> not conform to the standard, or does not implement the Critical attribute
> correctly, he has to accept the consequences of his actions, and both the CA
> and the subscriber should be relieved of any liability that might result
> from the relying party accepting some transaction that they should have
> rejected, based on the policy OID and the Critical flag.
> 
> But if the standard itself says that such markings can be ignored with
> impunity and still be considered as conforming to the standard, then the CA
> and/or the subscriber haven't a leg to stand on, for they have no way to
> ensure that effective legal notice is provided to any potential relying
> party.
> 
> This sentence must be removed or clarified considerably before the standard
> can be accepted, IMHO, for the concept of a Critical attribute is
> fundamental to the entire concept of legal notice which the certificate is
> supposed to provide.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> "If you are trying to get to the moon, climbing a tree, 
> although a step in the right direction, will not prove 
> to be very helpful."
> 
> "The most dangerous strategy is to cross the chasm in two leaps."
> 
> 
> >>> <[email-masked]> 12/04 2:29 PM >>>
> Bob, Mike,
>  I agree completely with the importance of obeying critical extensions. But
> I 
> also believe that there will be "rogue applications" that may or may not
> handle 
> these extensions properly dependent on the specific application. For
> example, 
> if I have a certificate whose policy is explicitly for signing user 
> certificates, someone may develop an application that allows me to use that 
> certificate for applying for a credit card exclusively for CAs. The "relying
> 
> party" in this case accepts the risk in using that certificate despite the 
> policy under which it was issued. If used improperly by these rogue 
> applications, Mike is correct in saying that all CA (or other) liability is 
> relieved. Hopefully, the relying party would have a difficult fight in court
> if 
> they wanted to blame the CA who issued that certificate. The point is that
> we 
> can only write the specifications, we cannot enforce them.
> 
> Cheers,
> Dave Oshman
> 
> Price Waterhouse LLP
> Electronic Commerce/Internet Practice
> >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> >From:    Mike Smith <[email-masked]>
> >Subject: Re: digitalSignature vs. nonRepudiation
> >As usual, Bob, I find myself agreeing with your statements.
> >
> >A certificate is issued under a certain set of authority policies.  If
> someone 
> wishes >to rely on a certificate issued under those policies, then the
> software 
> they use must >be able to process all of the critical extensions established
> 
> under that policy or >not honor the certificate.
> >
> >If someone does accept a certificate or signature issued with critical 
> extensions >that are ignored or interpreted other than the intent of the 
> issuing CA, then, it is >my belief, the reliant party (and, possibly the
> entity 
> that modified the code to >accept or ignore the critical extensions) has
> just 
> relieved the CA of any and all >liability regarding that critical extension 
> and, quite possibly, the whole >certificate's issued purpose.
> >
> >Michael
> >
> >>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
> >Sharon and David,
> >
> >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> >as a result of my confusion and exasperation in trying to sort though all
> of
> >these different issues.  But if we can't agree on some relatively simple
> >meaning, I submit that using the fields will actually be WORSE than
> >deprecating them, for one person will think that they mean one thing, and
> >another person will interpret them differently.
> >
> >What good does it do to mark an attribute as critical, if the semantics are
> >as undefined or ambiguous as these are?
> >
> >And to bring up a somewhat different ubject that I mentioned before, but
> >never got closure on, I think that it is completely UNACCEPTABLE to say
> that
> >if some particular application does not have, understand, or chose to
> >implement a security policy, it should be free to simply ignore the
> critical
> >marking on a Policy OID constraint. This simply turns the definition of
> >critical on its head.  The critical usage is provided primarily to protect
> >the CA and/or the subject of the certificate from unreasonable reliance on
> >the certificate, and to provide a means for IT administrators to centrally
> >control what kinds of policies are to be enforced.
> >
> >Bob
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                      
> 

Date: Wed, 10 Dec 1997 09:49:07 -0800
From: "Thane E. Plambeck" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Announcing the cert-talk X.509 mailing list

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

Date: Wed, 10 Dec 1997 10:27:18 -0500
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Critical extensions and Policy OIDs

You've piqued my interest as well.  This statement does seem to
contradict the statement of X.509, "if the extension is flagged
critical, it indicates that the certificate shall only be used for the
purpose, and in accordance with the rules implied by one of the
indicated certificate policies."

Dave Simonetti

[email-masked] wrote:
> 
> Bob--
>  Being relatively new to this mailing list, I did not notice the sentence you
> quoted. Knowing the authors, I suspect they have a good reason for putting that
> line in there and I would like to hear it. However, I can't imagine that the
> reason is good enough to make up for the trouble it may cause! The lawyers at
> the clients I work with (large financial institutions, insurance companies,
> telecomms, etc.) would "have a cow" if they realized that their software may be
> "PKIX conformant" and still not support a critical extension that they are
> relying on to possibly limit their liability. What is the point of marking
> anything critical with that sentence in the document? Before I rave anymore,
> could one of the authors restate their reasoning for including that sentence?
> I'd like to hear the other side of the coin. Thanks.
> 
> Dave Oshman
> Price Waterhouse LLP
> Electronic Commerce/Internet Security
> 
> [email-masked] on 12/05/97 12:41:54 PM
> To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
> cc: [email-masked] @ Internet, [email-masked] @ Internet
> Subject: Critical extensions and Policy OIDs
> 
> Dave,
> 
> So that we are all on the same page, let me refer you to the Oct 14th draft
> of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> 
> "Applications with specific policy requirements are expected to have a list
> of those policies which they will accept and to compare the policy OIDs in
> the certificate in that list. If this extension is critical, the path
> validation software must be able to interpret this extension, or must reject
> the certificate."
> 
> So far so good, although the text tends to put too much emphasis on
> applications deciding on their own what policy requirements they require and
> will enforce, whereas I believe that such decisions will more often be made
> by the MIS department and conveyed in the root-level certificate (issued by
> the MIS department) which cross-certifies particular CAs and imposes any
> necessary policy constraints on subsequent certificates.
> 
> Where the train jumps the track is in the following sentence of the
> paragraph:
> 
> "(Applications without specific policy requirements are not required to list
> acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> 
> This takes the issue well beyond that of a rogue application.  It says that
> a PKIX standards-conforming application can ignore an attribute bearing a
> Critical marking with impunity -- it doesn't have to even notify the user
> that it saw something that it doesn't understand.
> 
> I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
> help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
> Solo) to delete this sentence.
> 
> I think that we are in agreement that if someone goes out and buys an
> application that is non-conforming, we aren't going to sic the Internet
> police on him. I'm not trying to prevent anyone from building rogue
> applications. However, if someone knowingly uses an application that does
> not conform to the standard, or does not implement the Critical attribute
> correctly, he has to accept the consequences of his actions, and both the CA
> and the subscriber should be relieved of any liability that might result
> from the relying party accepting some transaction that they should have
> rejected, based on the policy OID and the Critical flag.
> 
> But if the standard itself says that such markings can be ignored with
> impunity and still be considered as conforming to the standard, then the CA
> and/or the subscriber haven't a leg to stand on, for they have no way to
> ensure that effective legal notice is provided to any potential relying
> party.
> 
> This sentence must be removed or clarified considerably before the standard
> can be accepted, IMHO, for the concept of a Critical attribute is
> fundamental to the entire concept of legal notice which the certificate is
> supposed to provide.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
> 
> "The most dangerous strategy is to cross the chasm in two leaps."
> 
> >>> <[email-masked]> 12/04 2:29 PM >>>
> Bob, Mike,
>  I agree completely with the importance of obeying critical extensions. But
> I
> also believe that there will be "rogue applications" that may or may not
> handle
> these extensions properly dependent on the specific application. For
> example,
> if I have a certificate whose policy is explicitly for signing user
> certificates, someone may develop an application that allows me to use that
> certificate for applying for a credit card exclusively for CAs. The "relying
> 
> party" in this case accepts the risk in using that certificate despite the
> policy under which it was issued. If used improperly by these rogue
> applications, Mike is correct in saying that all CA (or other) liability is
> relieved. Hopefully, the relying party would have a difficult fight in court
> if
> they wanted to blame the CA who issued that certificate. The point is that
> we
> can only write the specifications, we cannot enforce them.
> 
> Cheers,
> Dave Oshman
> 
> Price Waterhouse LLP
> Electronic Commerce/Internet Practice
> >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> >From:    Mike Smith <[email-masked]>
> >Subject: Re: digitalSignature vs. nonRepudiation
> >As usual, Bob, I find myself agreeing with your statements.
> >
> >A certificate is issued under a certain set of authority policies.  If
> someone
> wishes >to rely on a certificate issued under those policies, then the
> software
> they use must >be able to process all of the critical extensions established
> 
> under that policy or >not honor the certificate.
> >
> >If someone does accept a certificate or signature issued with critical
> extensions >that are ignored or interpreted other than the intent of the
> issuing CA, then, it is >my belief, the reliant party (and, possibly the
> entity
> that modified the code to >accept or ignore the critical extensions) has
> just
> relieved the CA of any and all >liability regarding that critical extension
> and, quite possibly, the whole >certificate's issued purpose.
> >
> >Michael
> >
> >>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
> >Sharon and David,
> >
> >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> >as a result of my confusion and exasperation in trying to sort though all
> of
> >these different issues.  But if we can't agree on some relatively simple
> >meaning, I submit that using the fields will actually be WORSE than
> >deprecating them, for one person will think that they mean one thing, and
> >another person will interpret them differently.
> >
> >What good does it do to mark an attribute as critical, if the semantics are
> >as undefined or ambiguous as these are?
> >
> >And to bring up a somewhat different ubject that I mentioned before, but
> >never got closure on, I think that it is completely UNACCEPTABLE to say
> that
> >if some particular application does not have, understand, or chose to
> >implement a security policy, it should be free to simply ignore the
> critical
> >marking on a Policy OID constraint. This simply turns the definition of
> >critical on its head.  The critical usage is provided primarily to protect
> >the CA and/or the subject of the certificate from unreasonable reliance on
> >the certificate, and to provide a means for IT administrators to centrally
> >control what kinds of policies are to be enforced.
> >
> >Bob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 8 Dec 97 14:38:56 EST
Subject: Re: Critical extensions and Policy OIDs

Bob--
 Being relatively new to this mailing list, I did not notice the sentence you 
quoted. Knowing the authors, I suspect they have a good reason for putting that 
line in there and I would like to hear it. However, I can't imagine that the 
reason is good enough to make up for the trouble it may cause! The lawyers at 
the clients I work with (large financial institutions, insurance companies, 
telecomms, etc.) would "have a cow" if they realized that their software may be 
"PKIX conformant" and still not support a critical extension that they are 
relying on to possibly limit their liability. What is the point of marking 
anything critical with that sentence in the document? Before I rave anymore, 
could one of the authors restate their reasoning for including that sentence? 
I'd like to hear the other side of the coin. Thanks.
 
Dave Oshman
Price Waterhouse LLP
Electronic Commerce/Internet Security

[email-masked] on 12/05/97 12:41:54 PM
To: Dave Oshman@Price Waterhouse-US, [email-masked] @ Internet
cc: [email-masked] @ Internet, [email-masked] @ Internet 
Subject: Critical extensions and Policy OIDs

Dave,

So that we are all on the same page, let me refer you to the Oct 14th draft
of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:

"Applications with specific policy requirements are expected to have a list
of those policies which they will accept and to compare the policy OIDs in
the certificate in that list. If this extension is critical, the path
validation software must be able to interpret this extension, or must reject
the certificate."

So far so good, although the text tends to put too much emphasis on
applications deciding on their own what policy requirements they require and
will enforce, whereas I believe that such decisions will more often be made
by the MIS department and conveyed in the root-level certificate (issued by
the MIS department) which cross-certifies particular CAs and imposes any
necessary policy constraints on subsequent certificates.

Where the train jumps the track is in the following sentence of the
paragraph:

"(Applications without specific policy requirements are not required to list
acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"

This takes the issue well beyond that of a rogue application.  It says that
a PKIX standards-conforming application can ignore an attribute bearing a
Critical marking with impunity -- it doesn't have to even notify the user
that it saw something that it doesn't understand.

I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
Solo) to delete this sentence.

I think that we are in agreement that if someone goes out and buys an
application that is non-conforming, we aren't going to sic the Internet
police on him. I'm not trying to prevent anyone from building rogue
applications. However, if someone knowingly uses an application that does
not conform to the standard, or does not implement the Critical attribute
correctly, he has to accept the consequences of his actions, and both the CA
and the subscriber should be relieved of any liability that might result
from the relying party accepting some transaction that they should have
rejected, based on the policy OID and the Critical flag.

But if the standard itself says that such markings can be ignored with
impunity and still be considered as conforming to the standard, then the CA
and/or the subscriber haven't a leg to stand on, for they have no way to
ensure that effective legal notice is provided to any potential relying
party.

This sentence must be removed or clarified considerably before the standard
can be accepted, IMHO, for the concept of a Critical attribute is
fundamental to the entire concept of legal notice which the certificate is
supposed to provide.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

>>> <[email-masked]> 12/04 2:29 PM >>>
Bob, Mike,
 I agree completely with the importance of obeying critical extensions. But
I 
also believe that there will be "rogue applications" that may or may not
handle 
these extensions properly dependent on the specific application. For
example, 
if I have a certificate whose policy is explicitly for signing user 
certificates, someone may develop an application that allows me to use that 
certificate for applying for a credit card exclusively for CAs. The "relying

party" in this case accepts the risk in using that certificate despite the 
policy under which it was issued. If used improperly by these rogue 
applications, Mike is correct in saying that all CA (or other) liability is 
relieved. Hopefully, the relying party would have a difficult fight in court
if 
they wanted to blame the CA who issued that certificate. The point is that
we 
can only write the specifications, we cannot enforce them.

Cheers,
Dave Oshman

Price Waterhouse LLP
Electronic Commerce/Internet Practice
>Date:    Wed, 3 Dec 1997 08:34:05 -0700
>From:    Mike Smith <[email-masked]>
>Subject: Re: digitalSignature vs. nonRepudiation
>As usual, Bob, I find myself agreeing with your statements.
>
>A certificate is issued under a certain set of authority policies.  If
someone 
wishes >to rely on a certificate issued under those policies, then the
software 
they use must >be able to process all of the critical extensions established

under that policy or >not honor the certificate.
>
>If someone does accept a certificate or signature issued with critical 
extensions >that are ignored or interpreted other than the intent of the 
issuing CA, then, it is >my belief, the reliant party (and, possibly the
entity 
that modified the code to >accept or ignore the critical extensions) has
just 
relieved the CA of any and all >liability regarding that critical extension 
and, quite possibly, the whole >certificate's issued purpose.
>
>Michael
>
>>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all
of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say
that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the
critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                     

From: [email-masked]
Date: Tue, 09 Dec 1997 23:18:52 -0700
To: Marc Branchaud <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
Cc: [email-masked]

Marc,

My interpretation of your requirement implies the CA operate in a fashion
that enables the "false revocation" attack Carlisle earlier identified.  I
may be misunderstanding your requiremment however.  May I ask that you
express it more precisely?

Mike

At 11:07 AM 12/8/97 -0800, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>On Fri, 5 Dec 1997 [email-masked] wrote:
>> 
>> >OCSP allows the relier to get the revocation information when it's needed,
>> >without being subject to the CA's CRL schedule.  Because CRLs can only be
>> >released periodically, they are at best a compromise solution to the needs
>> >of relying parties.
>> 
>> Keep in mind there's still a periodicity effect in the event of caching.
>> Section 2.3 of the current draft sets out the requirements.
>> 
>
>Agreed.  One of my main points, though, is that relying parties need to be
>able to override any caches (& their effects) at their discretion, not the
>CA's or anyone else's.
>
>> 
>> Again, I completely agree.  However, we must be cautious about overly
>> constraining implementors.  We can and should standardize what's
>> standarizable.
>> 
>
>Perhaps, but is it really overconstraining to make implementors create
>something that works?  To make an analogy, there are some unavoidable
>constraints to building an airplane -- don't make the wings cylinders,
>don't make the engines face each other, etc.  Airplane implementors are
>constrained to create planes that fly.  Similarly, we should constrain PKI
>implementors to make programs that work.  If we are aware of any flaws in
>the standards we create, we should at the very least describe them in the
>documents themselves.  I would prefer not standardizing a flawed system at
>all, but if there's a huge need to push forward then so be it.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                       \/
> Chief PKI Architect                                  /\CERT SOFTWARE INC.
> [email-masked]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNIxFfVrdFXNdDxPlAQHe3wL/RvQhevLG2bOkecStFrliLEXdHOacp3E6
>0UDNyiX/6RKlW0wZcc7PYL57C3RkUIDo4zSyxsYUlStjpyZn425XNTox91TN0nVO
>e1hOIsi8beC5Srlv7xNqCuD0/p3QzUAY
>=1BkI
>-----END PGP SIGNATURE-----
>
>
>

Date: Tue, 09 Dec 1997 20:45:43 -0700
From: Adrian De Leon <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: PKIX/ECDSA - Duplicate OIDs 

Gentlemen:

It appears that some duplicate OBJECT IDENTIFER values have been
assigned in the 21 Nov 97 IETF PKIX IPKI - ECDSA draft.  These
are:

For an ECDSA signature:
iso(1) member-body(2) us(840) ansi-X9-62(10045) ecdsa-with-SHA1(1)
-> { 1  2  840  10045  1 }

(same value as in MISPC)

The duplicate is:
id-fieldType OBJECT IDENTIFER ::= { ansi-X9-62  fieldType(1) }

Which I take to be equivalent to:
iso(1) member-body(2) us(840) ansi-X9-62(10045) id-fieldType(1)
-> { 1  2  840  10045  1 }

Since MISPC agrees w/ the use of this OID to identify an ECDSA
signature,
may I presume that id-fieldType will be changed to something else?

Thank you for your attention to this matter.

Adrian De Leon

Date: Tue, 09 Dec 1997 12:49:54 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: OCSP and Cross-certification

Mack:

You are probably aware of the following point, but thought I'd mention it anyway;  Some cross-certification of CA schemes bring in not just the tree of the CA cross-certified, but all of the Ca trees they have cross-certififed and all of the CA's those have cross-certified, ... etc.  Could be one CA cross cert could bring in all CA trees.

Scary from a Bank's point of view, eh?

Michael

>>> Mack Hicks <[email-masked]> 12/09/97 10:58AM >>>

Tim,

Date: Tue, 9 Dec 1997 11:04:31 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: Mike Smith <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 9 Dec 1997, Mike Smith wrote:
> 
> In OCSP, is there an obligation on the responder to validate the whole
> chain of trust above (and across the network of trust in cross certs),
> or, is OCSP really JUST giving status on the particular cert in the
> status request?
> 
> Michael
> 

Well, the current proposal is concerned solely with the validity of a
single given cert, regardless of whatever context might surround it (such
as a chain it might form a part of).

However, there's a lot of utility in having a "smart" OCSP responder.  For
example, a departmental OCSP responder can be tuned to reflect the trust
parameters of the organization (e.g. which cross-certifications are in
place, and for what purposes).  If all departmental users pass all their
validations through their local OCSP responder, the organization can have
a lot of control over how its employees accpet certificates.

For example, time-of-day restrictions become simple, as the OCSP responder
can be set up to return a "valid" response only during business hours.

OCSP creates a lot of opportunities for flexible PKI policies.  Whether or
not they're possible really depends on how the PKI is modelled.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Tue, 09 Dec 1997 11:49:58 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: OCSP and Cross-certification

Mack, I tend to agree with you regarding the difficulty of implementing a
general, bidirectional, cross-certification model -- especially if there is
any implication of liability flow. Presumably that is why Verisign has not
yet bought into the IBM/Entrust model yet.

However, I would be interested in your comments regarding something I
recently posted on the SPKI list regarding unidirectional certification vis
a vis verifier-selected policy OID constraints, and in particular how you
would view this concept in a commercial environment.

I am increasingly inclined to view certification or cross-certification of
suordinate or peer CAs as soemthing similar to what Standard and Poors would
do for bonds, i.e., a rating service, not a liability-assuming guarantee. 
If someone wants a guarantee, let them go buy an E&O insurance policy, or
vist their local cyber-notary.

I would therefore welcome technical contributions and/or your support for
the requirement for the necessary enhancements to OCSP to support a billing
mechanism for status checking, as well as errors and omissions insurance on
a per transaction basis.

Finally, the attached scenario for certificate validation, including policy
OIDs is the primary reason why I continue to believe that the parenthetical
remark in the second paragraph of 4.2.1.5 of part-1 is completely
unacceptable (it says, "applications withiout specific policy requirements
are not required to list acceptable policies, and may accept any valid
certificate regardless of policy erven if the extension is marked
critical.").

It occurs to me, however, that I may be incorrectly interpreting that
statement in the case where a Policy Constraint is applied.  If the intent
of the spec (especially 4.2.1.12) is that a certificate which contains a
Policy Constraint attribute which is marked Critcal and contains a
requiresExplicitPolicy field essentially trumps the statement in 4.2.1.5,
then I am reasonably content. Although that isn't the way I read it, and I
would like to see the language clarified, if everyone else reads it the way
I believe was intended, then maybe I just need to get new glasses.

Bob

>
>Tim,
>
>From the last announcement by Entrust, IBM, and others, there is a
>perception that the cross-certification of CAs will handle the problem
>of trust generally.  This means that trees within each organization
>will trust trees within other organizations.
>
>Within the Banking industry, discussions uniformly have rejected this
>idea.  We have learned from long experience - with private networks,
>credit cards, funds transfer networks, and others - that the best
>way to manage the risk of a transaction, a connection, or a communication
>is to have on-line status checking.  This is also true with
>the checking of the status of digital certificates.
>
>The volume questions are interesting.  Bank of America processes about
>10% of the US paper checks every night -- over 22,000,000 pieces of paper
>at high water mark.  I think we can handle some multi-million certificate
>status requests.
>
>But we do not do things for free or manage risk of communication without
>authentication.  Therefore the on-line status check is for our customers.
>
>The NACHA Internet Council pilot of CA interoperability will demonstrate
>how Banks will trust each others certificates.
>
>We are using CRLs between banks--and I think CRLs have a place in high
>volume relationships between organizations. This risk of outdated CRLs
>can be managed by agreement and rules that NACHA would set.
>
>Tim wrote:
>
>>>1. Approximately how many OCSP responders are required to serve a
>>>community of one billion relying parties and subscribers?
>>>
>I expect that certificate holders would go to their agents.
>Therefore, the magnitude of OSCPs will be the magnitude of
>agents (essentially CAs or their repositories).
>
>>2. How do the relying parties come to trust the verification keys of the
>>>OCSP responders?
>>>
>By contracted relationship, since they are using the OCSP to THEIR
>agent - and the agent now deals with the trust to other repositories.
>Admittedly, this does make the same problem at the agent's level,
>but this is a less difficult problem since these agents are in this
>business.  They will have contracts and associations.
>
>>>3. How do the OCSP responders obtain revocation information from the
>>>single CA?
>>>
>Revocation information will be by OCSP at low volumes from agent to
>agent.  High volume agents will contract on risk distribution and
>may use CRL mechanisms.
>
>I do not know of a CA will offer its CRLs to all comers without
>authentication. (Talk about denial of service opportunities.)
>
>>>4. How current will the revocation information be when it is presented
>>>to the relying parties?
>>>
>If it is OCSP, it will be as current as represented by the agency.
>Between agencies, association rules and contracts will provide
>this assurance.
>
>
>For all the talk of CRLs, I would like to point out that CRLs
>make really good sense in a military application where the
>commanding officer (relying party) needs to make a decision
>based on available information (certificate, roots, last CRL).
>In a commercial context, we have left this model of behavior
>behind with the advent of telephony.
>
>
>
>Therefore, I state my earlier discussion:
>
>From PKIX 3, I expect that a PKIX compliant CA can
>
>a) Provide a place for CRL or OCSP
>b) Provide a reponse of
>   "I don't know you - go away"
>   for unauthenticated requests.
>c) The relying party should then not automatically trust
>   the certificate since there is no assurance that the
>   certificate is still valid.
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                 
Date: Tue, 09 Dec 1997 10:04:36 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Closed loop paths of trust
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

> To me, there are not apples and speedboats.  Rather, there is
authorization 
>which is injected by the verifier into a so-called root key and passed 
>from that root key through certificates, possibly constrained or
restricted, 
>into the eventual request where it is delivered to the verifier as part of
a 
>request for some kind of action.  This model of trust computation fits all
>known certification examples.  Even though it is foreign to X.509 thinking,
>in particular, it applies to X.509.  The authorization in this example
flows
>in a loop (circuit) from verifier back to verifier.  To use an electrical 
>example, the verifier has both battery and ammeter.
>
> - Carl

At least with respect to X.509 v3 and the PKIX work, it is definitely not
foreign.  There is a continuing and erroneous belief that X.509 is
inherently a top-down trust structure, but this is not the case.

Especially once smart cards with tamper-proof storage for root keys become
popular, I would expect that at least for large organizations the following
will occur:

1.  The MIS or IT organization will issue smart cards containing one or more
public root keys created by the MIS/IT organization.  The root keys will be
embedded in self-signed X.509 certificates containing the organization DN
(for convenience, primarily), together with validity periods, etc.  These
certificate are not necessarily published anywhere, except in the smart
cards issued to employees, so as to minimize any potential liability that
might be caused by using that key to certify other keys.

2.  The self-signed certificates will contain a PolicyConstraint OID
attribute, specifying what other CA's policies are to be considered
acceptable as far as official business is concerned.

3.  The MIS/IT organization may choose to unilaterally cross-certify other
CAs that it trusts, and may in addition provide for policy OID mapping.  For
example, for high value transactions, it might certify an internal CA used
to issue certificates to corporate officers. In addition, now that the State
of Utah has officially certified Digital Signature Trust Co as a licensed CA
under the Utah Digital Signature Act, they might certify certificates from
the State of Utah and from DSTC.  Florida is about to adopt regulations
setting up a rather similar structure, and although it is unknown whether
either Utah or Florida will certify each other, the IT organization might
decide that Florida's certificates are good enough for their purposes, and
certify their public keys as well.

4. Eventually, Utah, Florida, and other states will get around to issuing
certificate to both public CAs like VeriSign, and to private corporations
who operate CAs for their own employees. These various CAs will not
necessarily meet the same strict standards for identification, technical
controls, liability, etc, nor should they.  So the user's IT organization
(or the user himself)  can create perhaps three categories of chains of
trust, called for example Classic, Gold, and Platinum, for various usages. 
Using the policy mapping option, they can map to a hypothetical Utah Red,
White, and Blue series of certificates, to a Florida Pink, Aqua, and Stucco
series; and an Illinois Diamond, Ruby, and Pearl series.  Eventually, those
licensed/accredited CAs may set up equivalent policy mapping controls to map
their series to say an IBM blue, bluer, and true blue series.  (You can have
any color certificate you want from Ford, of course, as long as it is
black.)

5.  Depending on the user's own trust requirements (suitably influenced or
constrained by corporate policy :-), individual applications, and even
different uses of an individual application (S/MIME, for example) may select
a particular color coded trust hierarchy, starting with the appropriate root
certificate and enforced by the policy OID constraints.

6. Once that initial selection is made, assuming that the user's software
correctly implements the certificate validation rules and that the various
intermediate CAs are legally or contractually constrained and audited
appropriately to ensure that the trust is really operable, the user/verifier
can select the appropriate trust environment for the intended use, and have
everything else happen automatically.  In particular, and this is one of the
most important features, if the smart card is trusted and has the
intelligence to validate the certificate chain itself, a digital signature
can be validated without having to rely on untrusted software, OR ON LOCAL
DATABASES.

Since it is the user who chooses which root key to use for particular
applications (at least from the set that is provided to him by his IT
organization), the validation is neither top down, nor bottom up, but both,
in a loop, as Carl has discussed.

(Having said that, I am inclined to wonder whether, after all of this time
and discussion, the SPKI group has developed anything that is sufficiently
different from what the PKIX has developed to be worth the beans, or whether
this has merely been a rather arcane, theological exercise of no practical
benefit. Obviously Carl would disagree with that assessment, and I know him
well enough to know that he is quite sincere in his beliefs.  But I would be
curious to know just who else among the vendor community is prepared to put
their money where their mouth is, and to commit to develop and support
actual products based on this specification?)

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Date: Tue, 09 Dec 1997 09:58:09 -0800
From: Mack Hicks <[email-masked]>
Subject: OCSP and Cross-certification
To: [email-masked] (Return requested)
Cc: [email-masked] (Return requested)
Content-identifier: 03EDB348D86B10E9
Conversion: Allowed
Original-encoded-information-types: IA5-Text
Priority: normal
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 03EDB348D86B10E9-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;

Tim,

Date: Tue, 09 Dec 1997 09:44:55 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

In OCSP, is there an obligation on the responder to validate the whole chain of trust above (and across the network of trust in cross certs), or, is OCSP really JUST giving status on the particular cert in the status request?

Michael

>>> Marc Branchaud <[email-masked]> 12/08/97 12:07PM >>>
-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 5 Dec 1997 [email-masked] wrote:
> 
> >OCSP allows the relier to get the revocation information when it's needed,
> >without being subject to the CA's CRL schedule.  Because CRLs can only be
> >released periodically, they are at best a compromise solution to the needs
> >of relying parties.
> 
> Keep in mind there's still a periodicity effect in the event of caching.
> Section 2.3 of the current draft sets out the requirements.
> 

Agreed.  One of my main points, though, is that relying parties need to be
able to override any caches (& their effects) at their discretion, not the
CA's or anyone else's.

> 
> Again, I completely agree.  However, we must be cautious about overly
> constraining implementors.  We can and should standardize what's
> standarizable.
> 

Perhaps, but is it really overconstraining to make implementors create
something that works?  To make an analogy, there are some unavoidable
constraints to building an airplane -- don't make the wings cylinders,
don't make the engines face each other, etc.  Airplane implementors are
constrained to create planes that fly.  Similarly, we should constrain PKI
implementors to make programs that work.  If we are aware of any flaws in
the standards we create, we should at the very least describe them in the
documents themselves.  I would prefer not standardizing a flawed system at
all, but if there's a huge need to push forward then so be it.

  Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com 
 604-640-6227          www.xcert.com/~marcnarc/PKI/ 
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

Date: Tue, 9 Dec 1997 09:54:00 -0500
To: [email-masked], [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Encoding of INTEGER fields in PKIX certs

All,

The US Department of Defense MISSI Key Privilege Certificate Management
Working Group (KPCMWG) debated the issue of encoding large INTEGERs raised
by Dave Kemp in his original msg in this chain.  The MISSI KPCMWG came to
the same conclusion as Peter stated in the enclosed msg that X.680 must be
followed and decided to adopt the following strategy:

Rules for ASN.1 encoding INTEGER values generated by the crypto token (i.e.
hardware and/or software that implements the crypto algorithms):

IF the crypto token generates an INTEGER value in which the most significant
9 bits are all set to 0, THEN the encoding software deletes the most
significant octet from the octets to be encoded.  This rule is applied
repeatedly to the remaining octets until the most significant 9 bits are not
all set to 0.

IF the crypto token generates an INTEGER value in which the most significant
bit (MSB) is set to 1, THEN the encoding software prepends a single octet in
which every bit is set to 0 to the octets to be encoded.

Rules for ASN.1 decoding INTEGER values to be supplied to the crypto token:

1) IF the encoded value is "missing" octets (i.e. there are fewer than the
expected number of octets) THEN the decoding software ensures that the MSB
is 0 and, if so, prepends the appropriate number of octets in which every
bit is set to 0 to the decoded value to obtain the value to be supplied to
the crypto token.  If the MSB of the value encoded in the certificate is set
to 1, then an error condition is reported.

2) IF the encoded value includes an "extra" octet (i.e. the length of the
decoded value is one greater that what is expected) THEN the decoding
software ensures that every bit in the most significant octet is set to 0
and, if so, deletes the most significant octet from the decoded value to
obtain the value to be supplied to the crypto token.  If the most
significant octet contains a bit set to 1, then an error condition is reported.

Example 1:

Encoding: The software uses the crypto token to generate a 128 byte DSA
public key in which the most significant octets are "FF0B".  The
aforementioned encoding rules are applied. Because the MSB is set to 1, then
the software prepends a single octet in which every bit is set to 0 to the
octets to be encoded.  In this case, a 129 byte DSA public key is encoded in
the DSAPublicKey ASN.1 INTEGER in which the most significant octets are "00FF0B"

Decoding: The certificate-using software discovers that a 129 byte DSA
public key in which the most significant octets are "00FF0B" is encoded in
the certificate.  Because the crypto token demands a 128 byte DSA public
key, the decoding software ensures that every bit in the most significant
octet is set to 0 and deletes the most significant octet from the decoded
value to obtain the value to be supplied to the crypto token to obtain a 128
byte value in which the most significant octets are "FF0B".

Example 2:

Encoding: The software uses the crypto token to generate a 128 byte DSA
public key in which the most significant octets are "001FFF". The
aformentioned encoding rules are applied.  Because the most significant 9
bits are all set to 0, then the most significant octet is not included in
the encoding of the public key.  The aforementioned encoding rules are
applied to the remaining octets.  The most significant nine bits are neither
all set to 1 nor all set to 0, so the ASN.1 rules are satisfied.  In this
case, a 127 byte DSA public key value is encoded in the DSAPublicKey ASN.1
INTEGER in which the most significant octets are "1FFF"

Decoding: The certificate using software discovers that a 127 byte DSA
public key in which the most significant octets are "1FFF" is encoded in the
certificate.  Because the cryto token demands a 128 byte public key and
because the MSB of the decoded value is 0, then the decoding software
prepends an octet consisting of all zeroes (i.e. 00) to the decoded value to
obtain a 128 byte value in which the most significant octets are "001FFF".

Example 3:

Encoding: The software uses the crypto token to generate a 128 byte DSA
public key in which the most significant octets are "00001FFF". The
aformentioned encoding rules are applied.  Because the most significant 9
bits are all set to 0, then the most significant octet is not included in
the encoding of the public key.  The aforementioned encoding rules are
applied to the remaining octets. Because the most significant 9 bits of the
remaining octets are all set to 0, then the most significant of the
remaining octets is also not included in the encoding of the public key.
The aformentioned encoding rules are applied to the remaining octets.  The
most significant nine bits are neither all set to 1 nor all set to 0, so the
ASN.1 rules are satisfied.  In this case, a 126 byte DSA public key value is
encoded in the DSAPublicKey ASN.1 INTEGER as in which the most significant
octets are "1FFF"

Decoding: The certificate using software discovers that a 126 byte DSA
public key in which the most significant octets are "1FFF" is encoded in the
certificate.  Because the cryto token demands a 128 byte public key and
because the MSB of the decoded value is 0, then the decoding software
prepends two octets each of which consist of all zeroes to the decoded value
to obtain a 128 byte value in which the most significant octets are "00001FFF".

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 03:59 PM 12/6/97, [email-masked] wrote:
>David P. Kemp <[email-masked]> writes:
> 
>>ASN.1 INTEGERS are encoded as two's-complement numbers, which implies that if 
>>a BER-encoded value is decoded into a larger native storage value, the high 
>>bit of the encoded value will be sign-extended into the excess bits of the 
>>native value. For cryptographic purposes, it is my understanding that bignums 
>>are always the same size as the encoded values, so the issue of sign 
>>extension never arises.  (Additionally, for cryptographic algorithms using 
>>modular arithmetic with a 2^n modulus, any sign-extended bits larger than the 
>>modulus are ignored - chopped off in the modular reduction.)
>>
>>[...]
>>Since a distinguished encoding of these values is required, there MUST be an 
>>encoding convention for whether to do sign padding when MSB=1. Most of the 
>>cert examples I have seen do not do sign padding.
> 
>The only certs I've seen that very consistently do this are the ones produced 
>by Microsoft software, who encode all (well, strictly speaking about 50% on 
>average) of their INTEGERs incorrectly.  Everyone else seems to get it right 
>(this is from a random sample of 50-odd CA certs pulled from browsers and 
>things).  My ASN.1 dump program 
>http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c, will flag negative integers 
>as encoding errors and can be used to check for this problem.
> 
>>* Does a convention for sign padding of INTEGERs already exist anywhere?
> 
>Yes.  X.680 says:
> 
>  8.3.2 If the contents octets of an integer value encoding consists of more 
>        than one octet then [the first 9 bits]
>        
>        a) shall not be all ones; and
>        b) shall not be zero.
> 
>  8.3.3 The contents octets shall be a two's complement binary number equal to 
>        the integer value and consisting of [lots of stuff on how the bits are 
>        ordered].
> 
>Therefore if the high bit in the value to be encoded is set, the first octet 
>is zero; if the high bit is not set, the first octet is nonzero (in other 
>words INTEGERs have to be zero-padded).
> 
>>If not, Part 1 should be amended to specify that compliant CAs SHALL NOT 
>>generate padding 00 bytes for INTEGERs, and that verifiers SHOULD accept both 
>>padded and unpadded INTEGERs.  And I will correct the examples accordingly.
> 
>Doing this would be in violation of the BER and DER, which is unhealthy (you 
>could try asking about messing with the encoding rules on the OSS ASN.1 list, 
>but I'm pretty sure I know what they'd say).  It should be the other way 
>around, always pad 00 for integers.
> 
>(As an aside, it's a bit of a pain to work with these padding bytes because 
>your encoded integers have a 50% chance of growing by 1 byte after your 
>signature is generated.  However the standard says you have to do this, and it 
>makes sense even if it's a bit of a nuisance).
> 
>Peter.
>
>

Date: Mon, 08 Dec 1997 15:26:59 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OCSP v CRLs over HTTP

Tim:

So, when does the Internet reach one billion users?  How much bandwidth/responders would be needed?  Then, of course, how many responder certificates per CA:  1 ... infinity?

Michael

>>> Tim Moses <[email-masked]> 12/07/97 04:01PM >>>
Phill - Thank you for your response.  But, the central question remains
unanswered: how can OCSP serve a community with a size of (let's use
your number) one billion users?  According to the model that I
presented, it is not possible.  So, where is my error?  Is one of my
assumptions wrong?  In which case, which one?  Can you provide
quantitative answers, under appropriate assumptions, to the following
questions:

1. Approximately how many OCSP responders are required to serve a
community of one billion relying parties and subscribers?

2. How do the relying parties come to trust the verification keys of the
OCSP responders?

3. How do the OCSP responders obtain revocation information from the
single CA?

4. How current will the revocation information be when it is presented
to the relying parties?

Best regards.  Tim.
>
>----------
>From:  Phillip M Hallam-Baker[SMTP:[email-masked]] 
>Sent:  December 5, 1997 11:28 AM
>To:  [email-masked] 
>Subject:  Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Re Tim Moses <[email-masked]> comments concerning the alledged 'non
>scalability of OCSP'.
>
>I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>First I note that Tim does not address scalability but the relative
>performance of OCSP and the Entrust approach under his chosen set of
>assumptions.
>
>Scalability is about  whether an architecture limits the size of the problem
>that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>assumes a big enough mainframe can be purchased.
>
>OCSP supports a function call end clients make routinely: 'Is this
>certificate valid'. It allows the function 'check every certificate in my
>address book' to be supported cleanly. Unless you want to either handle CRLs
>in the client or route all traffic through a central bottleneck OCSP is the
>obvious approach.
>
>To gain perspective on scaling issues I believe we should look at a billion
>certificates or more rather than Tim's million. At least two applications
>will involve this number of certificates:
>
>    * Credit card processing
>    * Certificate based equities
>
>Both these scenarios are much smaller than systems I have previously helped
>design, ZEUS and the Web. Simulation is the only way to prove viability of
>such systems. I see OCSP as a usefull tool in meeting such challenges which
>require a 'full toolbox'.
>
>        Phill
>
>
>
>
>
>
>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

Date: Mon, 8 Dec 1997 11:07:40 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 5 Dec 1997 [email-masked] wrote:
> 
> >OCSP allows the relier to get the revocation information when it's needed,
> >without being subject to the CA's CRL schedule.  Because CRLs can only be
> >released periodically, they are at best a compromise solution to the needs
> >of relying parties.
> 
> Keep in mind there's still a periodicity effect in the event of caching.
> Section 2.3 of the current draft sets out the requirements.
> 

Agreed.  One of my main points, though, is that relying parties need to be
able to override any caches (& their effects) at their discretion, not the
CA's or anyone else's.

> 
> Again, I completely agree.  However, we must be cautious about overly
> constraining implementors.  We can and should standardize what's
> standarizable.
> 

Perhaps, but is it really overconstraining to make implementors create
something that works?  To make an analogy, there are some unavoidable
constraints to building an airplane -- don't make the wings cylinders,
don't make the engines face each other, etc.  Airplane implementors are
constrained to create planes that fly.  Similarly, we should constrain PKI
implementors to make programs that work.  If we are aware of any flaws in
the standards we create, we should at the very least describe them in the
documents themselves.  I would prefer not standardizing a flawed system at
all, but if there's a huge need to push forward then so be it.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: "John Pettitt" <[email-masked]>
To: <[email-masked]>
Subject: CyberNotary
Date: Mon, 8 Dec 1997 09:42:14 -0800

There was some discussion on the Notary issue today - anybody interested in
the subject should take at look at
http://www.abanet.org/scitech/ec/cn/home.html which is the ABA CyberNotary
home page.  There is a good summary of the legal issues and the different
views of what a notary does from jurisdiction to jurisdiction.

John

Date: Mon, 08 Dec 1997 10:12:53 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OCSP Considerations

Mike, I either agree with or have no strong opinion regarding most of your
comments, but a couple made me want to stop and think a bit more:

>>3. Both the request and the response need to be signed, at least
optionally,
>>and particularly if there is billing or other information associated.
>
>I agree, particularly with the optional part.
>
>Now, there is a converse side to this capability--unsigned responses.  Some
>may wish to take advantage of this design effect for enterprise-level
>needs.  Within an enterprise, trust is often implicit and security policy
>enforced procedurally.

I am a more than a little bit wary of handing potentially naive users and/or
system administrators this much rope, because of the possibility of a
spoofing attack. Even in those applications where nonrepudiation really
isn't an issue, providing an unsigned "yes it's valid" response to an
inquiry about a certificate essentially wipes out the entire PKI
infrastructure.  I would therefore be strongly opposed to providing unsigned
responses, unless a very convincing case can be made for it, and unless some
other mechanism (validated SSL connection) could be guaranteed.

>>5.  I don't see any particular utility in making the nonce field optional
in
>>the request -- if someone is really convinced that they don't need it,
they
>>can just fill in zeroes, without adding the additional complexity of
>>deciding whether or not it was included, and therefore whether it should
be
>>included in the response.
>
>But doing so then creates complexity and potential breakage at the backend.
>
>I presume this practice is intended to enable pre-production and caching.
>However, this then requires CAs or other trust providers to reliably
>predict the default value in the event they wish to pre-produce signed
>responses.  We could easily agree on an industry-standard default value but
>this alternative also invites the possibility that a given developer will
>get it wrong, deploy their product, and break.  This kind of thing happens
>more frequently than perhaps we all care to admit.
>
>Also, there would need to be at least some minor amount of code written on
>the client to examine the default setting and branch appropriately.  So I'd
>prefer to have this branch to a default of "no inclusion" vs. "default
>value" because it seems to me the client-end complexity is roughly
>equivalent while also providing some benefit at the  backend.

I wasn't trying to enable preproduction and/or caching of results -- far
from it.  In fact, preproduction would be right up there with unsigned
responses as something that I would have extremely strong reservations
about.  My experience is that it is extremely difficult to try to think
though all of the possible ways that someone could try to defeat the system,
and then to decide whether or not those possibilities have been handled
adequately.  Instead, I tend to reach for a bigger hammer, using solutions
that have been tried and proven repeatedly.  Using a nonce to prevent a
reply attack is one of those principles, and if that defeats the use of
preproduced results, then you might as well use an unsigned result, since
you won't known anything with any degree of certainty in any case in that
event. So let's forget about making nonce's optional -- it's too risky.
>
>>
>>7.  It would be nice, but perhaps not essential, to have something in the
>>request that specifically identifies the nonce as consisting of a message
>>digest (SHA-1 by default) of the date/time of the request concatenated
with
>>the digital signature which is being validated by this OCSP request.
>
>I can see where this might be useful for certain applications.  But I would
>not want to assert any requirement that the trust provider confirm this
>construction.  From the trust provider's point of view, the underlying
>structure of the nonce, when included, should be opaque.  Now, this does
>lead us predictably into who is attesting to what in this interaction.  If
>the CA behaves "opaquely", then it is just a status service and subjecting
>itself to one set of potential damages.  If the CA confirms the
>construction, did it just unwittingly become a digital notary?

Hmm.

Perhaps that depends on why you mean by a digital notary.

Let's try a gedanken experiment.  I have in my hand a particular transaction
(which I won't identify to you), and as part of trying to decide whether or
not to trust that transaction, I ask you the CA whether the signer's
certificate is valid.  You say either yes or no, and if you say yes and you
are wrong, I sue you for any ensuing damages, up to the limit of your CPS at
least, and probably for much more if I get a good attorney and prove
negligence.  Since I didn't identity the transaction, or tell you what the
consequences might be, you have no way to know what transaction really went
bad, or how much the damages might be. In fact, you don't even know that
there was any such signed transaction, or what the value might have been, or
when it occurred.

Now we do the same thing, but this time I identify the particular
transaction by its message digest. I still didn't tell you the estimated
value of the transaction or promise to pay you an insurance fee (because you
aren't ready to support that function yet), but at least I confirmed that
there was a particular transaction that I had in mind.  So I can't lay a
trap for you, trying over and over to catch you in an error where you
confirm a certificate as valid which shouldn't have been, and then sandbag
you by making up a transaction to fit some real world events after the fact.

How is the CA any better off in the first case than in the second?  I would
argue the converse, that even without knowing the specifics of the
transaction, the CA is better covered if the relying party who is claiming
damages has to produce a signed response that includes a nonce that matches
a particular transaction, rather than applying to any and all possible
transactions.

Even in the case where the CA or other TTP is provided the estimated value
of the transaction, and the relying party pays a percentage fee to have that
particular transaction covered, the TTP is not acting as a digital notary in
any legal sense of the term.  Instead, they are acting as an insurance
company, probing a simple errors and omission policy for a given amount of
coverage for a predetermined rate.

What they are NOT doing, that a cyber-notary or civil law notaire might do,
is provide assurances that the person whose certificate was being validated
had sufficient credit-worthiness to be good for the value of the
transaction, or that the transaction itself was well-formed and truly
represented a meeting of minds, that the relying party was in fact dealing
in good faith, etc.

So in summary, I don't see any particularly useful distinction between an
OCSP provider who merely returns certificate status, vs. one that provides
the certificate status with respect to a particular transaction, assuming
that the value or other details of the transaction aren't described.  If
anything, the inclusion of a particular transaction nonce would seem to
provide some additional protection against someone trying to sandbag the CA.

Is there some other set of liabilities or functions that you are thinking
about when you use the term "digital notary"? 

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

To: [email-masked] (David P. Kemp)
cc: [email-masked], [email-masked]
Subject: Re: Encoding of INTEGER fields in PKIX certs 
Date: Mon, 08 Dec 1997 10:49:11 -0500
From: "Charles W. Gardiner" <[email-masked]>

    I think it is better to stick with the ASN.1 rule that the most significant
bit of an INTEGER is the sign.  Since p, q, g, x, and y are positive numbers,
they should have the extra null byte if the high bit is set -- as it always is
with p and q.  Note also that some values, particularly the r part of a
signature may have a null byte in the high position and not have the next lower
bit set.  In that case the proper encoding -- even with BER -- is of a 19-byte
string, e.g. 0x0033445566.... becomes 0x021333445566....  Consequently
applications must be able to handle instances where the INTEGERS are of
different sizes from the parameters.

    To make an exception for "big numbers" (how big is big?) seems to me to be a
mistake.

Charlie Gardiner

Date: Mon, 8 Dec 1997 09:33:25 GMT
From: [email-masked] (Guang Li)
To: [email-masked]
Subject: subscribe

subscribe

thanks

From: Tim Moses <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: OCSP v CRLs over HTTP
Date: Sun, 7 Dec 1997 18:01:41 -0500

Phill - Thank you for your response.  But, the central question remains
unanswered: how can OCSP serve a community with a size of (let's use
your number) one billion users?  According to the model that I
presented, it is not possible.  So, where is my error?  Is one of my
assumptions wrong?  In which case, which one?  Can you provide
quantitative answers, under appropriate assumptions, to the following
questions:

1. Approximately how many OCSP responders are required to serve a
community of one billion relying parties and subscribers?

2. How do the relying parties come to trust the verification keys of the
OCSP responders?

3. How do the OCSP responders obtain revocation information from the
single CA?

4. How current will the revocation information be when it is presented
to the relying parties?

Best regards.  Tim.
>
>----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	December 5, 1997 11:28 AM
>To: 	[email-masked]
>Subject: 	Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Re Tim Moses <[email-masked]> comments concerning the alledged 'non
>scalability of OCSP'.
>
>I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>First I note that Tim does not address scalability but the relative
>performance of OCSP and the Entrust approach under his chosen set of
>assumptions.
>
>Scalability is about  whether an architecture limits the size of the problem
>that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>assumes a big enough mainframe can be purchased.
>
>OCSP supports a function call end clients make routinely: 'Is this
>certificate valid'. It allows the function 'check every certificate in my
>address book' to be supported cleanly. Unless you want to either handle CRLs
>in the client or route all traffic through a central bottleneck OCSP is the
>obvious approach.
>
>To gain perspective on scaling issues I believe we should look at a billion
>certificates or more rather than Tim's million. At least two applications
>will involve this number of certificates:
>
>    * Credit card processing
>    * Certificate based equities
>
>Both these scenarios are much smaller than systems I have previously helped
>design, ZEUS and the Web. Simulation is the only way to prove viability of
>such systems. I see OCSP as a usefull tool in meeting such challenges which
>require a 'full toolbox'.
>
>        Phill
>
>
>
>
>
>
>

From: [email-masked]
Date: Sat, 06 Dec 1997 23:40:51 -0700
To: [email-masked] (David P. Kemp), [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

At 03:52 PM 12/5/97 -0500, David P. Kemp wrote:
>> On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
>> > 
>> > OCSP supports a function call end clients make routinely: 'Is this
>> > certificate valid'.
>
>I thought we had already established that this was NOT the goal of
>OCSP.  OCSP was presented as merely answering the question "Has this
>certificate been revoked?", the example given being the need to cut off
>people who demonstrate the danger of relying on MS Authenticode as an
>applet privilege management mechanism.  (Silencing the messengers,
>rather than fixing the problem, as it were.)

Dave,

Our prior discussions suffer from bandwidth starvation.  It is true that if
one were to quickly summarize OCSP, one can say it answers the question you
pose.  I've said or wrote the same thing several times in efforts to focus
and clarify discussions.  However, there are a few things to keep in mind
with regard to the development of a consensus on what OCSP is and should be:

1. From August until about the middle of November there were a total of
about five public comments on the original Part 2 text.

2. That text identified certificate validation and expiration responses in
addition to certificate revocation responses.

3. In the last three weeks there's been a tremendous surge in list traffic
regarding OCSP, on the order of 80 or so messages.

4. So I would think it's fair to say that we had established, even in the
-01 draft that recently emerged this past Friday, may fail to fully
accomodate the growing body of consensus on OCSP.  I would expect our work
next week to take us much closer towards an acceptable draft.

Mike

From: [email-masked]
Date: Sat, 06 Dec 1997 23:47:50 -0700
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP

At 04:42 PM 12/5/97 -0500, Carlisle Adams wrote:
>Hi Marc,
> . . .
>>The flaw is that the decision of when to release new revocation
>>information rests with the CA.  In other words, a relying party who needs
>>up-to-date revocation information in a CRL-only environment has to wait
>>for the next CRL to be published.  The relier has no power to influence
>>the CA into releasing revocation information earlier.
> . . . 
>Unfortunately, your "slightly different perspective" is no longer
>supported in the latest OCSP revision.  The OCSP response message now
>contains "produced_at" and "expires_on" fields.
>. . .
>So, it turns out that the CA still controls when new revocation
>information is released.

To which I would add: Including those operating autonomously within an
enterprise, using Internet-based technology.

A reliable decision regarding the revocation state of a certificate should
be made with reference to the entity that issued the certificate in the
first place.  This reference can established by direct signature or
indirectly, via agreement between a Trust Provider and a Certification
Authority.  In either case, relying parties have an avenue of recourse
should damages be incurred.

Mike

Date: Sat, 6 Dec 1997 23:36:27 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: Peter Whittaker <[email-masked]>
Cc: "'IETF PKIX'" <[email-masked]>, "'Harald T Alvestrand'" <[email-masked]>, "'David P. Kemp'" <[email-masked]>, Sharon Boeyen <[email-masked]>, Carlisle Adams <[email-masked]>, Tim Moses <[email-masked]>, "'Phillip H. Griffin'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: Re: Character sets in PKIX and X.509 (RE: [IETF-PKIX] Objections to IPKI3CMP charset handling)

On Fri, 5 Dec 1997, Peter Whittaker wrote:

> Harald's post lead to a debate and exchange of information, mostly
> off-line, that came to involve Bancroft Scott, the ISO ASN.1 Rapporteur
> (chair of the ASN.1 WG), Hoyt Kesterson, the ISO X.500 Rapporteur,
> Harald, Phillip Griffin, Carlisle Adams, and others.

I am the editor, not the Rapporteur, but am certain that John
Larmouth, the Rapporteur, entirely agrees with me on this issue.
 
> One issue that has been raised about the use of UTF8String is the
> question of what level of ASN.1 support it requires ('88, '94, '9x with
> x > 4, '2x?), and how it affects current ASN.1 compilers.   UTF8String
> may be the right thing to do, but may pose challenges in this area
> (compounding the problem of widespread use of ASN.1 1988 throughout IETF
> work, despite the superiority and clarity of ASN.1 1994).
> 
> Thoughts, comments, objections?

I am for the use of ASN.1:1998 which has been approved of ISO and is
being voted on this week by ITU-T with almost certainty that it will pass
since there has not been even a single objection to ASN.1:1998 which is
basically a merge of ASN.1:1994 with the corrigenda and amendments issued
since 1994, plus addition of UTF8String.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date:         Wed, 3 Dec 1997 13:36:29 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Laska <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]
Status:

-----Original Message-----
From: Phillip M Hallam-Baker <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 03, 1997 11:10 AM
Subject: Re: [IETF-PKIX] OCSP using SSL/https

>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>
>Are we talking 'instead of' or 'optionally'?

Sorry. By "permit" I meant "optionally". Maybe "...instead of" made that
ambiguous.

>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.
>
>            Phill
>

I agree that SSL and/or other external means should be mentioned as
alternative means of authentication in OCSP. I had noticed that the
language in PKIX-3 was more along these lines (more flexible) rather
than requiring any of the messages to be signed. It would be nice to
have the other PKIX specs such as OCSP be consistent.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [email-masked]
==========================================

Date:         Wed, 3 Dec 1997 09:09:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

In both the financial and defense communities, this is an important
distinction to make.  Making the extension non-critical means that I can
ignore this distinction, and that is not desirable.

Dave S.

Sharon Boeyen wrote:
>
> There are some pretty simple uses of the keyUsage extension such as the
> difference between an encryption and digital signature key and we make
> heavy use of this today. I'd have no problem making the extension
> non-critical if that's more appropriate.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[email-masked]       Tel: (613) 247-3181
> http://www.entrust.com          Fax: (613) 247-3690
>          Orchestrating Enterprise Security
>
> >----------
> >From:  Bob Jueneman[SMTP:[email-masked]]
> >Sent:  December 2, 1997 1:12 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
> >
> >Sharon and David,
> >
> >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> >as a result of my confusion and exasperation in trying to sort though all of
> >these different issues.  But if we can't agree on some relatively simple
> >meaning, I submit that using the fields will actually be WORSE than
> >deprecating them, for one person will think that they mean one thing, and
> >another person will interpret them differently.
> >
> >What good does it do to mark an attribute as critical, if the semantics are
> >as undefined or ambiguous as these are?
> >
> >And to bring up a somewhat different ubject that I mentioned before, but
> >never got closure on, I think that it is completely UNACCEPTABLE to say that
> >if some particular application does not have, understand, or chose to
> >implement a security policy, it should be free to simply ignore the critical
> >marking on a Policy OID constraint. This simply turns the definition of
> >critical on its head.  The critical usage is provided primarily to protect
> >the CA and/or the subject of the certificate from unreasonable reliance on
> >the certificate, and to provide a means for IT administrators to centrally
> >control what kinds of policies are to be enforced.
> >
> >Bob
> >
> >>Bob,
> >>
> >>First let me say that I highly respect all of the opinions that I've
> >>received.
> >>
> >>The key usage flags do play a useful role.  As a single example, they
> >>allow me to restrict use of my RSA key to either digital signature or
> >>key encipherment, but never both.  There is enough importance in this
> >>single role to warrant the extension be made "critical" when used.
> >>
> >>If this thread has proved anything, it's at least shown that there is no
> >>universal interpretation of non-repudiation or how to best implement
> >>it.  I think we should leave it up to individual communities of users to
> >>determine how to best implement this in their situation because there is
> >>not one right answer.  Certificate policies are going to play a mighty
> >>important role.
> >>
> >>Dave Simonetti
> >>
> >>Bob Jueneman wrote:
> >>>
> >>> >I, in turn, propose that digitalSignature is the mechanism.  If
> >>> >nonRepudiation is turned on, then the non-repudiation service is
> >>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
> >>> >provided.  Why can't it be this simple?
> >>> >
> >>> >Dave Simonetti
> >>> >
> >>> >
> >>> I'd like to think that those who have ventured an opinion in this area
> >are
> >>> reasonably knowledgable about the subject.
> >>>
> >>> But if we cannot agree as what these bits mean, it is not likely that
> >either
> >>> CAs or client software will understand or correctly implement the
> >semantics,
> >>> no matter what the bottom line is.
> >>>
> >>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
> >>> they seem to be doing more harm than good.
> >>>
> >>> Can someone make a case for why we should bother with them, if there is
> >this
> >>> much confusion about their meaning?
> >>>
> >>> Bob
> >

Date:         Wed, 3 Dec 1997 11:03:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
To: [email-masked]
Status:

Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Wed, 3 Dec 1997 10:10:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
Comments: To: [email-masked]
To: [email-masked]
Status:

In the case where a central repository services multiple CA's for OCSP, then that repository should sign (timestamp?) the response.  I'm not sure whether this will be a "tightly couple" relationship as some have suggested.  The CRL's used by the repository should, of course be signed by the original issuing CA.  The repository may even archive all of these CRL's issued and their signatures.

Michael
>>> Tim Moses <[email-masked]> 12/03/97 09:03AM >>>
Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Wed, 3 Dec 1997 09:55:08 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Laska <[email-masked]>
Subject:      [IETF-PKIX] OCSP using SSL/https
To: [email-masked]
Status:

It seems that the main purpose of having signed responses in OCSP
is to authenticate the responder.

Would it be useful, and perhaps simplify things, to permit SSL/https
to be used in the protocol instead of requiring signed responses over
http?

I am assuming here that the responder is tightly coupled to the CA.
If the responder's site certificate is revoked then the responder
itself would have to get disabled or updated by the CA.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [email-masked]
==========================================

Date:         Wed, 3 Dec 1997 14:00:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]
Status:

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent:  Wednesday, December 03, 1997 1:14 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>>reply in along sequence of requests.".
>>
>>If each object is not signed, or each data stream signed after the stream
>is created (thus becoming one signed object), then SSL by itself does not
>provide any evidence of what was sent by whom unless both parties retain
>complete records of all the activity within the SSL session from time of
>mutual authentication through the end of the session.
>
>
>What you appear to be saying is that SSL does not provide non-repudiation.
>This is of course a major problem. It is not necessarily a critical one
>(e.g. both sender and reciever under same authority hence non-repudiation
>moot).

My thesaurus entry for "moot" says that the following are synonyms:
controversial, contestable, debatable, arguable, disputable,
questionable, dubious, disputed, doubtful.

I'm having trouble figuring out what exactly you mean by your last
sentence above.  Are you suggesting that if the sender and receiver are
under the same CA then non-repudiation cannot really be achieved?  Any
clarification would be helpful...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 3 Dec 1997 14:04:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]
Status:

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent:  Wednesday, December 03, 1997 11:55 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.

This sounds a bit dangerous to me.  It may be too easy for developers to
use this as an excuse for skipping the authentication step most of the
time...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 3 Dec 1997 13:14:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: Mike Smith <[email-masked]>
To: [email-masked]
Status:

>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>reply in along sequence of requests.".
>
>If each object is not signed, or each data stream signed after the stream
is created (thus becoming one signed object), then SSL by itself does not
provide any evidence of what was sent by whom unless both parties retain
complete records of all the activity within the SSL session from time of
mutual authentication through the end of the session.

What you appear to be saying is that SSL does not provide non-repudiation.
This is of course a major problem. It is not necessarily a critical one
(e.g. both sender and reciever under same authority hence non-repudiation
moot).

This is why I don't like SSL for this application, I certainly don't see it
as being viable as the sole means of providing authentication. It MAY be
sufficiently useful in certain situations to make it an option along with
other external means of establishing authenticity.

        Phill

Date:         Wed, 3 Dec 1997 08:23:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

Andreas,

I think your proposal of guidelines and best practices is a good one and
probably about as far as we could go in this area. There are 2 different
sets of requirements, both of which need to be accommodated. In one case
we want the names to be simple and easily retreivable and in the other
case we need to address both PKI-specific repositories and repositories
that are shared directories with other applications.

There are some guidelines that clearly fit into both environments, such
as recommending that only "standard" attribute types be used in names
and possibly recommending which ones (increasing the likelihood that
they can be retrieved), use of numeric values to disambiguate (although
3-4 years ago people would have thrown up their arms in opposition to
that I think that has changed along with the realization that these
don't normally get displayed to end-users anyway) ... just a few early
thoughts.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Andreas Berger[SMTP:[email-masked]]
>Sent:  December 3, 1997 6:24 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Question about SubjectAltNames
>
>Bob Jueneman wrote:
>>
>> >Phil,
>> >
>> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
>> >require "Distinguished Names" to be "Directory Names"?
>
>To my opinion, the X.509 certificates were intended to authenticate
>users for access of the X.500 directory system. Certificates must
>contain an acceptable name for the application in question. Therefore,
>distinguished names for the X.500 are the appropriate namespace for this
>application. For other applications there may well be other namespaces
>acceptable.
>
>> 1.  Does the DN in a certificate have to be globally unambiguous, so that
>>no
>> two people with the same common name could possibly be confused?
>>
>> Answering that question "yes" will force name subordination to be applied
>> everywhere, even in cases where the obvious ways of doing it (geopolitical
>> name qualification, down to the street address level) are either
>> unacceptable (e.g., due to privacy concerns), or not workable (because the
>> state or locality entities have not bought into the system, or because the
>> natural domain of a CA (e.g., an ISP) is not confined by regional
>> boundaries. This in turn tends to force the use of multiple RDNs as the
>>leaf
>> component, in order to avoid changing someone's common name while still
>> maintaining global unambiguity.
>>
>> Answering the question "no" seems (at least on the surface) to
>>significantly
>> weaken the legal status of a digital signature for purposes of commerce,
>> unless some other name mechanism (e.g., a unique account number) is
>>included
>> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
>> system was somewhat cavalier about the assignment of names -- in fact it
>> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
>> mark, whether unique or not.  But more recently, the issue of who owns
>> domain names has become increasingly contentious. Whereas at one time Apple
>> the computer company and Apple the music company had little to do with each
>> other, today the separation is much less clean cut.  Even today, if there
>> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no
>>significant
>> legal confusion is likely to result. But who can say what will happen
>> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
>> have an e-mail account with CompuServe. or some other domestic ISP).
>
>We don't need a global unique name for users in a certificate in the way
>you described it. We have to be very careful not to mix the attributes
>of a person (Name, Address...) with the requirement of the technical
>"name". That is a problem that X.500 created with typed RDNs.
>
>For electronic commerce applications (or legally binding transactions)
>we need a name that is acceptable to the other party. This acceptance
>depends largely on the trustworthiness of the issuer of the certificate
>and defined measures to get hold of the physical person in case a
>dispute arises. Therefore, it should be enough to identify an end entity
>relativly unique to the issuer. And this identification may well be made
>by a number or some other means. People may have several identities in
>this respect - and nobody will care unless the resolution of these
>pseudonymity is required.
>
>> 2. Does the use of X.509 envision at least the possibility of a globally
>> interconnected directory to be used for certificate retrieval and perhaps
>> CRL retrieval?  If so, doesn't require the assumption that the DN in the
>> certificate is one to one with respect to the DIT?  If we don't start out
>> deploying certificates with that assumption in mind, will it not prove to
>>be
>> impossible to migrate to such a scheme later on?
>
>If an application accepts simple DNs (such as CN=High Speed Modem) it
>has to have some knowledge on how to retrieve such names from a
>directory (if a directory is employed at all). I would not want to make
>very piece of equiment in a corporate network "worldwide unique". And
>yes, this certificate would have no meaning outside the corporate
>network, but is this really necessary?
>
>For the (relativly simple) operations needed for retrieving security
>attribute from directories (i.e. find a certificate for a person,
>retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
>FINGER or something similar). We do not need a very complex "directory
>service" for these operations.
>
>But I agree that we should develop some guidelines for creating DNs. Or
>at least write down what is already there (see the NT4 LDAP server,
>verisign certificates, X.400 mailaddresses an so on). Perhaps we can
>converge on an accepted practice. We should stress the point that these
>DNs are automatically resolvable to machine/service names (on the
>internet or other) so that applications (e.g. eMail clients or payment
>systems) can access a direcory service to retrieve additional
>information desired.
>
>> 3.  And speaking of schemes, what schema is to be assumed for acceptable
>> components of a DN in a certificate, if we are to ever move toward a common
>> directory?  At present, I am not aware of any definition of what
>>constitutes
>> allowable, deprecated, or not allowable attribute types within a PKIX DN,
>> yet if we ever expect that the current islands of LDAP usage will ever
>>merge
>> into archipelagoes, and finally continents, some agreement on acceptable
>> schemas will have to be enforced.  Should we just leave it up to the public
>> CAs like VeriSign to say what kinds of DN attributes they will support, and
>> let all of the directory providers eat dirt?  Or vice versa?
>I doubt that we will get a common directory for each and every entity on
>the planet. Companies will severly restrict access to corporate
>directories and even I personally would not want to publish a massive
>amount of information globally.
>
>> I believe that the working consensus is still the same that it was in the
>> PEM days -- that we should strive to be interoperable with X.500
>> directories, but should not presume their existence to be either necessary
>> or sufficient.
>Agreed. But what I would like to see is the seperation of the DN as a
>name for an entry from identity information needed in certificates. The
>DN for an entry is just a name (like an URL or bettern URN) that - in my
>opionion - may be changed as often. What matters is the content of the
>entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
>to the application, it should put these into the certificate as well -
>but not as part of the DN.
>
>Andreas
>--
> Andreas Berger, GMD - German National         eMail:
>[email-masked]
> Research Center for Information Technology,
> Institute for Telecooperation Technology      Tel:   +49-6151-869-715
> Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   +49-6151-869-704
>

Date:         Wed, 3 Dec 1997 11:55:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]
Status:

>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill

Date:         Wed, 3 Dec 1997 08:36:06 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

Maybe I'm missing something with the X.500 compatibility issue and X.509 certifcates.  I thought that, with version 3, X.500 is just one schema tht the X.509v3 certificate processing systems should be "backward compatible" with.

Michael

>>> Andreas Berger <[email-masked]> 12/03/97 04:24AM >>>
Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas

Date:         Wed, 3 Dec 1997 08:34:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

As usual, Bob, I find myself agreeing with your statements.

A certificate is issued under a certain set of authority policies.  If someone wishes to rely on a certificate issued under those policies, then the software they use must be able to process all of the critical extensions established under that policy or not honor the certificate.

If someone does accept a certificate or signature issued with critical extensions that are ignored or interpreted other than the intent of the issuing CA, then, it is my belief, the reliant party (and, possibly the entity that modified the code to accept or ignore the critical extensions) has just relieved the CA of any and all liability regarding that critical extension and, quite possibly, the whole certificate's issued purpose.

Michael

>>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
Sharon and David,

My tongue in cheek suggestion that we deprecate the keyUsage field was made
as a result of my confusion and exasperation in trying to sort though all of
these different issues.  But if we can't agree on some relatively simple
meaning, I submit that using the fields will actually be WORSE than
deprecating them, for one person will think that they mean one thing, and
another person will interpret them differently.

What good does it do to mark an attribute as critical, if the semantics are
as undefined or ambiguous as these are?

And to bring up a somewhat different ubject that I mentioned before, but
never got closure on, I think that it is completely UNACCEPTABLE to say that
if some particular application does not have, understand, or chose to
implement a security policy, it should be free to simply ignore the critical
marking on a Policy OID constraint. This simply turns the definition of
critical on its head.  The critical usage is provided primarily to protect
the CA and/or the subject of the certificate from unreasonable reliance on
the certificate, and to provide a means for IT administrators to centrally
control what kinds of policies are to be enforced.

Bob

>Bob,
>
>First let me say that I highly respect all of the opinions that I've
>received.
>
>The key usage flags do play a useful role.  As a single example, they
>allow me to restrict use of my RSA key to either digital signature or
>key encipherment, but never both.  There is enough importance in this
>single role to warrant the extension be made "critical" when used.
>
>If this thread has proved anything, it's at least shown that there is no
>universal interpretation of non-repudiation or how to best implement
>it.  I think we should leave it up to individual communities of users to
>determine how to best implement this in their situation because there is
>not one right answer.  Certificate policies are going to play a mighty
>important role.
>
>Dave Simonetti
>
>Bob Jueneman wrote:
>>
>> >I, in turn, propose that digitalSignature is the mechanism.  If
>> >nonRepudiation is turned on, then the non-repudiation service is
>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>> >provided.  Why can't it be this simple?
>> >
>> >Dave Simonetti
>> >
>> >
>> I'd like to think that those who have ventured an opinion in this area
are
>> reasonably knowledgable about the subject.
>>
>> But if we cannot agree as what these bits mean, it is not likely that
either
>> CAs or client software will understand or correctly implement the
semantics,
>> no matter what the bottom line is.
>>
>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>> they seem to be doing more harm than good.
>>
>> Can someone make a case for why we should bother with them, if there is
this
>> much confusion about their meaning?
>>
>> Bob

Date:         Wed, 3 Dec 1997 09:27:37 -0500
Reply-To: Judie Mulholland <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Judie Mulholland <[email-masked]>
Subject:      [IETF-PKIX] ITU recommendations v. IETF drafts
To: [email-masked]
Status:

i'd like to know if anyone on this list has seen/read the following
document:

[X.509] Recommendation X.509 (11/93) - Information technology - Open
Systems Interconnection - The directory: Authentication framework
Posted: 1996-01-29

http://www.itu.int/itudoc/itu-t/rec/x/x500up/x509_27505.html

in order to get access this paper, the reader must pay 20 swiss francs
(i.e., pay first, read later) and before doing so, i'd like to know the
following:

1) if someone could explain to me what the differences are between the
docs that are being published by the ITU and the ones that are being
produced under the auspices of the IETF.

2) judging by the publication date, it seems that the material must be
grossly out of date? am i correct in this assumption? if yes, where and
what should i be looking at? if not, is it worth paying for?

tia

/judie

ps

oops, i forgot to mention that i am doing my disseration in the area of
e-commerce and rights management. in particular, i am focusing on the
implementation of certificate authorities and digital signatures in the
state of florida.

Ph.D. Candidate                         Voice: (850) 644-5775
School of Information Studies           Fax:   (850) 644-6253
Florida State University                Email: [email-masked]
Tallahassee, FL 32306                   [email-masked]

Date:         Wed, 3 Dec 1997 11:10:57 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] X.509 certificates and RADIUS
To: [email-masked]
Status:

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     All,

        Just a heads up that I submitted a draft to the RADIUS WG a few
     weeks back which describes a mechanism to carry X.509 certificates
     within a RADIUS message. Although it was sent to the secretariat well
     over a week prior to the deadline, it is still not in the archives.

        I am sending the draft within this message (I do appologize for
     readers who do not have mime capability).

        I, unfortunately, cannot discuss this draft in DC since the PKIX
     meetings conflict with a WG that I chair and another that I have 3
     drafts pending :(

        Comments would be appreciated,

        PatC
Content-Type: text/basic; name="radx509.txt"
Content-Transfer-Encoding: 7bit
Content-Description: MS-DOS text file
Content-Disposition: attachment; filename="radx509.txt"

Attachment converted: Ishmael:radx509.txt (TEXT/R*ch) (00004EB7)

Date:         Wed, 3 Dec 1997 10:17:57 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: [email-masked]
To: [email-masked]
Status:

In your response, SSL is said "would avoid the need to sign each HTTP/1.1
reply in along sequence of requests.".

If each object is not signed, or each data stream signed after the stream is created (thus becoming one signed object), then SSL by itself does not provide any evidence of what was sent by whom unless both parties retain complete records of all the activity within the SSL session from time of mutual authentication through the end of the session.

It seems that retaining object signing for each request or each batch of requests then lets each signed object stand by itself or either party.

Michael
>>> Phillip M Hallam-Baker <[email-masked]> 12/03/97 09:55AM >>>
>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill

Date:         Wed, 3 Dec 1997 08:26:51 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

Andreas Berger wrote:
>
> Bob Jueneman wrote:
> >
> > >Phil,
> > >
> > >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> > >require "Distinguished Names" to be "Directory Names"?
>
> To my opinion, the X.509 certificates were intended to authenticate
> users for access of the X.500 directory system. Certificates must
> contain an acceptable name for the application in question. Therefore,
> distinguished names for the X.500 are the appropriate namespace for this
> application. For other applications there may well be other namespaces
> acceptable.

Agreed. There are communities, such as Visa/MC's SET that may wish to
restrict the namespace...

  Name ::= CHOICE { -- only one possibility for now --
                       distinguishedName RDNSequence }

  RDNSequence ::= SEQUENCE SIZE (1..5) OF RelativeDistinguishedName

  RelativeDistinguishedName ::= SET SIZE(1) OF AttributeTypeAndValue

to a proper subset of what's defined for directory names. This SET
ASN.1 was so restricted to allow implementors to make more efficient
allocations and to more easily detect, when decoding, otherwise valid
Certificates that are not valid for the purposes of a SET application.

Note that these definitions produce encodings that are valid for use
in the directory, but indicate that not all directory DNs are valid
for use in SET.

>
> > 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> > two people with the same common name could possibly be confused?
> >
> > Answering that question "yes" will force name subordination to be applied
> > everywhere, even in cases where the obvious ways of doing it (geopolitical
> > name qualification, down to the street address level) are either
> > unacceptable (e.g., due to privacy concerns), or not workable (because the
> > state or locality entities have not bought into the system, or because the
> > natural domain of a CA (e.g., an ISP) is not confined by regional
> > boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> > component, in order to avoid changing someone's common name while still
> > maintaining global unambiguity.
> >
> > Answering the question "no" seems (at least on the surface) to significantly
> > weaken the legal status of a digital signature for purposes of commerce,
> > unless some other name mechanism (e.g., a unique account number) is included
> > somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> > system was somewhat cavalier about the assignment of names -- in fact it
> > doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> > mark, whether unique or not.  But more recently, the issue of who owns
> > domain names has become increasingly contentious. Whereas at one time Apple
> > the computer company and Apple the music company had little to do with each
> > other, today the separation is much less clean cut.  Even today, if there
> > exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> > legal confusion is likely to result. But who can say what will happen
> > tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> > have an e-mail account with CompuServe. or some other domestic ISP).
>
> We don't need a global unique name for users in a certificate in the way
> you described it. We have to be very careful not to mix the attributes
> of a person (Name, Address...) with the requirement of the technical
> "name". That is a problem that X.500 created with typed RDNs.
>
> For electronic commerce applications (or legally binding transactions)
> we need a name that is acceptable to the other party. This acceptance
> depends largely on the trustworthiness of the issuer of the certificate
> and defined measures to get hold of the physical person in case a
> dispute arises. Therefore, it should be enough to identify an end entity
> relativly unique to the issuer. And this identification may well be made
> by a number or some other means. People may have several identities in
> this respect - and nobody will care unless the resolution of these
> pseudonymity is required.
>
> > 2. Does the use of X.509 envision at least the possibility of a globally
> > interconnected directory to be used for certificate retrieval and perhaps
> > CRL retrieval?  If so, doesn't require the assumption that the DN in the
> > certificate is one to one with respect to the DIT?  If we don't start out
> > deploying certificates with that assumption in mind, will it not prove to be
> > impossible to migrate to such a scheme later on?
>
> If an application accepts simple DNs (such as CN=High Speed Modem) it
> has to have some knowledge on how to retrieve such names from a
> directory (if a directory is employed at all). I would not want to make
> very piece of equiment in a corporate network "worldwide unique". And
> yes, this certificate would have no meaning outside the corporate
> network, but is this really necessary?
>

Note that when I cited these CN examples, I did so in the more limited
context of augmenting the DN using the *AltName extensions. But for use
outside of directory applications, I agree that very simple DNs may be
appropriate for some groups of users.

> For the (relativly simple) operations needed for retrieving security
> attribute from directories (i.e. find a certificate for a person,
> retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
> FINGER or something similar). We do not need a very complex "directory
> service" for these operations.
>
> But I agree that we should develop some guidelines for creating DNs. Or
> at least write down what is already there (see the NT4 LDAP server,
> verisign certificates, X.400 mailaddresses an so on). Perhaps we can
> converge on an accepted practice. We should stress the point that these
> DNs are automatically resolvable to machine/service names (on the
> internet or other) so that applications (e.g. eMail clients or payment
> systems) can access a direcory service to retrieve additional
> information desired.
>

I'd like to see applications free to use the DN and extensions as they
perceive best suits their needs.

> > 3.  And speaking of schemes, what schema is to be assumed for acceptable
> > components of a DN in a certificate, if we are to ever move toward a common
> > directory?  At present, I am not aware of any definition of what constitutes
> > allowable, deprecated, or not allowable attribute types within a PKIX DN,
> > yet if we ever expect that the current islands of LDAP usage will ever merge
> > into archipelagoes, and finally continents, some agreement on acceptable
> > schemas will have to be enforced.  Should we just leave it up to the public
> > CAs like VeriSign to say what kinds of DN attributes they will support, and
> > let all of the directory providers eat dirt?  Or vice versa?
> I doubt that we will get a common directory for each and every entity on
> the planet. Companies will severly restrict access to corporate
> directories and even I personally would not want to publish a massive
> amount of information globally.
>
> > I believe that the working consensus is still the same that it was in the
> > PEM days -- that we should strive to be interoperable with X.500
> > directories, but should not presume their existence to be either necessary
> > or sufficient.
> Agreed. But what I would like to see is the seperation of the DN as a
> name for an entry from identity information needed in certificates. The
> DN for an entry is just a name (like an URL or bettern URN) that - in my
> opionion - may be changed as often. What matters is the content of the
> entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
> to the application, it should put these into the certificate as well -
> but not as part of the DN.
>

I agree that striving to be interoperable with directories is still the
goal. I think that a common ASN.1 structure helps to make this possible.
I almost agree with the last statement. While it is true that extensions
can be used to augment the DN, I support the idea that applications be
able to create their own attributes and include them in the DN, rather
than be forced into burying these attributes in the "octet holes"
components of extensions, where everything is an OCTET STRING.

> Andreas
> --
>  Andreas Berger, GMD - German National         eMail:
> [email-masked]
>  Research Center for Information Technology,
>  Institute for Telecooperation Technology      Tel:   +49-6151-869-715
>  Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   +49-6151-869-704

Phil Griffin

Date:         Wed, 3 Dec 1997 08:09:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

There are some pretty simple uses of the keyUsage extension such as the
difference between an encryption and digital signature key and we make
heavy use of this today. I'd have no problem making the extension
non-critical if that's more appropriate.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  December 2, 1997 1:12 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob
>
>>Bob,
>>
>>First let me say that I highly respect all of the opinions that I've
>>received.
>>
>>The key usage flags do play a useful role.  As a single example, they
>>allow me to restrict use of my RSA key to either digital signature or
>>key encipherment, but never both.  There is enough importance in this
>>single role to warrant the extension be made "critical" when used.
>>
>>If this thread has proved anything, it's at least shown that there is no
>>universal interpretation of non-repudiation or how to best implement
>>it.  I think we should leave it up to individual communities of users to
>>determine how to best implement this in their situation because there is
>>not one right answer.  Certificate policies are going to play a mighty
>>important role.
>>
>>Dave Simonetti
>>
>>Bob Jueneman wrote:
>>>
>>> >I, in turn, propose that digitalSignature is the mechanism.  If
>>> >nonRepudiation is turned on, then the non-repudiation service is
>>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>>> >provided.  Why can't it be this simple?
>>> >
>>> >Dave Simonetti
>>> >
>>> >
>>> I'd like to think that those who have ventured an opinion in this area
>are
>>> reasonably knowledgable about the subject.
>>>
>>> But if we cannot agree as what these bits mean, it is not likely that
>either
>>> CAs or client software will understand or correctly implement the
>semantics,
>>> no matter what the bottom line is.
>>>
>>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>>> they seem to be doing more harm than good.
>>>
>>> Can someone make a case for why we should bother with them, if there is
>this
>>> much confusion about their meaning?
>>>
>>> Bob
>

Date:         Wed, 3 Dec 1997 08:01:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

Bob

Shades of NADF all over again - isn't it!

At the Washington PKIX meeting, one of the topics which will be
discussed is whether or not the PKIX WG should define the minimum
requirements of a schema for support in the directory environment. If
that work does progress, I personally do not expect it to be a full
directory schema definition (primarily because in many environments the
PKI schema components need to fit into a larger schema which addresses
multiple applications), however I believe there is utility in defining
the minimum requirements for PKI purposes. I haven't given a lot of
thought yet to what requirements of names there might be but  we'd be
defining this schema with directory deployment so that probably would
dictate a general direction for that piece of work.

Several people have indicated over the past 6 months or so that they
think
some schema work for PKIX would be useful and help move us forward in
the area of interoperability, so I personally suspect this work item
will progress (of course there's always the question of whether it
belongs in the PKIX WG or elsewhere in the IETF). My opinion is that it
should be tackled in the PKIX WG because that's where the understanding
of the requirements is.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  December 2, 1997 4:31 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Question about SubjectAltNames
>
>>Phil,
>>
>>I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
>>require "Distinguished Names" to be "Directory Names"?
>>
>>I am of the opinion that X.509 is not tied inextricably to X.500, and
>>that Authorities and Relying Parties should be free to use the
>>SEQUENCE OF RelativeDistinguishedName syntax (and the associated
>>nameConstraints extension) in any way that makes sense to them.  Under
>>this scenario, it would be completely legal to have a subjectName of
>>"CN = High Speed Modem".
>>
>>Unfortunately, this example is not a Directory Name, because it is
>>not unique identifier within the DIT.  Many user communities (such as
>>MISSI) will restrict usage to Directory Names because that convention
>>makes many things simpler.  But does X.509 require this restriction?
>>
>>Consensus, anyone?
>
>David, this is a question which has plagued us since the PEM days. In
>addition to the technical ramifications (which were some of the reasons why
>the spki group developed their own agenda), it has legal ramifications as
>well.
>
>I believe the appropriate questions to ask are:
>
>1.  Does the DN in a certificate have to be globally unambiguous, so that no
>two people with the same common name could possibly be confused?
>
>Answering that question "yes" will force name subordination to be applied
>everywhere, even in cases where the obvious ways of doing it (geopolitical
>name qualification, down to the street address level) are either
>unacceptable (e.g., due to privacy concerns), or not workable (because the
>state or locality entities have not bought into the system, or because the
>natural domain of a CA (e.g., an ISP) is not confined by regional
>boundaries. This in turn tends to force the use of multiple RDNs as the leaf
>component, in order to avoid changing someone's common name while still
>maintaining global unambiguity.
>
>Answering the question "no" seems (at least on the surface) to significantly
>weaken the legal status of a digital signature for purposes of commerce,
>unless some other name mechanism (e.g., a unique account number) is included
>somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
>system was somewhat cavalier about the assignment of names -- in fact it
>doesn't matter if you sign your checks as "Santa Claus" -- it is still your
>mark, whether unique or not.  But more recently, the issue of who owns
>domain names has become increasingly contentious. Whereas at one time Apple
>the computer company and Apple the music company had little to do with each
>other, today the separation is much less clean cut.  Even today, if there
>exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
>legal confusion is likely to result. But who can say what will happen
>tomorrow? On the Internet, no one knows you live in Uganda (at least if you
>have an e-mail account with CompuServe. or some other domestic ISP).
>
>2. Does the use of X.509 envision at least the possibility of a globally
>interconnected directory to be used for certificate retrieval and perhaps
>CRL retrieval?  If so, doesn't require the assumption that the DN in the
>certificate is one to one with respect to the DIT?  If we don't start out
>deploying certificates with that assumption in mind, will it not prove to be
>impossible to migrate to such a scheme later on?
>
>3.  And speaking of schemes, what schema is to be assumed for acceptable
>components of a DN in a certificate, if we are to ever move toward a common
>directory?  At present, I am not aware of any definition of what constitutes
>allowable, deprecated, or not allowable attribute types within a PKIX DN,
>yet if we ever expect that the current islands of LDAP usage will ever merge
>into archipelagoes, and finally continents, some agreement on acceptable
>schemas will have to be enforced.  Should we just leave it up to the public
>CAs like VeriSign to say what kinds of DN attributes they will support, and
>let all of the directory providers eat dirt?  Or vice versa?
>
>I believe that the working consensus is still the same that it was in the
>PEM days -- that we should strive to be interoperable with X.500
>directories, but should not presume their existence to be either necessary
>or sufficient.
>
>But that still leaves us a lot of questions to answer.
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are tring to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross the chasm in two leaps."
>

Date:         Wed, 3 Dec 1997 12:24:02 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas
--
 Andreas Berger, GMD - German National         eMail:
[email-masked]
 Research Center for Information Technology,
 Institute for Telecooperation Technology      Tel:   +49-6151-869-715
 Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   +49-6151-869-704

Date: Sat, 06 Dec 1997 15:52:15 -0800
From: Deepak Nadig <[email-masked]>
Reply-To: [email-masked]
Organization: Verifone/Internet Commerce Division
To: [email-masked]
Subject: Comments on IPKI Part V: Time Stamp Protocols

Hi,

The following are my comments on the specification.

1. [Page 2, Section 2.2]

    The semantics of a 'valid request' should be described. I can only
derive that a valid request is one that can be decoded properly. Is
there more ?

2. [Page 2, Section 2.4]

    It looks like the TMP is restricted to timestamp messages. Shouldn't
the TMP timestamp any data, and leave the contents of the data to be
defined by the application ? If the concern is the size of the data,
then TMP should recommend that the sizes be made small by sending the
Digest of the data (I would recommend the use of PKCS DetachedDigest
type here), instead of the data itself.

3. [Page 2, Section 4]

    I recommend that the request message should carry a Nonce that is
reflected in the response. This is to prevent replay attacks.

4. [Page 2, Section 4]

   I would recommend that the messages also carry a version field in
them. In general, this applies to other PKI protocol messages (like
OCSP, etc.) as well.

5. [Page 2, Section 4]

   Following (2), messageImprint should be an open type.

6. [Page 3, Section 4]

   Please consider using PKCS SignedData for defining the response
message. Is there a reason why it is not used ?

7. [Page 3, Section 7]

   Applications using TMP should also be concerned about the the amount
of time it is willing to wait for a response. A 'man in the middle' can
introduce delays in the request message, to determine the time that the
application sees in the response.

Thanks
Deepak

Date: Sat, 06 Dec 1997 11:57:07 -0800
To: [email-masked] (David P. Kemp)
From: Warwick Ford <[email-masked]>
Subject: RE: draft-ietf-smime-crs-00.txt
Cc: [email-masked]

Dave:

What you are asking for is exactly what many of us had been trying to
achieve for a long time.  We had the plan, well over a year ago, that PKIX
Part 3 should be a 2-layered protocol - a set of messages at the top layer,
and a security enveloping mechanism, which could be either PKCS#7 or an
alternative mechanism favored by Entrust, at the lower layer.

Unfortunately this was not achieved, and our extensive efforts to achieve
this at Munich proved fruitless.  The problem is that the current CMP
specification simply does not reflect layer independence.  The messages
described in Section 3, in particular several of the PKIHeader components,
are inherently tied to the Entrust protection mechanism.

At Munich, we asked the PKIX CMP editor if he could rearrange the
specification to make the separation of these two layers pure, but he found
this unacceptable.

I see no point in reopening this issue again now.  Why would the outcome be
any different?  I see no alternative to letting the CMP protocol be
published as is, meanwhile the PKCS#7-based protocol will be developed as a
fully-independent specification.  The PKCS protocol should, of course, try
to reuse components of the CMP message formats where possible; in fact, I
am still hopeful we can meaningfully consider CRS to be an "interpretation"
of CMP.  However, it would be unreasonable to encumber the PKCS design with
unwanted baggage.

Regards,
Warwick

At 12:37 PM 12/5/97 -0500, David P. Kemp wrote:
>
>Mike,
>   With respect, I've admitted to you and others privately that I find
>the *document describing* CMP which is now in Last Call to be overly
>complex.  But I fail to understand why you refuse to make your proposal
>compatible with the CMP protocol itself, which in it's minimal form,
>is not that complex.
>
>
>> There is a serious disconnect here which no amount of artful optional
>> syntax will repair and we might as well admit it.
>
>There is a disconnect in someone's understanding, perhaps mine.  But
>IMHO the "artful optional syntax" is not an attempt to repair anything,
>it is the fundamental design principle which enables one to start small
>and add on later.  Stripped of everything optional, CMP can be
>described in just a few lines:
>
>
>    PKIMessage ::= SEQUENCE {
>        header    PKIHeader,
>        body      PKIBody  }
>
>    PKIHeader ::= SEQUENCE {
>        pvno      INTEGER,
>        sender    GeneralName,
>        recipient GeneralName }
>
>    PKIBody ::= SEQUENCE {
>        p10cr     [4] CertificationRequest }  -- PKCS#10 certification
request*
>
>
>Are you claiming that adding one integer, two names, and a couple of
>nested SEQUENCEs to PKCS #10 is so much of a burden that S/MIME
>developers, toolkit vendors, and CAs will be unable to accomplish it
>within the next release cycle?
>
>As Blake said, if there is something wrong with this tiny bit of
>required CMP syntax, then suggest that it be fixed.  Otherwise, just
>get about the business of writing your draft describing a minimal cert
>request syntax in a manner that is compatible with CMP, instead of
>insisting on a non-extensible alternative with no future growth path.
>
>
>> The issues and forces are readily apparent.  If x% of the PKI-using
>> community does something other than CMP for their own internal reasons,
>> then at some value of x we must perform a reality check.  I would claim the
>> current value of x far exceeds this threshold.
>
>Reality check: 100% of browser vendors do not support TLS in their
>current products.  Yet I don't see that being used as an argument claiming
>that the IETF must write a Standards Track protocol that enshrines
>SSL v3.0 as a permanent parallel alternative to TLS 1.0.  One Standard
>is enough - implementations are always free to support as many additional
>non-standard or de-facto standard options as business needs dictate.
>
>
>-------------
>* as an aside, I'll express my opinion that using the CMP "cr" message
>  and eliminating the redundant "p10cr" message would also not be a
>  major burden for developers, and would have the benefit of simplifying
>  the codebase.  But in the spirit of compromise, I won't
>  argue for that here. 
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

From: [email-masked]
Date: Fri, 05 Dec 1997 16:38:27 -0700
To: "IETF X.509-based public key infrastructure mailing list"              <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

Tim,

A very thoughtful analysis.  I believe however there are several critical
points the list's readership should consider before they come to any firm
conclusions regarding the suitability of proposed mechanism to the
requirements at hand:

1. CRLs are more complex than needed to satisfy OCSP requirements.  While I
don't wish to presume to speak for those who evolved the concepts, CRLs are
architected towards an operational concept that is orthogonal to the needs
of online status checking.  They were and are static objects intended to
aggregate information in a central repository.  An OCSP response is (or, to
be fair, must be capable of being) a dynamic object intended to distribute
a single piece of information throughout a large-scale network.

2. CRLs fail to address the extensibility and value-added requirements
asserted by Rich Ankey and Bob Juenemann.

3. In separate works, Silvio Micali and Santosh Chokani have amply
demonstrated the devastating effect that even modest CRL distribution
transmission schedules can have on the costs of operating a network.  This
effect is particularly acute when the proposed mechanism is applied to
dynamic production of responses--precisely the requirement an online status
mechanism must support with minimal impact.

4. A CRL only confirms revocation.  It does not assert that a given
certificate is valid if not present on the CRL.  Thus relying parties are
ill-equipped with the proposed alternative to acquire the answer they most
wish to receive.

5.  The analysis fails to recognize the diversity of uses of public key
technology, and consequently leads to false conclusions regarding cache hit
ratios at the periphery of a distributed network.  For example, the
population of parties relying on certificates that validate the
authenticity of signed code objects is orders of magnitude larger than the
population of signed code publishers.  A similar asymmetry exists with
respect to SSL server authentication.  Lastly, SMIME message originators
could include as an authenticated attribute an OCSP response validating
their certificate.

Now, to respond to your specific points:

At 09:17 AM 12/2/97 -0500, Tim Moses wrote:
>Colleagues - I have been reviewing the OCSP and the 'FTP and HTTP'
>drafts, and it occurs to me that OCSP can be considered to be a special
>case of the latter scheme.  This would not be the case if OCSP could
>offer a 'live' response in a large-scale system, but clearly this is not
>practical.

Quite the opposite, I would claim.  OCSP is specifically intended to enable
live responses for large-scale environments with a need.  I would define
large-scale to be at least as large as the number of parties currently or
potentially relying on signed code objects.

Liveness at this scale is strongly driven by cryptographic throughput.
There exist on the market today a number of high-speed cryptographic
devices with sufficient per-signature performance and throughput capacity
to enable such a service.

Liveness is also governed by bandwidth requirements.  However, predictions
on required bandwidth are subject to a range of operational models.  I will
identify some of these in a moment.  When integrated across the complete
set of PKI usage environments, the practicality of OCSP should become
readily apparent.

>I assume that OCSP is designed to provide notification of revocation
>over the Internet in the absence of a replicated directory.  Clearly,
>there is a need to solve this problem. But the use of CRLs over HTTP
>offers a more general solution to the same problem.

But with generality comes complexity and redundancy.  Here I would assert
another fundamental requirement: bounded simplicity.  With CRL extensions
and CRL entry extensions, CRLs are far from simple constructs.  For
example, does this proposal apply as well to the Indirect CRL case as well?
 Knowing the intended purpose of that construct (having been a contributor
to its formation), I would expect it could.  Thus, in order to deliver on
the same set of capabilities OCSP provides, the proposed alternative
requires a considerable investment in CRL implementation to achieve the
same effects that OCSP's much simpler syntax and operational concept provides.

>In addition, it is
>a more robust solution, offers greater flexibility in engineering
>implementations, exhibits lower cost and makes better re-use of existing
>software.

One must consider the totality of the definition of "cost".  As a (former)
software developer, flexibility is a good thing.  But if I were a product
manager and all I wanted was my Java-based applet to determine if *this*
certificate is good *now*, why would I want to pay to develop needless
flexibility?  Because I might need it someday?  I've been in these
discussions before; the outcome is quite predictable.  From this
perspective, the proposed alternative increases costs and product
development cycle time to the point where revocation checking *might* show
up in version N+1 of that Java applet.  Thus the proposed alternative
inhibits the growth of PKI when compared to the original OCSP solution.

>HTTP-caching must be used with either protocol, in order to
>achieve adequate scalability.  In which case, the CA can control the
>cache retention interval in intermediate HTTP servers, in order to
>ensure that they will be refreshed when new revocation status
>information is scheduled to become available.

This is exactly the case I've been making, where caching is operationally
relevant.  I fail to see though how it benefits the CRL over OCSP argument.

>An illustrative example to support these conclusions is provided at the
>end.
>
>Summary
>
>OCSP places a heavy load on the most highly shared components of the
>system, making it unnecessarily expensive to offer a scaleable and
>compliant service.

In other words, OCSP performance tuning can be centrally managed and
scaled.  I would expect many IT managers to welcome this aspect of OCSP
over the burden CRLs transmission places across a network.  In the first
case, one buys a more powerful server.  In the latter case, one is faced
with an organizational-wide upgrade of networking capability to accomodate
the proposed alternative.

As Silvio Micali's and Santosh Chokani's studies have shown, CRL
transmission injects large amounts of unrequested information into and
throughout a network.  This burden can quickly overwhelm any other costs
associated with operating a PKI.  It was these and other well-considered
analyses that led to the notion of an online status mechanism in the first
place.

>This is because dividing revocation information into
>its smallest parts makes the probability of a cache hit in the periphery
>of the network insignificant.  This may be appropriate if, for some
>reason, one wants to ensure that each individual revocation status
>request is serviced directly by the CA, but a more general solution is
>required for situations where this is not a consideration.

I read in the above the requirement for trust distribution.  This has
nothing to do with CRLs and everything to do with liability apportionment.
I don't know how many reading the list have had the pleasure of actually
working out the business details of such agreements, but experience has
shown the diligence required can far outweigh the costs associated with
technical implementation.  If I may brutally condense the DSG, it's not the
signature that's important, it's the trust that lies behind the signature.  

Thus, the policy generality implied by the trust distribution requirement
is in no way met by the technical generality of the proposed alternative.

>Moreover, the general solution can, if necessary, be engineered to provide a
>service equivalent to that offered by OCSP where this is appropriate.

There is no requirement for a general solution that can be reduced to the
intended functionality.  There does however exist a diversity of needs.
Some of these can be satisfied by CRL retrieval mechanisms.  Where CRLs are
either unworkable, untimely or unavailable, a quick direct connection is
needed.

>
>Conclusions
>
>OCSP and the 'single monolithic CRL for the entire subscriber-base'
>approaches represent two extremes of the general solution represented by
>CRL distribution points accessed over the HTTP infrastructure.  OCSP can
>be considered equivalent to assignment of a single subscriber to each
>distribution point, and the single monolithic CRL can be considered
>equivalent to the assignment of the entire subscriber-base to a single
>distribution point.
>
>The special case of OCSP leads to a solution which minimizes the
>consumption of network resource in the dedicated data-link between the
>relying party and its ISP.  But, this is not a scarce resource (largely
>because it is not shared).

It is however the only one relying parties are concerned about.

>The penalty paid for this is that there is
>increased demand placed on the most highly shared components (the
>data-link between the Internet and the CA and the CA's signature
>facility).  This leads to excessive hardware and communication costs.

The cost model needs refinement.  Clearly one can construct an example case
to fit any cost model.  I have some further observations to this point
later on.

>Using CRLs over HTTP represents the general solution of which the other
>two can be considered special cases.

Again, there is no requirement for a general case that reduces to the
required functionality.  This strikes me as an argument one hears in the
SPKI camp (with all due respect to those working on some very difficult
issues over there.)

>Therefore, each implementation of
>the general case can be engineered, as appropriate, to satisfy the
>requirements of the specific application.  Those for whom the
>characteristics of OCSP are attractive may tailor the general solution
>to recreate OCSP-like characteristics.

But for all its claimed generality, the proposed alternative is still
absent the value-added features that commentators such as Rich Ankey and
Bob Juenemann have requested.

As I indicated in an earlier note, syntactic restructuring of the baseline
OCSP syntax could easily accomodate these needs while maintaining baseline
functionality.  How does a CRL convey a reliance limit?  How does a CRL
bind a message hash to an attestation of certificate validity?  How does
one incrementally add other context information?

The fact is CRLs serve one well-defined set of needs.  OCSP serves a
complementary set.  Force-fitting requirements onto a solution ill-suited
to satisfy those requirements leads to dissatisfied customers, redesign and
redeployment.  As I see it, the proposed alternative to online status will
lead to such scenarios.

>Others can make different choices, without having to modify the
>operation of the relying party software.

Assuming that relying party software is capable of managing hundreds of
partitioned CRLs.  How does a web browser select from among these partioned
CRLs, assuming local caching is being leveraged?  The proposed alternative
presumes a pre-placed technical development infrastructure.

>So, I propose that we examine the Internet Draft protocol for
>distributing CRLs over HTTP and ensure that it adequately accommodates
>the concerns that led to the proposal for the OCSP protocol.

The basis for OCSP's existence was a fairly broad and long-held consensus
that CRLs fail to meet timeliness and bandwith needs.  A mechanism based on
CRLs to now meet this need is self-contradictory.

>Analysis
>
>The effect of caching at the periphery of the Internet becomes apparent
>by considering this illustrative example.
>
>The architecture consists of ten components connected linearly in order
>from 1 to 10.
>
>Component 1: The relying party.
>Component 2: The relying party's HTTP cache.
>Component 3: The relying party's data-link to its ISP.
>Component 4: The ISP (let's assume that each ISP serves 1,000 relying
>parties).
>Component 5: The ISP's HTTP cache.
>Component 6: The ISP's data-link to the Internet backbone.
>Component 7: The Internet (let's assume that all the relying parties are
>represented by 1,000 ISPs).
>Component 8: The data-link connecting the Internet backbone to the CA.
>Component 9: The CA's HTTP cache.
>Component 10: The CA's signature facility.
>
>In this architecture, the CA serves 1 million subscribers and 1 million
>relying parties, via 1,000 ISPs.

As I will note below, this is but one example of these types of
relationships.  There are a number of different cases that need to be
considered when trying to do scalability assessments.  One can prove or
disprove the case for CRLs depending on what assumptions you make and what
your domain looks like.

>
>Other assumptions we need are these.
>
>Assumption 1.  Each use of the OCSP protocol consumes 6 kilobits of
>network resource.  This number includes the signature on the OCSP
>response (assumed to be 1024b or 170 base64 characters), but it also
>includes bits associated with establishing and destroying a TCP
>connection and sending the HTTP message.
>
>Assumption 2.  In the case of CRLs over HTTP, let's assume that the 1
>million subscribers are assigned to 500 distribution points, and that
>10% of subscribers are revoked at all times.  This situation might
>obtain in a corporate setting, where certificates are issued with a one
>year validity, they are revoked when the holder leaves the corporation
>and the corporation suffers a 10% staff turnover.  I believe these are
>very conservative assumptions.  Under these assumptions, the network
>resource consumed by retrieving a distribution point entry may be 50kb,
>including the bits associated with the connection and message.  While
>this number is almost ten times that for OCSP, it is much more
>efficient, because it conveys information about 2,000 certificates.

Conversely, it places onto the wire ten times more information than the
relying party requested.  What is the likelihood one would find the next
certificate on this partion again?  The model as presented strongly
suggests it would be on the order of a 2% likelihood (2000/100000).  In the
instance when "most-current" updates are needed--exactly the timeliness
requirement OCSP was intended to satisfy--and the CA operates a more or
less fixed policy of CRL partition size, there is no cache effect to be
obtained.  Thus almost every validation is going to result in the
transmission of nearly 50kb of useless information.

It is true that one could increase the granularity of the CRL partition to
mitigate this effect, but now implemetors and designers of a online service
would be faced with the complexity associated with CRL size partition
management.  Does this require a policy management module/subarchitecture?
It would seem so if the proposed alternative were to be reduced to practice
as proposed.  It is much more likely the partition size would be fixed.
Consider as well that if some compromise were struck in the design
process--say, five different partition sizes for five different levels of
service--then one is face with producting five different CRLs to answer
essentially the same question.

It is easily predictable that when operated in the manner which OCSP is
intended to operate, applications which dared to implement the proposed
alternative would quickly flood their communications channels with
unrequested information.  This is exactly the scenario Silvio and Santosh
warned us against.

>
>Assumption 3.  Each relying party validates 0.01 certificates per second
>during the "busy-hour" (this pattern of behavior  is consistent with use
>for signed and encrypted email, in which all relying parties work
>through their "overnight" email first thing in the morning).
>
>Assumption 4.  The relying parties are spread geographically over three
>time zones.
>
>Assumption 5.  In order to keep delays caused by contention for shared
>resources to an acceptable level, shared components will be engineered
>with a capacity three times the calculated busy-hour average demand.
>
>In the case of the OCSP protocol ·
>
>OCSP component 2 (relying party HTTP cache).  The probability of a hit
>on the relying party's cache is zero.
>
>OCSP component 3 (relying party data-link).  The average resource
>consumption in the data-link between the relying party and the ISP is
>6kb * 0.01 per sec = 60b/s.
>
>OCSP component 5 (ISP HTTP cache).  The probability of a hit on the
>ISP's cache is essentially zero (the ISP receives 36,000 requests during
>the busy-hour.  If you pick at random, from 1 million items, 36,000
>times (replacing them after each pick), then the probability of picking
>the same item twice is negligible).

The analysis is fundamentally flawed in that it over-simplifies the
population assumptions.  There are many operational environments and
communications habit factors that could substantially increase the
likelihood of a cache hit.

The probability of a hit will increase as relying party's queries are
retained in the cache.  The first few RPs will not hit, but later ones
will.  The analysis is also over-simplified in failing to consider the
traffic patterns.  In many organizations, there exist well-established
channels of external communications:  between trading partners, well-known
customers, geographically dispersed organizations and so forth.  It is
further well known that a large percentage of one's daily email is with
other members of the organization.

The analysis also fails to acknowledge well-known population relationships
in the PKI marketplace today.  In the code signing or SSL server
authentication case, the size of the domain of relying parties is very
large compared to the size of the domain of subscribers.  This population
asymmetry would in many cases raise the probability of a cache hit to near
unity in queries on a signed code publisher or secure server certificate.

Consider also equivalent architectures:  Authenticating Firewalls, Secure
Mail Gateways, Secure Mail Lists, an IPSEC router.  The entire
client-server paradigm is completely ignored in this example.

In the case of SMIME the population size of subscriber and relying parties
are indeed more nearly matched as the assumption asserts.  However, given
an OCSP status service, message orginators could acquire and attach their
current OCSP status to the SMIME message.  This could be done quite easily
as an Authenticated Attribute.  This can become a very convenient mechanism
for non-repudiation needs.  At baseline assumption of 50kb per CRL
partition, the proposed alternative call into question the practicality of
this potentially indispensible practice.

>OCSP component 6 (ISP data-link).  Each ISP passes 36,000 requests per
>hour to the Internet backbone.  So, the resource consumed in the
>data-link between the ISP and the Internet backbone is 1,000 * 60b/s =
>60kb/s.  Applying Assumption 5, a 256kb/s data link is required.

Assuming no cache hits in the peripery of the network.  As previously shown
however, this assumption is fundamentally flawed.

>
>OCSP component 8 (CA data-link).  If the ISPs each serve one time zone,
>then 333 of them will be generating busy-hour traffic levels at the same
>time.  Therefore, resource consumption in the data-link between the
>Internet and the CA will be 333 * 60kb/s = 20Mb/s.  So again, by
>Assumption 5, a 60Mb/s ATM link is required.

Again, the resulting bandwidth estimate is arrived at via an oversimplified
assumption regarding population structures and well-known usage patterns.

>
>OCSP component 9 (CA HTTP cache).  The CA's cache outputs is 36,000 *
>333 = 12 million requests per hour.  So, a database capable of serving
>3,333 read operations per second is required.

Same issue regarding population structures.

>
>OCSP component 10 (CA signature facility).  If the CA takes 3 hours to
>replenish its cache with a new entry for each of its 1 million
>subscribers, then the CA's signature facility must support a rate of 90
>signatures per second, and responses may be up to three hours out of
>date.

Which is easily within reach of today's hardware cryptographic
accelerators.  Given the current state of the art, signature production
throughput is a well-contained problem.  There no shortage of hardware
crypto vendors eager to prove their product line is up to this task.

>
>In the case of the CRLs over HTTP protocol. ·
>
>CRLs over HTTP component 2 (relying party HTTP cache).  The probability
>of a hit on the relying party's cache is zero.
>
>CRLs over HTTP component 3 (relying party data-link).  The average
>resource consumption in the data-link between the relying party and the
>ISP is 50kb * 0.01 per sec = 500b/s.
>
>CRLs over HTTP component 5 (ISP HTTP Cache).  The ISP's HTTP cache
>receives 36,000 requests per hour for one of 500 distribution points.
>Therefore, the probability of a cache hit is 0.986.  Although each
>request consumes about ten times as much network resource, only slightly
>more than one in every hundred requests are transferred to the Internet.
> So the amount of Internet traffic generated is approximately one tenth.

But, as noted earlier, in the case of a need for dynamic refresh--exactly
the requirement OCSP is intended to satisfy--the overall network burden is
dramatically impacted.  Further, this effect is transferred directly onto
the local organization subnet, flooding it with unrequested and very likely
useless information.

>
>CRLs over HTTP component 6 (ISP data-link). The average data rate
>transferred by the ISP cache to the Internet is the number of relying
>parties times the average data rate per relying party times one minus
>the efficiency of the case.  I.e. 1,000 * 500 * (1 - 0.986) b/s.= 7
>kb/s.  Therefore, by Assumption 5, a 32kb/s link would be adequate
>between the ISP and the Internet backbone.
>
>CRLs over HTTP component 8 (CA data-link).  If the ISPs each serve one
>time zone, then 333 of them will be generating busy-hour traffic levels
>at the same time.  Therefore, resource consumption in the data-link
>between the Internet and the CA will be 333 * 7 kb/s = 2.3 Mb/s.  So, by
>Assumption 5, a 7Mb/s data link is required between the Internet and the
>CA.
>
>CRLs over HTTP component 9 (CA HTTP cache).  The CA's cache receives 333
>* 500 requests per hour.   So, a database capable of servicing 50 read
>operations per second is required.
>
>CRLs over HTTP component 10 (CA signature facility).  If the CA were
>capable of performing 90 signature operations per second, then
>theoretically, it could update all of its 500 entries once every six
>seconds.  If, however, it were to update them every three hours, then
>its signature capacity must be 0.04 signatures per second.

If CRLs were updated with this frequency, then bandwidth needs of component
6 and component 8 can easily exceed those of the OCSP case for some
reasonable assumptions on CRL partition granularity.

>
>
>--------------------------------------------------------------
>Tim Moses, Entrust Technologies,
>Tel: 613 247 3183,
>email: [email-masked].
>
>

From: [email-masked]
Date: Fri, 05 Dec 1997 19:11:08 -0700
To: Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

Marc,

At 10:37 AM 12/5/97 -0800, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>I agree with Phill's comments below, and would like to add what I think is
>a slightly different perspective.
>
>OCSP is an attempt to address some of the flaws of the CRL model.  For the
>most part, the flaw with the most attention has been the untimeliness of
>CRL revocation information.  But there's another CRL flaw that deserves
>equal attention, and which isn't being properly addressed with the current
>OCSP discussion.
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

Keep in mind there's still a periodicity effect in the event of caching.
Section 2.3 of the current draft sets out the requirements.

>
>Of course, OCSP can't be used in all situations.  A caching mechanism is
>needed to relieve bandwidth pressures.  But CRLs are poor candidates for
>a caching mechanism, because they still dictate to relying parties when
>their caches can be refreshed.
>
>It is crucial that relying parties get the revocation information they
>need when they need it.  To accomplish that, CRLs need to be avoided
>entirely.  Instead, relying parties should cache OCSP responses, and
>decide for themselves when to refresh their caches.
>
>Luckily, it's easy to charge for an OCSP query.  So we have the makings of
>a self-regulating system.  Parties who need real-time revocation
>information can pay for it.  On the other hand, once I find the validity
>of my buddy's email signature certificate it's unlikely that I'll feel a
>desperate need to refresh that validity information every time I read one
>of his messages.  Especially if I have to pay $x every time I do so.
>
>The point is that in order to allow CAs to serve the widest community of
>users, they need to be flexible enough to properly serve those users'
>needs.  CRLs simply do not provide the required flexibility.

I think it's fair to say we are in violent agreement here.

>The OCSP proposal, as it stands, is also inadequate. Along with the OCSP
>specification, we need a description of the caching mechanism, which can
>be simple, but is definiately required.  We also need to define user
>interface behavior, because real people are ultimately the relying
>parties in most of the situations we want to support.  By this I mean that
>we need to explain that the users must be shown the ages of the satuses
>(stati?) of the certificates they're about to rely on, and they must be
>given the opportunity to refresh that status if they desire.

Again, I completely agree.  However, we must be cautious about overly
constraining implementors.  We can and should standardize what's
standarizable.

>
>OCSP only becomes viable with proper caching and user interaction. 
>Otherwise, it's a tool without an instruction manual.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                       \/
> Chief PKI Architect                                  /\CERT SOFTWARE INC.
> [email-masked]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>
>
>On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
>> 
>> Re Tim Moses <[email-masked]> comments concerning the alledged 'non
>> scalability of OCSP'.
>> 
>> I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>> First I note that Tim does not address scalability but the relative
>> performance of OCSP and the Entrust approach under his chosen set of
>> assumptions.
>> 
>> Scalability is about  whether an architecture limits the size of the
problem
>> that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>> assumes a big enough mainframe can be purchased.
>> 
>> OCSP supports a function call end clients make routinely: 'Is this
>> certificate valid'. It allows the function 'check every certificate in my
>> address book' to be supported cleanly. Unless you want to either handle
CRLs
>> in the client or route all traffic through a central bottleneck OCSP is the
>> obvious approach.
>> 
>> To gain perspective on scaling issues I believe we should look at a billion
>> certificates or more rather than Tim's million. At least two applications
>> will involve this number of certificates:
>> 
>>     * Credit card processing
>>     * Certificate based equities
>> 
>> Both these scenarios are much smaller than systems I have previously helped
>> design, ZEUS and the Web. Simulation is the only way to prove viability of
>> such systems. I see OCSP as a usefull tool in meeting such challenges which
>> require a 'full toolbox'.
>> 
>>         Phill
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNIhJ4lrdFXNdDxPlAQEsFwL9GyGA7p9xeIBBiMYfkeVvqCfEGFHD71Ga
>FdIDELmR42ksY7bjVlpuh0O7BuqvXBeV+Atx8EIV8TlrHFaWuZzxPSbyp93RoCr3
>0FHsGlcoyRQsjaUZAMMi1g5LwWOkdrWX
>=Sp+F
>-----END PGP SIGNATURE-----
>
>
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Encoding of INTEGER fields in PKIX certs
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 6 Dec 1997 15:59:54 (NZDT)

David P. Kemp <[email-masked]> writes:
 
>ASN.1 INTEGERS are encoded as two's-complement numbers, which implies that if 
>a BER-encoded value is decoded into a larger native storage value, the high 
>bit of the encoded value will be sign-extended into the excess bits of the 
>native value. For cryptographic purposes, it is my understanding that bignums 
>are always the same size as the encoded values, so the issue of sign 
>extension never arises.  (Additionally, for cryptographic algorithms using 
>modular arithmetic with a 2^n modulus, any sign-extended bits larger than the 
>modulus are ignored - chopped off in the modular reduction.)
>
>[...]
>Since a distinguished encoding of these values is required, there MUST be an 
>encoding convention for whether to do sign padding when MSB=1. Most of the 
>cert examples I have seen do not do sign padding.
 
The only certs I've seen that very consistently do this are the ones produced 
by Microsoft software, who encode all (well, strictly speaking about 50% on 
average) of their INTEGERs incorrectly.  Everyone else seems to get it right 
(this is from a random sample of 50-odd CA certs pulled from browsers and 
things).  My ASN.1 dump program 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c, will flag negative integers 
as encoding errors and can be used to check for this problem.
 
>* Does a convention for sign padding of INTEGERs already exist anywhere?
 
Yes.  X.680 says:
 
  8.3.2 If the contents octets of an integer value encoding consists of more 
        than one octet then [the first 9 bits]
        
        a) shall not be all ones; and
        b) shall not be zero.
 
  8.3.3 The contents octets shall be a two's complement binary number equal to 
        the integer value and consisting of [lots of stuff on how the bits are 
        ordered].
 
Therefore if the high bit in the value to be encoded is set, the first octet 
is zero; if the high bit is not set, the first octet is nonzero (in other 
words INTEGERs have to be zero-padded).
 
>If not, Part 1 should be amended to specify that compliant CAs SHALL NOT 
>generate padding 00 bytes for INTEGERs, and that verifiers SHOULD accept both 
>padded and unpadded INTEGERs.  And I will correct the examples accordingly.
 
Doing this would be in violation of the BER and DER, which is unhealthy (you 
could try asking about messing with the encoding rules on the OSS ASN.1 list, 
but I'm pretty sure I know what they'd say).  It should be the other way 
around, always pad 00 for integers.
 
(As an aside, it's a bit of a pain to work with these padding bytes because 
your encoded integers have a 50% chance of growing by 1 byte after your 
signature is generated.  However the standard says you have to do this, and it 
makes sense even if it's a bit of a nuisance).
 
Peter.

From: [email-masked]
Date: Fri, 05 Dec 1997 17:48:55 -0700
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: OCSP Considerations

Bob,

At 11:09 AM 12/5/97 -0700, Bob Jueneman wrote:
>Mike, sorry if I too negative. Sometimes it is difficult to know if someone
>agrees with you but hasn't had time to say so, vs. is still thinking, vs.
>disagreeing and/or ignoring you.  I appreciate the fact that we all have
>other jobs to do as well.

No problem.  The intent of the note was simply to stimulate constructive
comments towards consensus.

>
>With regard to your strawman proposal, my comments would be the following:
>
>1.  I see no particularly good reason to avoid the use of ASN.1. Despite
>some of its complexity, it provides a uniform way of documenting the
>specifications that can be validated by use of a compiler (minimizing the
>possibility of a misunderstanding). Anyone who is implementing any kind of a
>PKI implementation is going to be up to their ears in ASN.1 -- a little more
>won't hurt. But I wouldn't go to war on this issue.

In this instance, and especially this transport model, there exist
compelling reasons to not do ASN.1 simply because that's what PKIX does.
If all an application needs for ASN.1 is certificate decoding, this is or
soon will become an API-level issue.  The same applies to a perhaps lesser
scale for those who wish to use PKCS7 in creative ways.

For a general specification mechanism, it's great.  But in this instance we
can do our job without it, to the benefit, for example, of the small
Java-based developers who are using an API for certificate deconstruction.

>2. Regardless of the ASN.1 decision, providing a means of easily extending
>the protocol is absolutely vital. In particular, it is highly likely that
>billing information will have to be conveyed in both directtions, and
>ultimately a transaction value field as well.

I agree, and as I said earlier, began going down this path on the basis of
Certco's request in Munich. Going into the redraft though, the then-current
request syntax did not easily accomodate extensibility.  I was also wary of
over-engineering the solution in isolation. What I felt myself lacking
however were the voices of those who had similar expectations of usage.  I
concluded that it would be best to hear from others first before presuming
OCSP extensibility was meeting the needs of the WG as a whole.

After sitting back and taking another look at the draft, and especially the
recent spate of comments, it was clear that a couple of simple corrections
would accomodate mutually opposed needs.  That is, extensions that
incorporate transactions identifiers do an equally effective job at
breaking caching behavior.  However, the OCSP draft needs also be
accomodate enterprise-level operations where trust and policy is implicit
and all they really want back is a 1 or a 0.

So, I believe we're in agreement here.

>
>3. Both the request and the response need to be signed, at least optionally,
>and particularly if there is billing or other information associated.

I agree, particularly with the optional part.

Now, there is a converse side to this capability--unsigned responses.  Some
may wish to take advantage of this design effect for enterprise-level
needs.  Within an enterprise, trust is often implicit and security policy
enforced procedurally.

>
>4. I haven't studied the timestamping proposal, so I have no comment on the
>use of an OID in this area.  It is sufficient, I believe, that the CA or
>repository which is acting as an agent of the CA include the time, since in
>most cases I believe that time per se will not be of critical importance.

May I draw your attention to recent work by Todd Glassey and David Mills
regarding the instrumentation of trusted time?  Todd recently posted notice
to the PKIX of this work.  Their work is at
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt

>
>5.  I don't see any particular utility in making the nonce field optional in
>the request -- if someone is really convinced that they don't need it, they
>can just fill in zeroes, without adding the addtiional complexity of
>deciding whether or not it was included, and therefore whether it should be
>included in the response.

But doing so then creates complexity and potential breakage at the backend.

I presume this practice is intended to enable pre-production and caching.
However, this then requires CAs or other trust providers to reliably
predict the default value in the event they wish to pre-produce signed
responses.  We could easily agree on an industry-standard default value but
this alternative also invites the possibility that a given developer will
get it wrong, deploy their product, and break.  This kind of thing happens
more frequently than perhaps we all care to admit.

Also, there would need to be at least some minor amount of code written on
the client to examine the default setting and branch appropriately.  So I'd
prefer to have this branch to a default of "no inclusion" vs. "default
value" because it seems to me the client-end complexity is roughly
equivalent while also providing some benefit at the  backend.

>
>7.  It would be nice, but perhaps not essential, to have something in the
>request that specifically identifies the nonce as consisting of a message
>digest (SHA-1 by default) of the date/time of the request concatenated with
>the digital signature which is being validated by this OCSP request.

I can see where this might be useful for certain applications.  But I would
not want to assert any requirement that the trust provider confirm this
construction.  From the trust provider's point of view, the underlying
structure of the nonce, when included, should be opaque.  Now, this does
lead us predictably into who is attesting to what in this interaction.  If
the CA behaves "opaquely", then it is just a status service and subjecting
itself to one set of potential damages.  If the CA confirms the
construction, did it just unwittingly become a digital notary?

Mike

Date: Fri, 05 Dec 1997 15:46:12 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Computing Corp.
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Encoding of INTEGER fields in PKIX certs

It's not really sign extension that is the issue here.  It is the
representation of the sign itself. INTEGER represents a two's
complement signed integer.

The most significant bit represents the
sign bit in the encoded integer.  If what you intend to
encode is a positive value and the most significant bit
would otherwise be a 1, then you must add a  zero octet 
to preserve the intended sign.

--a.

David P. Kemp wrote:
> 
> ASN.1 Folks,
> 
> I have the following certificate, which is intended for use
> in the PKIX Certificate and CRL Profile examples draft.
> 
> There are several fields representing cryptographic bignums which
> are encoded as INTEGERs: the DSA parameters p, q, and g; the
> DSA public key y, and the DSA signature values r and s.
> 
> ASN.1 INTEGERS are encoded as two's-complement numbers, which
> implies that if a BER-encoded value is decoded into a larger
> native storage value, the high bit of the encoded value will be
> sign-extended into the excess bits of the native value.
> For cryptographic purposes, it is my understanding that bignums
> are always the same size as the encoded values, so the issue
> of sign extension never arises.  (Additionally, for cryptographic
> algorithms using modular arithmetic with a 2^n modulus, any
> sign-extended bits larger than the modulus are ignored - chopped
> off in the modular reduction.)
> 
> With that in mind, is it ever necessary to do sign-bit protection
> of BER-encoded INTEGERs (adding an extra 00 whenever the MSB of
> the value is 1)?
> 
> In the following example, p and q each have MSB=1, and have the extra 00
> octet added.  g and s have MSB=0, so no extra octet is needed.
> The public key (y) and r both have MSB=1 and no extra octet, thus the
> encoding of y and r is inconsistent with the encoding of p and q.
> 
> Since a distinguished encoding of these values is required, there MUST
> be an encoding convention for whether to do sign padding when MSB=1.
> Most of the cert examples I have seen do not do sign padding.
> 
> I believe that padding:
> 
>  * is always unnecessary,
>  * is an added complication,
>  * is seen less often than unpadded INTEGERS in existing certs, and
>  * is inconsistent with the treatment of parameters encoded
>       as BIT STRINGs or OCTET STRINGs, which are never padded
> 
> so I would prefer to document the convention that sign padding is not
> to be used.
> 
> Questions:
> 
>  * Does a convention for sign padding of INTEGERs already exist anywhere?
>  * Is there ever a need to do sign-extension of encoded INTEGERS
>     (in which case padding would be necessary)?
>  * Does anyone feel that sign padding is desirable, regardless of whether
>     it is necessary?
> 
> If not, Part 1 should be amended to specify that compliant CAs SHALL
> NOT generate padding 00 bytes for INTEGERs, and that verifiers SHOULD
> accept both padded and unpadded INTEGERs.  And I will correct the
> examples accordingly.
> 
> -----------------------------------------------------------------------
> 
>       Version: v3
> Serial Number: 256
> Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
>    Parameters: NULL
>        Issuer: C=US, O=gov, OU=nist
>      Validity: Not Before 970609050000Z
>                Not After  980609050000Z
>       Subject: C=US, O=gov, OU=nist
> SubjectPKInfo: id-dsa (1.2.840.10040.4.1)
>    Parameters:
>       p:
>         00 93 e8 96 5d af d9 df ec fd 00 b4 66 b6 8f 90
>         ea 68 af 5d c9 fe d9 15 27 8d 1b 3a 13 74 71 e6
>         55 96 c3 7f ed 0c 78 29 ff 8f 83 31 f8 1a 27 00
>         43 8e cd cc 09 44 7d c3 97 c6 85 f3 97 29 4f 72
>         2b cc 48 4a ed f2 8b ed 25 aa ab 35 d3 5a 65 db
>         1f d6 2c 9d 7b a5 58 44 fe b1 f9 40 1e 67 13 40
>         93 3e e4 3c 54 e4 dc 45 94 00 d7 ad 61 24 8b 83
>         a2 62 48 35 b3 1f ff 2d 95 95 a5 b9 0b 27 6e 44
>         f9
>       q:
>         00 bb 5d fe 42 de 11 5c 00 db 5e f1 b0 38 83 44
>         d6 c1 54 85 ad
>       g:
>         69 27 9f 8e ba b8 0e 8f 24 f0 18 46 21 96 63 6c
>         4c 22 54 64 f0 13 3e 0f 2f 21 e7 bb ed 1d 85 3f
>         06 eb 94 9a 86 85 0a 30 a9 b5 b2 ce a8 30 ea ad
>         00 e7 bd f6 1e bc 81 cc 41 de ba ff 1b 5b fd 9f
>         2a a4 b1 13 29 b1 3c 3d c6 95 11 27 fb c8 6b 4d
>         35 33 82 3b f9 7a 58 de 2f f1 f9 c9 b3 17 7b a3
>         49 4e d5 e0 00 38 3d bd 6a 69 9d 57 89 54 8f ce
>         f5 07 36 8e 4b e6 6e eb 0f 08 75 73 8c bc fc c5
>    Public Key:
>         8b 20 50 88 00 73 c1 35 95 44 c5 5f ef b4 d8 08
>         b8 8d 21 ec 91 06 6e 2e 8a a7 a8 92 97 75 2d fa
>         87 f3 94 b7 72 3d 21 c8 5d 1e 3a 59 7a 6c c7 62
>         5b 2f c5 bc ae ce 68 ad 52 85 6a 83 5c a6 43 7d
>         d8 8e bc 7e ea 12 74 89 ec ad 89 fe 7a be fb fb
>         2a 0e 2e 28 8d 92 a1 7a 67 3d b2 52 73 39 63 8f
>         0f 79 c6 b2 f6 40 46 83 bf 62 6e 1c d2 25 b5 e5
>         5a ff d1 ad 4d b3 bc cc 65 bd 08 04 4e 11 32 45
>    Issuer UID: none
>   Subject UID: none
>    Extensions: 2
>   Extension 1: Critical basicConstraints (2.5.29.19)
>     CA = Yes, Pathlen = unlimited
>   Extension 2: Critical keyUsage (2.5.29.15)
>     Usage Bits= { keyCertSign cRLSign }
> Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
>    Parameters: NULL
> Signature Value:
>       r:
>         b3 2d dd 5e c9 f6 6d a7 91 c0 3f aa e7 43 77 40
>         f3 1f b1 64
>       s:
>         68 fd 1a 69 da 08 9c 27 9c 34 32 8b 43 23 cb d1
>         84 13 32 ca

-- 
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Date: Fri, 5 Dec 1997 15:16:19 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 5 Dec 1997, David P. Kemp wrote:
> 
> > From: Marc Branchaud <[email-masked]>
> > 
> > OCSP is an attempt to address some of the flaws of the CRL model.  For the
> > most part, the flaw with the most attention has been the untimeliness of
> > CRL revocation information.  But there's another CRL flaw that deserves
> > equal attention, and which isn't being properly addressed with the current
> > OCSP discussion.
> > 
> > The flaw is that the decision of when to release new revocation
> > information rests with the CA.  In other words, a relying party who needs
> > up-to-date revocation information in a CRL-only environment has to wait
> > for the next CRL to be published.  The relier has no power to influence
> > the CA into releasing revocation information earlier.
> 
> I don't see how OCSP with caching allows the relying party any more control
> over the timeliness of revocation information than does CRL with caching.
> 

If the relying party can decide whether or not to ignore the cache, then
the RP has more control.  Although your model of CRLs is different -- I'll
get to it below -- having CRLs sitting in a repository and refreshed
periodically does not give the RP the option of ignoring the cache,

> Of course, if a particular CA publishes CRLs once per month, many RPs will
> not find it sufficient.  But in the limit, there is no reason for CRLs
> to be published more frequently than on an event-driven basis - a new
> CRL issued every time the status of any covered certificate changes, or
> whenever the nextUpdate field kicks in if there have been no intervening
> status changes.
> 
> The CA (or CRL publisher) is the only entity authoritative for
> revocation events, so it makes more sense for the CA to push updates
> than for caching OCSP servers to decide to refresh based on some
> necessarily arbitrary criteria.  In the case of all but leaf
> certificates, it seems obvious that status-change events will occur
> *far* less frequently than status queries, so the CRL push model is
> more appropriate.
> 
> For leaf certs, I agree with you and Phill that simulations should be
> run over many parameter variations.  But my gut feeling is that if the
> RP needs status information that is accurate to within some fixed
> limit, that pushing CRLs out to caches based on status events or
> refreshing the caches based on some acceptably fine nextUpdate
> resolution, partitioned by name and/or reason, will again prove to be
> more bandwidth and processor efficient than OCSP over a wide range of
> parameters.
> 

CRL pushing and event-driven publishing are interesting ideas that deserve
as much consideration as OCSP.  I was addressing the more traditional
CRL-in-a-repository approach that PKIX is working with, and those two
solutions sound just as plausible as OCSP.

My main concerns with (traditional) CRLs are their untimeliness and
inflexibility.  OCSP is one way to address those problems, although
serious concerns have been raised about the current proposal.  But call it
OCSP or CRL push or whatever, there needs to be a formal part of PKIX that
describes how to obtain and support timely revocation information.

> 
> > This is an interesting approach.  We have a proposal that may not scale
> > to a million under reasonable assumptions.  Let's do some simulation to
> > see whether it can scale to a billion...
> 
> As B&B would say:  "Heh heh heh heh ..."
> 

Isn't that usually something more like "Uh huh, uh huh, uh huh huh, uh
huh..."?  :)

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: [email-masked]
Date: Fri, 05 Dec 1997 15:34:59 -0700
To: "Arsenault, Al W." <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP

Al,

At 03:03 PM 12/5/97 -0500, Arsenault, Al W. wrote:
>One question on Marc Branchaud's posting:
>
>You wrote:
>>
>>The flaw is that the decision of when to release new revocation
>>information rests with the CA.  In other words, a relying party who needs
>>up-to-date revocation information in a CRL-only environment has to wait
>>for the next CRL to be published.  The relier has no power to influence
>>the CA into releasing revocation information earlier.
>>
>>OCSP allows the relier to get the revocation information when it's needed,
>>without being subject to the CA's CRL schedule.  Because CRLs can only be
>>released periodically, they are at best a compromise solution to the needs
>>of relying parties.
>
>In most models/products with which I am familiar, the only entity which
>can mark a certificate as revoked is the CA who signed it in the first
>place.

As an initial condition, I agree.  But especially in the commercial space
we should not discount the utility of delegation of this authority by
contract.

I would also further sharpen the focus by observing that the private key
used to sign the certificate need not be the same private key used to sign
the corresponding CRL or OCSP response.

>
>Given this, why is an OCSP any less subject to the CA's schedule than a
>CRL strategy? That is:
>	- the CA receives from some source a request to mark a certificate it
>issued as revoked.  Possibly the request comes from the user himself
>("My private key has been compromised..."); possibly by the user's
>supervisor ("She no longer works here ..."); possibly from the CA's
>management chain ("He didn't pay his bill; kill his certificate").  
>	- the CA takes some finite amount of time to decide whether or not to
>actually mark the certificate as revoked.  (Automatically accepting
>revocation requests without some sort of validation on them is an open
>invitation to denial of service attacks.)
>A conscientious CA who is
>worried about liability will do this quickly, but it may take a while to
>propagate results out.

The model should also take into account the presence of an RA.  Depending
on the relationship established between and RA and a CA, the CA could
perform automatically.  Responsibility for diligence in this instance rests
on the RA.  In these instances, the RA legitimately considers itself more
authoritative for subscriber status than the CA.  It is willing to enter
into an agreement with the CA to this effect.

>	- thus, the OCSP solution still leaves a "window of vulnerability"
>wherein the certificate may be bad but this information is not available
>to the user.  Yes, it's the CA who assumes the liability during this
>interval, but that's the same as the CRL case.

I would agree that even in the case of a self-empowered RA above, this
window still exists.  OCSP is not a magic oracle able to peer directly onto
the user's hardware token, her daily actions or the state of her status as
a trusted employee (for examples).  Such is an ideal, like the theoretical
random number generator of cryptographic academia.

>
>Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
>from one of his previous lives :-), and I recognize the limitations of
>CRLs.  They leave (sometimes very) large windows of vulnerability.  They
>can consume enormous amounts of bandwidth just being transferred across
>the network. They can cause significant workloads on the CA.  
>
>But let's be honest about this.  OCSP as it currently stands has some
>shortfalls.  As I pointed out above, there's still a window of
>vulnerability that extends until the CA actually agrees to mark the
>certificate as revoked. The protocol is vulnerable to replay, and denial
>of service related to replay.  

I would agree to the existance of window between event, report,
investigation and database marking.  Towards the replay issue though, I
believe we might be closer to a solution.  This is basically the
nonce-based argument.  I recently put to the list a proposal regarding an
optional OCSP nonce (with all due respect to the diligence of Ambarish, Bob
and Carlisle).

>
>Also, I think it's important to point out again:  OCSP is only good for
>answering one question:  "Does the CA who issued this certificate still
>stand behind it?"  That's not the same question as "Is this certificate
>valid right now?"  We need to recognize that, and make sure we all agree
>that that's what we want a protocol to do.

As noted, I see this more as difference between a Certificate Status Oracle
and that which is realistically achievable.  OCSP takes us much closer to
the CSO ideal than does CRLs.  Given a risk management model that is able
to accomodate contract-based protection, I believe we can get quite close
to a CSO.  We can close that window to an arbitrary degree of assurance.
In this case, parties reliant on a trusted third party's representations of
certificate validity may be at least as concerned with your first question
as with your second.

For organizations where contract-based risk management is not an option, I
would agree that OCSP fails to close the window quite as fully.

>
>			Al Arsenault
>	- I speak only for myself.  My opinions do not necessarily reflect
>those of my employer.
>>
>>
>
>

Date: Fri, 5 Dec 1997 14:45:58 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 5 Dec 1997, Carlisle Adams wrote:
> 
> Unfortunately, your "slightly different perspective" is no longer
> supported in the latest OCSP revision.  The OCSP response message now
> contains "produced_at" and "expires_on" fields.  Recall Mike's message
> to the list:
>

[ snip ]

> 
> So, it turns out that the CA still controls when new revocation
> information is released.  Furthermore,  the functionality you're looking
> for is actually supported in the Notary protocol...
> 

I agree that the current proposal is inadequate.

Also, the CA obviously and inevitably is the sole authority regarding how
and when new revocation information is released.  OCSP does not seek to
relieve the CA of that role.  Rather, it's an effort to allow the
information to be propagated as quickly as possible.  CRLs are inadequate
for two reasons:  1. They impose delays that are unnecessary and 
unacceptable to relying parties; and 2. Each relying party has its own
idea of what's acceptable.  The advantage of OCSP is that it overcomes
those deficiencies.

Finally, the Notary protocol, as a revocation-checking protocol, is hardly
an improvement over the proposed OCSP spec.  For instance, it makes no
mention of caching or user-interface issues.  Here's it's description of
certificate notarization (i.e. status checking) from the introduction:

   When notarizing a certificate, the NA verifies that the certificate
   included in the request is a valid certificate and determines its 
   revocation status at a specified time.  Again, it checks the full 
   certification path from the certificate signing entity to a trusted 
   point.  The NA may be able to rely on all relevant CRLs and ARLs, or
   the NA may need to supplement this with access to more current status 
   information for the CA.  It includes this information, along with a 
   trusted time, to create a Notary Token.  (See Appendix C.)

Appendix C provides some extra detail, but it doesn't contain anything
that would challenge Tim's analysis.  The Notary protocol may be an
improvement over the OCSP proposal, but it's hardly the functioanlity I'm
looking for.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 05 Dec 1997 11:09:00 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OCSP Considerations

Mike, sorry if I too negative. Sometimes it is difficult to know if someone
agrees with you but hasn't had time to say so, vs. is still thinking, vs.
disagreeing and/or ignoring you.  I appreciate the fact that we all have
other jobs to do as well.

With regard to your strawman proposal, my comments would be the following:

1.  I see no particularly good reason to avoid the use of ASN.1. Despite
some of its complexity, it provides a uniform way of documenting the
specifications that can be validated by use of a compiler (minimizing the
possibility of a misunderstanding). Anyone who is implementing any kind of a
PKI implementation is going to be up to their ears in ASN.1 -- a little more
won't hurt. But I wouldn't go to war on this issue.

2. Regardless of the ASN.1 decision, providing a means of easily extending
the protocol is absolutely vital. In particular, it is highly likely that
billing information will have to be conveyed in both directtions, and
ultimately a transaction value field as well.

3. Both the request and the response need to be signed, at least optionally,
and particularly if there is billing or other information associated.

4. I haven't studied the timestamping proposal, so I have no comment on the
use of an OID in this area.  It is sufficient, I believe, that the CA or
repository which is acting as an agent of the CA include the time, since in
most cases I believe that time per se will not be of critical importance.

5.  I don't see any particular utility in making the nonce field optional in
the request -- if someone is really convinced that they don't need it, they
can just fill in zeroes, without adding the addtiional complexity of
deciding whether or not it was included, and therefore whether it should be
included in the response.

7.  It would be nice, but perhaps not essential, to have something in the
request that specifically identifies the nonce as consisting of a message
digest (SHA-1 by default) of the date/time of the request concatenated with
the digital signature which is being validated by this OCSP request.

Regards,

Bob

>>> <[email-masked]> 12/04 6:23 PM >>>
Bob,

Actually, you are making headway, as have Richard Ankey, Carlisle, Ambarish
and others.  The fact is that when the sudden rush of interest and comment
on OCSP started pouring in--both on-list and off-list--I saw the whole
thing going down a long and slippery slope without due consideration given
to fundamental requirements.

I still firmly believe that simplicity is a fundamental requirement.  That
said, having now had the last few days to go back and digest the recent
input, I'm quite certain a specification of OCSP can be crafted that
strikes an acceptable compromise among the various positions.  For the
benefit of those who may not be able to make it to the IETF next week,
here's a strawman proposal:

1. Re-craft the request & response syntax (still non-ASN.1) to more
effectively enable extensibility without introducing implementation
complexity.  The current syntax is simply too rigid to do extensibility
cleanly.

2. Add an optional policy OID in alignment with the Timestamping proposal.
I would still recommend we go cautiously here.  Matching an OID should be
fairly straightforward for environments with a need; algorithmic models of
policy a la SPKI may never see the light of day.

3. Add an optional nonce for replay detection.  This could be included
within the scope of the extensibility mechanism.  I've never needed
convincing that nonces are good, but we do need to ensure that the final
OCSP solution enables one to make a choice whether or not to take full
advantage of the existing Internet infrastructure.

Regarding SSL, I agree with your observeration.  OCSP is signed content for
exactly the reason you note.  Technically, we should recognize however that
there exists nothing in the OCSP protocol model which inhibits use of SSL
for who wish to do so.

Mike

At 11:21 AM 12/3/97 -0700, you wrote:
>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>I don't think so.  Although I'm not making much headway in trying to get
>OCSP to be more responsive to the nonrepudiation requirement,
authenticating
>the responder via SSL would not provide any lingering proof of the the
>certificate's status.
>>
>>I am assuming here that the responder is tightly coupled to the CA.
>>If the responder's site certificate is revoked then the responder
>>itself would have to get disabled or updated by the CA.
>>
>>==========================================
>>Dan Laska
>>Frontier Technologies Corp.
>>Email: [email-masked] 
>>==========================================
>
>Bob
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Fri, 5 Dec 1997 14:12:17 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 5 Dec 1997, Arsenault, Al W. wrote:
> 
> Given this, why is an OCSP any less subject to the CA's schedule than a
> CRL strategy? That is:
> 	- the CA receives from some source a request to mark a certificate it
> issued as revoked.  Possibly the request comes from the user himself
> ("My private key has been compromised..."); possibly by the user's
> supervisor ("She no longer works here ..."); possibly from the CA's
> management chain ("He didn't pay his bill; kill his certificate").  
> 	- the CA takes some finite amount of time to decide whether or not to
> actually mark the certificate as revoked.  (Automatically accepting
> revocation requests without some sort of validation on them is an open
> invitation to denial of service attacks.)  A conscientious CA who is
> worried about liability will do this quickly, but it may take a while to
> propagate results out.
> 	- thus, the OCSP solution still leaves a "window of vulnerability"
> wherein the certificate may be bad but this information is not available
> to the user.  Yes, it's the CA who assumes the liability during this
> interval, but that's the same as the CRL case.
> 

CA processing delays certainly exist, but there are two separate issues
here:

1. When is a certificate considered Revoked?  When the CA receives a
notice of revocation, or when the CA marks the certificate as revoked?
That's a matter of semantics, though I would suggest that the latter
definition makes more sense than the former.  The CA is the final arbiteur
of certificate status.

2. Back with OCSP vs. CRL -- Both approaches are subject to the window o'
vulnerability you describe.  However, CRLs impose an additional window,
specifically the time until the next CRL is published.  OCSP avoids this
second window.

There's a difference between making the information available as fast as
possible and making it available on a regular schedule.  The CRL approach
gives the CA an opportunity to say "I've done everything I'm supposed to"
while the relying party is still left in the lurch.  OCSP would eliminate
these situations where a CA knows true revocation status internally, but
that information is hidden from the rest of the world.

> Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
> from one of his previous lives :-), and I recognize the limitations of
> CRLs.  They leave (sometimes very) large windows of vulnerability.  They
> can consume enormous amounts of bandwidth just being transferred across
> the network. They can cause significant workloads on the CA.  
> 
> But let's be honest about this.  OCSP as it currently stands has some
> shortfalls.  As I pointed out above, there's still a window of
> vulnerability that extends until the CA actually agrees to mark the
> certificate as revoked.

Agreed.  But I don't see how that can be avoided.  It takes a finite
amount of time to place a phone call, or flip a bit.  Physics limits us
all...

> The protocol is vulnerable to replay, and denial
> of service related to replay.  
> 

I agree here, too, in that the protocol as proposed is not what I envision
as a useful description of OCSP.  It glosses over too many details and 
leaves too many questions unanswered.

> Also, I think it's important to point out again:  OCSP is only good for
> answering one question:  "Does the CA who issued this certificate still
> stand behind it?"  That's not the same question as "Is this certificate
> valid right now?"  We need to recognize that, and make sure we all agree
> that that's what we want a protocol to do.
> 

This is an interesting, though separate, point.  What does "valid" mean
anyway?  From one perspective, the two questions you list are indeed the
same question, as a CA would revoke any certificate it no longer stands
behind, thus making it invalid.

On the other hand, it gets at the semantic debate I mentioned earlier.
When is a certificate no longer valid?  Is it the moment when the private
key is compromised, or is it when the CA revokes the certificate?
Unfortunately, the former is far more difficult to pin down than the
latter.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 05 Dec 1997 10:41:54 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Critical extensions and Policy OIDs

Dave,

So that we are all on the same page, let me refer you to the Oct 14th draft
of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:

"Applications with specific policy requirements are expected to have a list
of those policies which they will accept and to compare the policy OIDs in
the certificate in that list. If this extension is critical, the path
validation software must be able to interpret this extension, or must reject
the certificate."

So far so good, although the text tends to put too much emphasis on
applications deciding on their own what policy requirements they require and
will enforce, whereas I believe that such decisions will more often be made
by the MIS department and conveyed in the root-level certificate (issued by
the MIS department) which cross-certifies particular CAs and imposes any
necessary policy constraints on subsequent certificates.

Where the train jumps the track is in the following sentence of the
paragraph:

"(Applications without specific policy requirements are not required to list
acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"

This takes the issue well beyond that of a rogue application.  It says that
a PKIX standards-conforming application can ignore an attribute bearing a
Critical marking with impunity -- it doesn't have to even notify the user
that it saw something that it doesn't understand.

I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
Solo) to delete this sentence.

I think that we are in agreement that if someone goes out and buys an
application that is non-conforming, we aren't going to sic the Internet
police on him. I'm not trying to prevent anyone from building rogue
applications. However, if someone knowingly uses an application that does
not conform to the standard, or does not implement the Critical attribute
correctly, he has to accept the consequences of his actions, and both the CA
and the subscriber should be relieved of any liability that might result
from the relying party accepting some transaction that they should have
rejected, based on the policy OID and the Critical flag.

But if the standard itself says that such markings can be ignored with
impunity and still be considered as conforming to the standard, then the CA
and/or the subscriber haven't a leg to stand on, for they have no way to
ensure that effective legal notice is provided to any potential relying
party.

This sentence must be removed or clarified considerably before the standard
can be accepted, IMHO, for the concept of a Critical attribute is
fundamental to the entire concept of legal notice which the certificate is
supposed to provide.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

>>> <[email-masked]> 12/04 2:29 PM >>>
Bob, Mike,
 I agree completely with the importance of obeying critical extensions. But
I 
also believe that there will be "rogue applications" that may or may not
handle 
these extensions properly dependent on the specific application. For
example, 
if I have a certificate whose policy is explicitly for signing user 
certificates, someone may develop an application that allows me to use that 
certificate for applying for a credit card exclusively for CAs. The "relying

party" in this case accepts the risk in using that certificate despite the 
policy under which it was issued. If used improperly by these rogue 
applications, Mike is correct in saying that all CA (or other) liability is 
relieved. Hopefully, the relying party would have a difficult fight in court
if 
they wanted to blame the CA who issued that certificate. The point is that
we 
can only write the specifications, we cannot enforce them.

Cheers,
Dave Oshman

Price Waterhouse LLP
Electronic Commerce/Internet Practice
>Date:    Wed, 3 Dec 1997 08:34:05 -0700
>From:    Mike Smith <[email-masked]>
>Subject: Re: digitalSignature vs. nonRepudiation
>As usual, Bob, I find myself agreeing with your statements.
>
>A certificate is issued under a certain set of authority policies.  If
someone 
wishes >to rely on a certificate issued under those policies, then the
software 
they use must >be able to process all of the critical extensions established

under that policy or >not honor the certificate.
>
>If someone does accept a certificate or signature issued with critical 
extensions >that are ignored or interpreted other than the intent of the 
issuing CA, then, it is >my belief, the reliant party (and, possibly the
entity 
that modified the code to >accept or ignore the critical extensions) has
just 
relieved the CA of any and all >liability regarding that critical extension 
and, quite possibly, the whole >certificate's issued purpose.
>
>Michael
>
>>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all
of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say
that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the
critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                     

Date: Fri, 5 Dec 1997 16:54:37 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Encoding of INTEGER fields in PKIX certs

ASN.1 Folks,

I have the following certificate, which is intended for use
in the PKIX Certificate and CRL Profile examples draft.

There are several fields representing cryptographic bignums which
are encoded as INTEGERs: the DSA parameters p, q, and g; the
DSA public key y, and the DSA signature values r and s.

ASN.1 INTEGERS are encoded as two's-complement numbers, which
implies that if a BER-encoded value is decoded into a larger
native storage value, the high bit of the encoded value will be
sign-extended into the excess bits of the native value.
For cryptographic purposes, it is my understanding that bignums
are always the same size as the encoded values, so the issue
of sign extension never arises.  (Additionally, for cryptographic
algorithms using modular arithmetic with a 2^n modulus, any
sign-extended bits larger than the modulus are ignored - chopped
off in the modular reduction.)

With that in mind, is it ever necessary to do sign-bit protection
of BER-encoded INTEGERs (adding an extra 00 whenever the MSB of
the value is 1)?

In the following example, p and q each have MSB=1, and have the extra 00
octet added.  g and s have MSB=0, so no extra octet is needed.
The public key (y) and r both have MSB=1 and no extra octet, thus the
encoding of y and r is inconsistent with the encoding of p and q.

Since a distinguished encoding of these values is required, there MUST
be an encoding convention for whether to do sign padding when MSB=1.
Most of the cert examples I have seen do not do sign padding.

I believe that padding:

 * is always unnecessary,
 * is an added complication,
 * is seen less often than unpadded INTEGERS in existing certs, and
 * is inconsistent with the treatment of parameters encoded
      as BIT STRINGs or OCTET STRINGs, which are never padded

so I would prefer to document the convention that sign padding is not
to be used.

Questions:

 * Does a convention for sign padding of INTEGERs already exist anywhere?
 * Is there ever a need to do sign-extension of encoded INTEGERS
    (in which case padding would be necessary)?
 * Does anyone feel that sign padding is desirable, regardless of whether
    it is necessary?

If not, Part 1 should be amended to specify that compliant CAs SHALL
NOT generate padding 00 bytes for INTEGERs, and that verifiers SHOULD
accept both padded and unpadded INTEGERs.  And I will correct the
examples accordingly.

-----------------------------------------------------------------------

      Version: v3
Serial Number: 256
Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
   Parameters: NULL
       Issuer: C=US, O=gov, OU=nist
     Validity: Not Before 970609050000Z
               Not After  980609050000Z
      Subject: C=US, O=gov, OU=nist
SubjectPKInfo: id-dsa (1.2.840.10040.4.1)
   Parameters:
      p:
        00 93 e8 96 5d af d9 df ec fd 00 b4 66 b6 8f 90
        ea 68 af 5d c9 fe d9 15 27 8d 1b 3a 13 74 71 e6
        55 96 c3 7f ed 0c 78 29 ff 8f 83 31 f8 1a 27 00
        43 8e cd cc 09 44 7d c3 97 c6 85 f3 97 29 4f 72
        2b cc 48 4a ed f2 8b ed 25 aa ab 35 d3 5a 65 db
        1f d6 2c 9d 7b a5 58 44 fe b1 f9 40 1e 67 13 40
        93 3e e4 3c 54 e4 dc 45 94 00 d7 ad 61 24 8b 83
        a2 62 48 35 b3 1f ff 2d 95 95 a5 b9 0b 27 6e 44
        f9
      q:
        00 bb 5d fe 42 de 11 5c 00 db 5e f1 b0 38 83 44
        d6 c1 54 85 ad
      g:
        69 27 9f 8e ba b8 0e 8f 24 f0 18 46 21 96 63 6c
        4c 22 54 64 f0 13 3e 0f 2f 21 e7 bb ed 1d 85 3f
        06 eb 94 9a 86 85 0a 30 a9 b5 b2 ce a8 30 ea ad
        00 e7 bd f6 1e bc 81 cc 41 de ba ff 1b 5b fd 9f
        2a a4 b1 13 29 b1 3c 3d c6 95 11 27 fb c8 6b 4d
        35 33 82 3b f9 7a 58 de 2f f1 f9 c9 b3 17 7b a3
        49 4e d5 e0 00 38 3d bd 6a 69 9d 57 89 54 8f ce
        f5 07 36 8e 4b e6 6e eb 0f 08 75 73 8c bc fc c5
   Public Key:
        8b 20 50 88 00 73 c1 35 95 44 c5 5f ef b4 d8 08
        b8 8d 21 ec 91 06 6e 2e 8a a7 a8 92 97 75 2d fa
        87 f3 94 b7 72 3d 21 c8 5d 1e 3a 59 7a 6c c7 62
        5b 2f c5 bc ae ce 68 ad 52 85 6a 83 5c a6 43 7d
        d8 8e bc 7e ea 12 74 89 ec ad 89 fe 7a be fb fb
        2a 0e 2e 28 8d 92 a1 7a 67 3d b2 52 73 39 63 8f
        0f 79 c6 b2 f6 40 46 83 bf 62 6e 1c d2 25 b5 e5
        5a ff d1 ad 4d b3 bc cc 65 bd 08 04 4e 11 32 45
   Issuer UID: none
  Subject UID: none
   Extensions: 2
  Extension 1: Critical basicConstraints (2.5.29.19)
    CA = Yes, Pathlen = unlimited
  Extension 2: Critical keyUsage (2.5.29.15)
    Usage Bits= { keyCertSign cRLSign }
Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
   Parameters: NULL
Signature Value:
      r:
        b3 2d dd 5e c9 f6 6d a7 91 c0 3f aa e7 43 77 40
        f3 1f b1 64
      s:
        68 fd 1a 69 da 08 9c 27 9c 34 32 8b 43 23 cb d1
        84 13 32 ca

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 16:42:44 -0500

Hi Marc,

>----------
>From: 	Marc Branchaud[SMTP:[email-masked]]
>Sent: 	Friday, December 05, 1997 1:37 PM
>To: 	[email-masked]
>Subject: 	Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>I agree with Phill's comments below, and would like to add what I think is
>a slightly different perspective.
>
>OCSP is an attempt to address some of the flaws of the CRL model.  For the
>most part, the flaw with the most attention has been the untimeliness of
>CRL revocation information.  But there's another CRL flaw that deserves
>equal attention, and which isn't being properly addressed with the current
>OCSP discussion.
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

Unfortunately, your "slightly different perspective" is no longer
supported in the latest OCSP revision.  The OCSP response message now
contains "produced_at" and "expires_on" fields.  Recall Mike's message
to the list:

I've revised the OCSP draft on the basis of recent comments and debate.
Notice of its availability in all the usual places should be showing up
in
due course.  The revisions include:

- specification of HTTP 1.1 vs. 1.0
- elimination of the prior_to field in the request
- addition of a {produce_at, expires_on} interval in the response
- addition of requirements on the periodicity of pre-production of
responses

With the exception of the first one (which has to do with 1.0 being an
Informational document while 1.1 is Standards Track), the changes
address
the replay issue and scalability factors.

So, it turns out that the CA still controls when new revocation
information is released.  Furthermore,  the functionality you're looking
for is actually supported in the Notary protocol...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Fri, 5 Dec 1997 15:52:36 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

> From: Marc Branchaud <[email-masked]>
> 
> OCSP is an attempt to address some of the flaws of the CRL model.  For the
> most part, the flaw with the most attention has been the untimeliness of
> CRL revocation information.  But there's another CRL flaw that deserves
> equal attention, and which isn't being properly addressed with the current
> OCSP discussion.
> 
> The flaw is that the decision of when to release new revocation
> information rests with the CA.  In other words, a relying party who needs
> up-to-date revocation information in a CRL-only environment has to wait
> for the next CRL to be published.  The relier has no power to influence
> the CA into releasing revocation information earlier.

I don't see how OCSP with caching allows the relying party any more control
over the timeliness of revocation information than does CRL with caching.

Of course, if a particular CA publishes CRLs once per month, many RPs will
not find it sufficient.  But in the limit, there is no reason for CRLs
to be published more frequently than on an event-driven basis - a new
CRL issued every time the status of any covered certificate changes, or
whenever the nextUpdate field kicks in if there have been no intervening
status changes.

The CA (or CRL publisher) is the only entity authoritative for
revocation events, so it makes more sense for the CA to push updates
than for caching OCSP servers to decide to refresh based on some
necessarily arbitrary criteria.  In the case of all but leaf
certificates, it seems obvious that status-change events will occur
*far* less frequently than status queries, so the CRL push model is
more appropriate.

For leaf certs, I agree with you and Phill that simulations should be
run over many parameter variations.  But my gut feeling is that if the
RP needs status information that is accurate to within some fixed
limit, that pushing CRLs out to caches based on status events or
refreshing the caches based on some acceptably fine nextUpdate
resolution, partitioned by name and/or reason, will again prove to be
more bandwidth and processor efficient than OCSP over a wide range of
parameters.

> On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
> > 
> > OCSP supports a function call end clients make routinely: 'Is this
> > certificate valid'.

I thought we had already established that this was NOT the goal of
OCSP.  OCSP was presented as merely answering the question "Has this
certificate been revoked?", the example given being the need to cut off
people who demonstrate the danger of relying on MS Authenticode as an
applet privilege management mechanism.  (Silencing the messengers,
rather than fixing the problem, as it were.)

The question of certificate validity is far more complex.  It might be
somewhat useful to have a locally-administered validity server within a
small group of mutually-trusting machines, but it doesn't make much
(any?) sense to export that function outside of a single administrative
domain.

> From: Carlisle Adams <[email-masked]>
> 
> >To gain perspective on scaling issues I believe we should look at a billion
> >certificates or more rather than Tim's million. At least two applications
> >will involve this number of certificates:
> >
> >    * Credit card processing
> >    * Certificate based equities
> >
> >Both these scenarios are much smaller than systems I have previously helped
> >design, ZEUS and the Web. Simulation is the only way to prove viability of
> >such systems. I see OCSP as a usefull tool in meeting such challenges which
> >require a 'full toolbox'.
> 
> This is an interesting approach.  We have a proposal that may not scale
> to a million under reasonable assumptions.  Let's do some simulation to
> see whether it can scale to a billion...

As B&B would say:  "Heh heh heh heh ..."

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 15:03:48 -0500

One question on Marc Branchaud's posting:

You wrote:
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

In most models/products with which I am familiar, the only entity which
can mark a certificate as revoked is the CA who signed it in the first
place.

Given this, why is an OCSP any less subject to the CA's schedule than a
CRL strategy? That is:
	- the CA receives from some source a request to mark a certificate it
issued as revoked.  Possibly the request comes from the user himself
("My private key has been compromised..."); possibly by the user's
supervisor ("She no longer works here ..."); possibly from the CA's
management chain ("He didn't pay his bill; kill his certificate").  
	- the CA takes some finite amount of time to decide whether or not to
actually mark the certificate as revoked.  (Automatically accepting
revocation requests without some sort of validation on them is an open
invitation to denial of service attacks.)  A conscientious CA who is
worried about liability will do this quickly, but it may take a while to
propagate results out.
	- thus, the OCSP solution still leaves a "window of vulnerability"
wherein the certificate may be bad but this information is not available
to the user.  Yes, it's the CA who assumes the liability during this
interval, but that's the same as the CRL case.

Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
from one of his previous lives :-), and I recognize the limitations of
CRLs.  They leave (sometimes very) large windows of vulnerability.  They
can consume enormous amounts of bandwidth just being transferred across
the network. They can cause significant workloads on the CA.  

But let's be honest about this.  OCSP as it currently stands has some
shortfalls.  As I pointed out above, there's still a window of
vulnerability that extends until the CA actually agrees to mark the
certificate as revoked. The protocol is vulnerable to replay, and denial
of service related to replay.  

Also, I think it's important to point out again:  OCSP is only good for
answering one question:  "Does the CA who issued this certificate still
stand behind it?"  That's not the same question as "Is this certificate
valid right now?"  We need to recognize that, and make sure we all agree
that that's what we want a protocol to do.

			Al Arsenault
	- I speak only for myself.  My opinions do not necessarily reflect
those of my employer.
>
>

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 14:09:09 -0500

Hi Phill,

>----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	Friday, December 05, 1997 11:28 AM
>To: 	[email-masked]
>Subject: 	Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Re Tim Moses <[email-masked]> comments concerning the alledged 'non
>scalability of OCSP'.
>
>I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>First I note that Tim does not address scalability but the relative
>performance of OCSP and the Entrust approach under his chosen set of
>assumptions.

You seem to be misunderstanding something here.  "CRLs over HTTP" is not
the "Entrust approach"; it is a part of what was previously called
PKIX-2, as is OCSP.  The FTP/HTTP spec. was not authored by Entrust and
we had no contribution to it whatsoever.  Tim was simply comparing two
IETF PKIX drafts.

>Scalability is about  whether an architecture limits the size of the problem
>that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>assumes a big enough mainframe can be purchased.
>
>OCSP supports a function call end clients make routinely: 'Is this
>certificate valid'. It allows the function 'check every certificate in my
>address book' to be supported cleanly. Unless you want to either handle CRLs
>in the client or route all traffic through a central bottleneck OCSP is the
>obvious approach.

OCSP may seem like the obvious approach if it is viewed only from the
client end.  However, Tim's message pointed out that the CA supporting
this functionality appears to need a HUGE pipe to deliver this service.
I fully agree with your observation above:  scalability *is* about
whether an architecture limits the size of the problem that can be
handled.  In the case of OCSP, the architecture appears to do just that.

Note too, though, that scalability is not the only point of discussion.
The thrust of Tim's message is that CRLs (using distribution points)
over HTTP is the general solution, of which OCSP is one specific
instance.  Maybe it makes sense to standardize a general solution that
can be engineered to provide OCSP-like functionality if desired, or can
be engineered in any other desired way for other
requirements/environments.  Doesn't this sound like a reasonable thing
for an *Internet* PKI WG to do?

>To gain perspective on scaling issues I believe we should look at a billion
>certificates or more rather than Tim's million. At least two applications
>will involve this number of certificates:
>
>    * Credit card processing
>    * Certificate based equities
>
>Both these scenarios are much smaller than systems I have previously helped
>design, ZEUS and the Web. Simulation is the only way to prove viability of
>such systems. I see OCSP as a usefull tool in meeting such challenges which
>require a 'full toolbox'.

This is an interesting approach.  We have a proposal that may not scale
to a million under reasonable assumptions.  Let's do some simulation to
see whether it can scale to a billion...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-01.txt
Date: Fri, 05 Dec 1997 13:57:34 -0500
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers
	Filename	: draft-ietf-pkix-ocsp-01.txt
	Pages		: 7
	Date		: 04-Dec-97
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure
(PKI).  This document specifies an HTTP-based application protocol use-
ful in determining the current status of a digital certificate without
the use of CRLs.  Additional mechanisms addressing PKIX operational re-
quirements are specified in separate documents.
 
Please send comments on this document to the [email-masked] mail
list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ocsp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ocsp-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID:	<[email-masked]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Ishmael:Get I-D ACTION-draft-ietf-pkix- (EuSn/CSOm) (00004EA5)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Ishmael:Get draft-ietf-pkix-ocsp-01.txt (AURL/Arch) (00004EA6)
Content-Type: text/plain
Content-ID:	<[email-masked]>

Date: Fri, 5 Dec 1997 10:37:20 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP

-----BEGIN PGP SIGNED MESSAGE-----

I agree with Phill's comments below, and would like to add what I think is
a slightly different perspective.

OCSP is an attempt to address some of the flaws of the CRL model.  For the
most part, the flaw with the most attention has been the untimeliness of
CRL revocation information.  But there's another CRL flaw that deserves
equal attention, and which isn't being properly addressed with the current
OCSP discussion.

The flaw is that the decision of when to release new revocation
information rests with the CA.  In other words, a relying party who needs
up-to-date revocation information in a CRL-only environment has to wait
for the next CRL to be published.  The relier has no power to influence
the CA into releasing revocation information earlier.

OCSP allows the relier to get the revocation information when it's needed,
without being subject to the CA's CRL schedule.  Because CRLs can only be
released periodically, they are at best a compromise solution to the needs
of relying parties.

Of course, OCSP can't be used in all situations.  A caching mechanism is
needed to relieve bandwidth pressures.  But CRLs are poor candidates for
a caching mechanism, because they still dictate to relying parties when
their caches can be refreshed.

It is crucial that relying parties get the revocation information they
need when they need it.  To accomplish that, CRLs need to be avoided
entirely.  Instead, relying parties should cache OCSP responses, and
decide for themselves when to refresh their caches.

Luckily, it's easy to charge for an OCSP query.  So we have the makings of
a self-regulating system.  Parties who need real-time revocation
information can pay for it.  On the other hand, once I find the validity
of my buddy's email signature certificate it's unlikely that I'll feel a
desperate need to refresh that validity information every time I read one
of his messages.  Especially if I have to pay $x every time I do so.

The point is that in order to allow CAs to serve the widest community of
users, they need to be flexible enough to properly serve those users'
needs.  CRLs simply do not provide the required flexibility.

The OCSP proposal, as it stands, is also inadequate.  Along with the OCSP
specification, we need a description of the caching mechanism, which can
be simple, but is definiately required.  We also need to define user
interface behavior, because real people are ultimately the relying
parties in most of the situations we want to support.  By this I mean that
we need to explain that the users must be shown the ages of the satuses
(stati?) of the certificates they're about to rely on, and they must be
given the opportunity to refresh that status if they desire.

OCSP only becomes viable with proper caching and user interaction. 
Otherwise, it's a tool without an instruction manual.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
> 
> Re Tim Moses <[email-masked]> comments concerning the alledged 'non
> scalability of OCSP'.
> 
> I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
> First I note that Tim does not address scalability but the relative
> performance of OCSP and the Entrust approach under his chosen set of
> assumptions.
> 
> Scalability is about  whether an architecture limits the size of the problem
> that can be handled. e.g. resource requirements scale O(n^2)or worse or it
> assumes a big enough mainframe can be purchased.
> 
> OCSP supports a function call end clients make routinely: 'Is this
> certificate valid'. It allows the function 'check every certificate in my
> address book' to be supported cleanly. Unless you want to either handle CRLs
> in the client or route all traffic through a central bottleneck OCSP is the
> obvious approach.
> 
> To gain perspective on scaling issues I believe we should look at a billion
> certificates or more rather than Tim's million. At least two applications
> will involve this number of certificates:
> 
>     * Credit card processing
>     * Certificate based equities
> 
> Both these scenarios are much smaller than systems I have previously helped
> design, ZEUS and the Web. Simulation is the only way to prove viability of
> such systems. I see OCSP as a usefull tool in meeting such challenges which
> require a 'full toolbox'.
> 
>         Phill

Date: Fri, 5 Dec 1997 12:37:40 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: draft-ietf-smime-crs-00.txt

Mike,
   With respect, I've admitted to you and others privately that I find
the *document describing* CMP which is now in Last Call to be overly
complex.  But I fail to understand why you refuse to make your proposal
compatible with the CMP protocol itself, which in it's minimal form,
is not that complex.

> There is a serious disconnect here which no amount of artful optional
> syntax will repair and we might as well admit it.

There is a disconnect in someone's understanding, perhaps mine.  But
IMHO the "artful optional syntax" is not an attempt to repair anything,
it is the fundamental design principle which enables one to start small
and add on later.  Stripped of everything optional, CMP can be
described in just a few lines:

    PKIMessage ::= SEQUENCE {
        header    PKIHeader,
        body      PKIBody  }

    PKIHeader ::= SEQUENCE {
        pvno      INTEGER,
        sender    GeneralName,
        recipient GeneralName }

    PKIBody ::= SEQUENCE {
        p10cr     [4] CertificationRequest }  -- PKCS#10 certification request*

Are you claiming that adding one integer, two names, and a couple of
nested SEQUENCEs to PKCS #10 is so much of a burden that S/MIME
developers, toolkit vendors, and CAs will be unable to accomplish it
within the next release cycle?

As Blake said, if there is something wrong with this tiny bit of
required CMP syntax, then suggest that it be fixed.  Otherwise, just
get about the business of writing your draft describing a minimal cert
request syntax in a manner that is compatible with CMP, instead of
insisting on a non-extensible alternative with no future growth path.

> The issues and forces are readily apparent.  If x% of the PKI-using
> community does something other than CMP for their own internal reasons,
> then at some value of x we must perform a reality check.  I would claim the
> current value of x far exceeds this threshold.

Reality check: 100% of browser vendors do not support TLS in their
current products.  Yet I don't see that being used as an argument claiming
that the IETF must write a Standards Track protocol that enshrines
SSL v3.0 as a permanent parallel alternative to TLS 1.0.  One Standard
is enough - implementations are always free to support as many additional
non-standard or de-facto standard options as business needs dictate.

-------------
* as an aside, I'll express my opinion that using the CMP "cr" message
  and eliminating the redundant "p10cr" message would also not be a
  major burden for developers, and would have the benefit of simplifying
  the codebase.  But in the spirit of compromise, I won't
  argue for that here. 

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 11:28:59 -0500

Re Tim Moses <[email-masked]> comments concerning the alledged 'non
scalability of OCSP'.

I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
First I note that Tim does not address scalability but the relative
performance of OCSP and the Entrust approach under his chosen set of
assumptions.

Scalability is about  whether an architecture limits the size of the problem
that can be handled. e.g. resource requirements scale O(n^2)or worse or it
assumes a big enough mainframe can be purchased.

OCSP supports a function call end clients make routinely: 'Is this
certificate valid'. It allows the function 'check every certificate in my
address book' to be supported cleanly. Unless you want to either handle CRLs
in the client or route all traffic through a central bottleneck OCSP is the
obvious approach.

To gain perspective on scaling issues I believe we should look at a billion
certificates or more rather than Tim's million. At least two applications
will involve this number of certificates:

    * Credit card processing
    * Certificate based equities

Both these scenarios are much smaller than systems I have previously helped
design, ZEUS and the Web. Simulation is the only way to prove viability of
such systems. I see OCSP as a usefull tool in meeting such challenges which
require a 'full toolbox'.

        Phill

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: LDAP v3 authentication
Date: Fri, 5 Dec 1997 10:22:23 -0500

Let's make sure PKIX requirements (assuming we have some) are input to
this effort.
------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	December 5, 1997 9:23 AM
>To: 	[email-masked]
>Subject: 	LDAP is approved!
>
> 
>After a long discussion, the IESG has decided to approve LDAPv3.
>That's good news - BUT:
>
>The IESG also requested (as you can see) that the spec be supplemented
>as soon as possible with a Proposed Standard for mandatory-to-implement
>authentication in LDAPv3, so that one could approach the prospect
>of an Internet-accessible read-write directory with a joyous heart
>rather than with trepidation and noninteroperability.
>
>Congratulations - and let's start working!
>
>               Harald A
>
>

From: The IESG <[email-masked]>
To: Unknown User <Unknown User>
Cc: RFC Editor <[email-masked]>, Internet Architecture Board
	 <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Protocol Action: Lightweight Directory Access Protocol (v3) to Proposed Standard
Date: Fri, 5 Dec 1997 08:14:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The IESG has approved the following Internet-Drafts as Proposed
Standards:

 o Lightweight Directory Access Protocol (v3)
	 <draft-ietf-asid-ldapv3-protocol-09.txt>

 o Lightweight Directory Access Protocol (v3):  Attribute Syntax
   Definitions
	<draft-ietf-asid-ldapv3-attributes-08.txt>

 o Lightweight Directory Access Protocol (v3): UTF-8 String
   Representation of Distinguished Names
	<draft-ietf-asid-ldapv3-dn-04.txt>

 o The String Representation of LDAP Search Filters 
	<draft-ietf-asid-ldapv3-filter-03.txt> 

 o The LDAP URL Format <draft-ietf-asid-ldapv3-url-04.txt> 

 o A Summary of the X.500(96) User Schema for use with LDAPv3 
	<draft-ietf-asid-ldapv3schema-x500-04.txt> 

 These documents are the product of the Access, Searching and Indexing
 of Directories Working Group.  The IESG contact person(s) are Harald 
 Alvestrand & Keith Moore.

Technical Summary
 
   The protocol described in this document is designed to provide access
   to directories supporting the X.500 models, while not incurring the
   resource requirements of the X.500 Directory Access Protocol (DAP).

   It is an improvement over the earlier LDAP version 2 that includes
   consistent character set handling, cleaner security, the possibility
   of handing back referrals to other servers, and extensibility.

Working Group Summary

   The ASID WG had rough consensus on this set of documents, the
   roughness being mostly in the area of what functionality to include
   in or exclude from the core protocol.
   There was consensus on the selection presented here.

Protocol Quality

   The protocol has been reviewed for the IESG by Chris Weider and
   Harald Alvestrand. Multiple implementations exist of both clients
   and servers.

Note To RFC Editor:

The IESG requests the following note be included:

IESG NOTE: This document describes a directory access protocol that
provides both read and update access.  Update access requires secure
authentication, but this document does not mandate implementation
of any satisfactory authentication mechanisms.

In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this limitation,
for the following reasons:

a. to encourage implementation and interoperability testing of
   these protocols (with or without update access) before they
   are deployed, and

b. to encourage deployment and use of these protocols in read-only
   applications.  (e.g. applications where LDAPv3 is used as
   a query language for directories which are updated by some
   secure mechanism other than LDAP), and

c. to avoid delaying the advancement and deployment of other Internet
   standards-track protocols which require the ability to query, but
   not update, LDAPv3 directory servers.

Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according
to this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.

Implementors are hereby discouraged from deploying LDAPv3 clients
or servers which implement the update functionality, until a
Proposed Standard for mandatory authentication in LDAPv3 has been
approved and published as an RFC.

From: Peter Whittaker <[email-masked]>
To: "'IETF PKIX'" <[email-masked]>
Cc: "'Bancroft Scott'" <[email-masked]>, "'Harald T Alvestrand'" <[email-masked]>, "'David P. Kemp'" <[email-masked]>, Sharon Boeyen <[email-masked]>, Carlisle Adams <[email-masked]>, Tim Moses <[email-masked]>
Cc: "'Phillip H. Griffin'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: Character sets in PKIX and X.509 (RE: [IETF-PKIX] Objections to IPKI3CMP charset handling)
Date: Fri, 5 Dec 1997 09:48:04 -0500

On November 21, Harald Alvestrand posted to this listed comments on
character set handling in PKIX.  His objections centered around the
definition of PKIFreeText as a CHOICE between IA5String and BMPString:
this was seen as problematic for the following reasons:

1) It is not compatible with current thinking on charset policy, as
specified in draft-alvestrand-charset-policy-02.txt, currently in Last
Call for BCP.

2) The BMPString encoding of 10646 is a particularly bad choice, since
ISO has stated intent of adding characters to 10646 outside the BMP
range, which cannot be represented there. (BMPString is not the same
thing as UTF-16, another ISO proposal)

3) The use of CHOICE for this important construct makes "shorthand
implementation" handling only one branch of the CHOICE all too likely.

Another area of concern was the rules currently in the PKIX I-Ds
concerning how to decide what character set to use (use Printable if the
character fits, if it doesn't, use BMP if it fits, if it doesn't use
Universal;  they're longer than this, but you get the idea).  One major
concern here was why a CA should be constrained to follow those rules
when its operating environment requires the use of BMP or Universal,
with strings encodable in Printable being but a minority.

Harald's post lead to a debate and exchange of information, mostly
off-line, that came to involve Bancroft Scott, the ISO ASN.1 Rapporteur
(chair of the ASN.1 WG), Hoyt Kesterson, the ISO X.500 Rapporteur,
Harald, Phillip Griffin, Carlisle Adams, and others.

>After some debate and sharing of information, it was pointed out that
>UTF8String is now a recognized ISO character set.  It was suggested that this
>character set be used within PKIX when defining string data and that it be
>added to the DirectoryString choice in X.500.  The X.500 Rapporteur agreed to
>do so.  This means that we now have an efficient character set - efficient in
>terms of encoding - capable of reprensenting every human language, and
>possibly a few extra-terrestrial ones (to use the example provided by the
>ASN.1 Rapporteur).

The implication of this is that in the near future, though not
immediately, UTF8String will be a valid member of the DirectoryString
choice.  This should simplify the lives of implementors as they need
only deal with a single character set, UTF8String.

Harald then made the following suggestions:

>I distrust solutions which change other people's specifications.
>
>In the ideal world, ISO/ITU-T would add UTF8String to DirectoryString,
declare all other variants to be "for backwards compatibility only", and
we would halt all work with certificates until the world implemented
>that :-)
>
>In this imperfect world, with people overeager to push products "whether it
>works or not", it seems to me that the best thing to do is:

>- Declare that PKIX sees the future as UTF8String
>- Declare that PKIX will use UTF8String and only UTF8String wherever possible
>(there's no reason for either PrintableString or IA5String when you have
>UTF8String; the only difference is limits on the charset, which can also be
>expressed as a constraint on the UTF8String)
- Refer to X.509 as an external specification, and state that you expect
>to see UTF8String here in the next version, once ISO/ITU gets its work done.
>- Encourage use of BMPString as long as UTF8String is illegal (it's the type
>that gives the least problems with conversions <-> UTF8String)
>
>Seems reasonable?
>
>                     Harald A
>
>PS: The reason not to just modify X.509 is that occasionally, a PKIX
>certificate will be handed to an X.509-only device. Ouch....

>Further to Harald's suggestions, I would add the following:  that PKIX
>applications MUST be prepared to receive UTF8String, even in X.500-defined
>data, and that PKIX applications MAY use UTF8String in X.500-defined data,
>though they MUST be able to support BMPString as an alternative in order to
>interoperate with non-PKIX X.509 applications (presuming that this is
>important).

These allow us to redefine PKIFreeText as UTF8String and only as
UTF8String.  Furthermore, with appropriate language, we can specify the
use of UTF8String everywhere, with a fall-back to BMPString when
interoperability with non-IPKI applications is required, simplifying the
character set choice rules.

>If so desired, I can supply all of the relevant mail messages (though not in
>a nice digest format or anything like that, my mail system does not provide
>that service :-<).

One issue that has been raised about the use of UTF8String is the
question of what level of ASN.1 support it requires ('88, '94, '9x with
x > 4, '2x?), and how it affects current ASN.1 compilers.   UTF8String
may be the right thing to do, but may pose challenges in this area
(compounding the problem of widespread use of ASN.1 1988 throughout IETF
work, despite the superiority and clarity of ASN.1 1994).

Thoughts, comments, objections?

>pww
>

From: [email-masked]
To: [email-masked]
Date: Thu, 4 Dec 97 16:29:24 EST
Subject: Re: digitalSignature vs. nonRepudiation

Bob, Mike,
 I agree completely with the importance of obeying critical extensions. But I 
also believe that there will be "rogue applications" that may or may not handle 
these extensions properly dependent on the specific application. For example, 
if I have a certificate whose policy is explicitly for signing user 
certificates, someone may develop an application that allows me to use that 
certificate for applying for a credit card exclusively for CAs. The "relying 
party" in this case accepts the risk in using that certificate despite the 
policy under which it was issued. If used improperly by these rogue 
applications, Mike is correct in saying that all CA (or other) liability is 
relieved. Hopefully, the relying party would have a difficult fight in court if 
they wanted to blame the CA who issued that certificate. The point is that we 
can only write the specifications, we cannot enforce them.

Cheers,
Dave Oshman

Price Waterhouse LLP
Electronic Commerce/Internet Practice
>Date:    Wed, 3 Dec 1997 08:34:05 -0700
>From:    Mike Smith <[email-masked]>
>Subject: Re: digitalSignature vs. nonRepudiation
>As usual, Bob, I find myself agreeing with your statements.
>
>A certificate is issued under a certain set of authority policies.  If someone 
wishes >to rely on a certificate issued under those policies, then the software 
they use must >be able to process all of the critical extensions established 
under that policy or >not honor the certificate.
>
>If someone does accept a certificate or signature issued with critical 
extensions >that are ignored or interpreted other than the intent of the 
issuing CA, then, it is >my belief, the reliant party (and, possibly the entity 
that modified the code to >accept or ignore the critical extensions) has just 
relieved the CA of any and all >liability regarding that critical extension 
and, quite possibly, the whole >certificate's issued purpose.
>
>Michael
>
>>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob

From: [email-masked]
Date: Thu, 04 Dec 1997 19:24:25 -0700
To: [email-masked], [email-masked]
Subject: RE: draft-ietf-smime-crs-00.txt

Blake,

At 02:53 PM 12/4/97 -0800, you wrote:
>>On Tuesday, December 02, 1997 7:07 AM, [email-masked]
>>[SMTP:[email-masked]] wrote:
>>> 
>>> If this working group takes on this task, (I think it would be more
>>> appropriate within the PKIX WG, but like Mike, don't have any strong
>>> objection to pursuing it here - many of the participants are members
>>> of both groups), then it MUST ensure that the result is compatible
>>> with PKIX, not an independent and incompatible protocol based on
>>> straight unmodified PKCS#10.
>>
>>I agree.  This whole thing has caught me kind of off guard as a behind
>>the scenes effort.  I am still trying to sort out the spec and figure
>>out what exactly can't be accomplished with existing protocols
>>(specifically CMP) by constraining those protocols to fit in our
>>profile, and/or modifying them to fix any shortcomings that make them
>>unsuitable for our profile (non-persistent connections, etc.)

Well, the draft *was* available for public review and comment since August.
 Following Munich, those who were interested in seeing the initiative move
forward provided input.  I would have preferred to develop a broader
consensus during this summer's workshops, but there quite obviously wasn't
time given the more fundamental questions facing the SMIME developer
community.

>>
>>> Note the key last sentence - "an interpretation of PKIX-3 messages over
>>> PKCS7".  This means that any usage of PKCS#10 certificate requests MUST
>>> be in the form of PKIX-3 "p10cr" messages, in order to allow implementors
>>> to quickly develop "Basic functionality" certificate request messages
>>> based on existing technology, while remaining compatible with, and
allowing
>>> smooth migration to, the "Full functionality" (and more difficult to
>>> implement) CMP.
>>
>>I agree, and this option was discussed in an earlier thread also I
>>believe.
>>
>>> If this WG adds a certificate request work item to it's charter, it
>>> should be clearly stated that the result must be compatible with
>>> PKIX CMP, not an independent, non-interoperable syntax based on raw
>>> PKCS#10.
>>
>>If there are problems with CMP then we should fix them.  Coming up with
>>a new protocol is fun, but I think it fragments the effort.

I wouldn't necessarily call this fun.  I'm not fond of waving the reality
flag but it's something that needs to be done.  There is a serious
disconnect here which no amount of artful optional syntax will repair and
we might as well admit it.

>>I will read
>>the CRS spec more closely to find out what the differences are, but I
>>think that CMP can be fixed to satisfy our needs.
>>From my understanding, CMP is in last call, but I really think we should
fix it
>>right, and I think that "right" means fixing CMP if it is broken and
>>can't be used for S/MIME.

I proposed in Munich, with Tim Polk's support, a restructuring of CMP that
was vectored towards accomodating the consensus of all PKIX members.  It
was felt however that further delay of CMP towards Last Call would not
speak well of the WG.  Fine, that's the consensus and consensus rules.
However, a successful Last Call does not eliminate the market, partner and
customer needs I and others face daily.  It merely ratifies the content of
a document.

At this point I'm much more concerned about whether that document gets
reduced to practice in a scale equivalent to the SMIME and SSL efforts.  As
an early reader of Part 3, I was hopeful that would be the case.  Given my
current perspective, I am not at all confident this will occur in any way
close to the scale we thought it would.

>>There may certainly be issues and forces at work here that I don't
>>understand, and someone should feel free to correct me if I am too
>>unenlightened to see the value in having a separate incompatible
>>specification instead of a profile constraint on (potentially modified)
>>PKIX CMP.

The issues and forces are readily apparent.  If x% of the PKI-using
community does something other than CMP for their own internal reasons,
then at some value of x we must perform a reality check.  I would claim the
current value of x far exceeds this threshold.

The fact is version N+1 of a software products contains incremental
improvments over version N; this includes PKI clients.  No one has managed
to convince me this fundamental rule of product development will be ignored
simply to accomodate CMP where alternative solutions are provably working
and interoperating.  Despite CMP's Last Call, I'm compelled to inform the
working group that it fails to address the needs of a large percentage of
the PKI-development community.  I and a few others have a suggestion on how
to deal with this issue.

With respect,
Mike

From: [email-masked]
Date: Thu, 04 Dec 1997 18:23:35 -0700
To: [email-masked]
Subject: OCSP Considerations

Bob,

Actually, you are making headway, as have Richard Ankey, Carlisle, Ambarish
and others.  The fact is that when the sudden rush of interest and comment
on OCSP started pouring in--both on-list and off-list--I saw the whole
thing going down a long and slippery slope without due consideration given
to fundamental requirements.

I still firmly believe that simplicity is a fundamental requirement.  That
said, having now had the last few days to go back and digest the recent
input, I'm quite certain a specification of OCSP can be crafted that
strikes an acceptable compromise among the various positions.  For the
benefit of those who may not be able to make it to the IETF next week,
here's a strawman proposal:

1. Re-craft the request & response syntax (still non-ASN.1) to more
effectively enable extensibility without introducing implementation
complexity.  The current syntax is simply too rigid to do extensibility
cleanly.

2. Add an optional policy OID in alignment with the Timestamping proposal.
I would still recommend we go cautiously here.  Matching an OID should be
fairly straightforward for environments with a need; algorithmic models of
policy a la SPKI may never see the light of day.

3. Add an optional nonce for replay detection.  This could be included
within the scope of the extensibility mechanism.  I've never needed
convincing that nonces are good, but we do need to ensure that the final
OCSP solution enables one to make a choice whether or not to take full
advantage of the existing Internet infrastructure.

Regarding SSL, I agree with your observeration.  OCSP is signed content for
exactly the reason you note.  Technically, we should recognize however that
there exists nothing in the OCSP protocol model which inhibits use of SSL
for who wish to do so.

Mike

At 11:21 AM 12/3/97 -0700, you wrote:
>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>I don't think so.  Although I'm not making much headway in trying to get
>OCSP to be more responsive to the nonrepudiation requirement, authenticating
>the responder via SSL would not provide any lingering proof of the the
>certificate's status.
>>
>>I am assuming here that the responder is tightly coupled to the CA.
>>If the responder's site certificate is revoked then the responder
>>itself would have to get disabled or updated by the CA.
>>
>>==========================================
>>Dan Laska
>>Frontier Technologies Corp.
>>Email: [email-masked]
>>==========================================
>
>Bob
>
>

Date: Thu, 04 Dec 1997 12:00:22 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: PKIX naming conventions and schema

Michael, X.500 per se does not define ANY schema for DNs. That is one of the
things we were trying to do in the late lamented NADF.

X.520 does provide some oxymoronic "useful" definitions, that most people
(including the NADF) found were not in fact very useful, but nothing in
X.500, X.509, or so far in PKIX would either restrict or require the use of
any particular attribute, either public or proprietary, as an RDN component
of a DN.

As I recently commented on the spki list, there is nothing in any of these
standards that would prevent me from including a 1 gigabit MPEG movie of me
playing with my cat as one of the RDN components of the DN in my
certificate. The fact that doing that would be rather brain-dead, would
probably blow up the CA software that is issuing the certificate, and would
severely limit interoperability with browsers and other certificate-aware
software, not to mention LDAP and the search and browse efficiency of
various directory implementations, is sufficient reason why we should
attempt to profile a set of acceptable RDN attributes.

I am somewhat less concerned about profiling subjectAltname attribute
schemas, just because they were provided as a form of escape clause, and we
don't yet know which ones will be useful. It isn't that it won't eventually
be needed, just that it is premature at present. In particular, it isn't yet
apparent whether subjectAltnames will be browsed for in conventional
directories where schema issues are particularly important.

In checking the definition of the DN is part01, I was interested to find in
4.1.2.6 the statement, "Where it is non-null, the subject name field shall
contain an X.500 distinguished name (DN). the DN must be unique for each
subject entity certified by the one CA as defined by the issuer name field.
(A CA may issue more than one certificate wioth the same DN to the same
subject entity.)"

I interpret that to mean that if you really want to have a globally
unambiguous DN, for example to include in your global X.500 directory, it
may be necessary to invent a DN that is a composite of the issuer name and
the subject name, and insert that name rather then the DN in the certificate
in the directory.  That of course would be rather awkward -- it would be
preferable if that kind of name subordination were included in the
certificate DN originally.

I understand the difficuty of coordinating between CAs to ensure globally
unique names, but allowing names to be local to a CA without specifically
indicating that would seem to have to have some serious consequences..

I question whether this is really what we want.  If it is not possible to
use a DN that is inherently unique, then either name subordination or some
other technique should be used to specifically include the CA in the scope
of the name. Alternatively, some unique CA OID can be used in combination
with a subjectUniqueID and included as a component of a DN to make the DN
globally unambiguous.

This one sentence in 4.1.2.6 threatens to have serious implications with
respect to both existing and proposed legislation (which generally assumes
that a DN in a certificate is globally unambiguous), as well as potentially
hindering interoperability with various directory implementations, including
LDAP.

I think we ought to revisit this issue as part of the schema discussions
forthcoming  at the Washington meeting.  I wish I could be there.

Bob

>>> Mike Smith <[email-masked]> 12/03 8:36 AM >>>
Maybe I'm missing something with the X.500 compatibility issue and X.509
certifcates.  I thought that, with version 3, X.500 is just one schema tht
the X.509v3 certificate processing systems should be "backward compatible"
with.

Michael

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 04 Dec 1997 12:17:41 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Moot issues

Carlisle,
>
>My thesaurus entry for "moot" says that the following are synonyms:
>controversial, contestable, debatable, arguable, disputable,
>questionable, dubious, disputed, doubtful.

You need a better thesaurus.

The most common usage of the word is as given in the American Heritage
Dictionary:

2 a. (Law) Without legal significance, through having been previously
decided or settled. 

b. Of no practical importance.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 04 Dec 1997 14:01:36 -0800
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
To: Robert Zuccherato <[email-masked]>, [email-masked], [email-masked], [email-masked]
CC: IETF PKIX <[email-masked]>, Roger Romano <[email-masked]>
Subject: Re: [IETF-PKIX] Adding Certified NTP as a possible standard forportable trust innetworking systems

Robert,
thanks for replying so promptly and pardon my long winded reply but this is a
technology I am passionate about.

The intent behind the appliance style NTP based timestamp/concept is that it creates a
politically correct or neutral mechanism to have certified time available. What I mean
is available for all timestamping use models within the vertical WG's... Sort of a
horizontal enablement for the vertical WG's.

The reasoning is that it is not only PKIX and SPKI WG's that need certifiable
timestamping, but also CAT, AFT, and RoamOps as well will make use of reliable
timestamps. They can use these for their policy and service standards as well as
connection management and event signaling. In addition, certified time has value in
Telecom for backbone synchronization and other networking operations functions. In
electronic Commerce as a whole it is invaluable.

Now, we in the PKIX-WG are clear on the need for Certified Timestamping in transaction
processing and especially nonrepudiated event logging, hence the PKIX #7 timestamping
extensions. For us these technologies are the basis of a way to convey portable-trust
and proofing services. These services by the way, [IMHO] are the gating items to
getting the business-to-business folks and the Fed's to accept our solutions!. There is
also another reason for settling on a NTP style stamping infrastructure. This is
because it is useful to all. This means that we won't need twenty different solutions
for sources of certified time to answer requirements from the varied use models that
are emerging all throughout the IETF. Our reasoning and intent for this is to pre-empt
the multitude of independent standards that will rise from each WG doing it's own
certified time source and timestamp infrastructure...

So many times we have created methods so particular to one use model that when a new
requirement emerged we redesigned the wheel from scratch thus complicating the process
ad infinitum. Certified NTP Timestamping is an attempt to do the right thing. To create
a public resource specific to all of us in the PKI arena that also enables our brethren
in the other WG to leverage our creativity.

Thanks for letting me soapbox and see you in DC.

Todd

Robert Zuccherato wrote:

> Hi Todd;
>
> Some of us in the PKIX working group have been working on a time stamp
> protocol for a few months now.  Our revised draft is available at:
> ftp://ds.internic.net/internet-drafts/draft-adams-time-stamp-00.txt
> The working group will be deciding (hopefully) at the upcoming meeting
> whether or not this work belongs within PKIX.
>
> Robert Zuccherato
> Entrust Technologies
>
> >----------
> >From:  Todd Glassey[SMTP:[email-masked]]
> >Sent:  Thursday, December 04, 1997 12:40 PM
> >To:    [email-masked]
> >Subject:       [IETF-PKIX] Adding Certified NTP as a possible standard forportable
> >trust innetworking systems
> >
> ><<File: vcard.vcf>>
> >Hi all,
> >I want to propose the consideration of
> >using a certified NTP timestamp as the
> >basis of a portable trust model and
> >nonreputiead network timing. We and many
> >others in the associated IETF WG's have
> >long known the value of digital
> >timestamps for fixing a point of
> >reference to an event. Consider the
> >value if the source of the timestamp and
> >it's facility can be verified and
> >proffered as a certified network entity.
> >This is the birth of truly nonrepudiated
> >events and their logging.
> >
> >This capability brings a whole new light
> >to the world of certificates and
> >networking policy. Imagine email with
> >built-in timestamping and nonrepudiated
> >logging. Especially if combined with the
> >automated reply services now proposed
> >for SMTP. This timestamping technology
> >goes a tremendous way to enabling the
> >collapsing of human commerce models into
> >the digital domain.
> >
> >The use models of the NTP supplied
> >timestamps will fit in all groups
> >standards efforts, but especially are of
> >interest to the PKIX WG. These
> >timestamping extensions without any real
> >sweat enable the PKIX #7 Time Extensions
> >directly. Thus the settling on certified
> >NTP as the basis of the timestamp source
> >creates a horizontal technology that is
> >directly applicable to a number of IETF
> >and other Standards Working Groups
> >including those of ANSI, The ABA, and
> >the SEC. All in all it makes sense for
> >everyone in our mind.
> >
> >To this end, Coastek [Glassey and
> >McNeil] and David Mills have
> >collaborated on an extended NTP Spec and
> >an Interoperability Spec for Coastek's
> >variant of SNTP (since most financial
> >systems will mandate stratum-1 sources
> >for security reasons). This first draft
> >is on-file with the IETF as and
> >Individual Contributor at the following
> >URL:
> >ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt
> >
> >The Coastek specific use models draft
> >and a third draft on portable-trust and
> >logging systems will follow in the next
> >two weeks. We apologize for the lateness
> >of these drafts as we intended to have
> >them available pre-meeting but you know
> >how the last minute crunch is.
> >
> >
> >Todd Glassey
> >
> >

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 2 (TEXT/R*ch) (0001DB89)

Date:         Thu, 4 Dec 1997 09:40:13 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] Adding Certified NTP as a possible standard for portable trust in networking systems
Comments: To: [email-masked], [email-masked], [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], Dave Mills <[email-masked]>
To: [email-masked]

Hi all,
I want to propose the consideration of
using a certified NTP timestamp as the
basis of a portable trust model and
nonreputiead network timing. We and many
others in the associated IETF WG's have
long known the value of digital
timestamps for fixing a point of
reference to an event. Consider the
value if the source of the timestamp and
it's facility can be verified and
proffered as a certified network entity.
This is the birth of truly nonrepudiated
events and their logging.

This capability brings a whole new light
to the world of certificates and
networking policy. Imagine email with
built-in timestamping and nonrepudiated
logging. Especially if combined with the
automated reply services now proposed
for SMTP. This timestamping technology
goes a tremendous way to enabling the
collapsing of human commerce models into
the digital domain.

The use models of the NTP supplied
timestamps will fit in all groups
standards efforts, but especially are of
interest to the PKIX WG. These
timestamping extensions without any real
sweat enable the PKIX #7 Time Extensions
directly. Thus the settling on certified
NTP as the basis of the timestamp source
creates a horizontal technology that is
directly applicable to a number of IETF
and other Standards Working Groups
including those of ANSI, The ABA, and
the SEC. All in all it makes sense for
everyone in our mind.

To this end, Coastek [Glassey and
McNeil] and David Mills have
collaborated on an extended NTP Spec and
an Interoperability Spec for Coastek's
variant of SNTP (since most financial
systems will mandate stratum-1 sources
for security reasons). This first draft
is on-file with the IETF as and
Individual Contributor at the following
URL:
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt

The Coastek specific use models draft
and a third draft on portable-trust and
logging systems will follow in the next
two weeks. We apologize for the lateness
of these drafts as we intended to have
them available pre-meeting but you know
how the last minute crunch is.

Todd Glassey

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf (TEXT/R*ch) (0001DB80)

Date:         Thu, 4 Dec 1997 11:54:29 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki-ecdsa-00.txt
Comments: To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group
of the IETF.

        Title           : Internet X.509 Public Key Infrastructure
                          Representation of Elliptic Curve
                          Digital Signature Algorithm
                          (ECDSA) Keys and Signatures in
                          Internet X.509 Public Key
                          Infrastructure Certificates
        Author(s)       : D. Johnson, L. Bassham, W. Polk
        Filename        : draft-ietf-pkix-ipki-ecdsa-00.txt
        Pages           : 9
        Date            : 03-Dec-97

   This is the first draft of a profile for specification of Elliptic
   Curve Digital Signature Algorithm (ECDSA) keys in Internet Public Key
   Infrastructure X.509 certificates. Please send comments on this
   document to the [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki-ecdsa-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-ecdsa-00.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ipki-ecdsa-00.txt".

NOTE:   The mail server at ds.internic.net can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID:     <[email-masked]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get [IETF-PKIX] I-D ACTION-draf (EuSn/CSOm) (0001DB6F)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki-ecdsa-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki-ecdsa- (AURL/Arch) (0001DB70)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Date:         Wed, 3 Dec 1997 23:16:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Patrick C. Richard" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

Dan Laska wrote:
>
> It seems that the main purpose of having signed responses in OCSP
> is to authenticate the responder.

I disagree. IMHO, the main purpose is to have a non-repudiable receipt
of status provision, that can be used to attest to an attempt to
reasonably check the status of a certificate.

>
> Would it be useful, and perhaps simplify things, to permit SSL/https
> to be used in the protocol instead of requiring signed responses over
> http?

This would not acheive the above.

>
> I am assuming here that the responder is tightly coupled to the CA.
> If the responder's site certificate is revoked then the responder
> itself would have to get disabled or updated by the CA.

This doesn't take into account multiple responder scenarios...

nor the instance where the OCSP provider has multiple certificates

>
> ==========================================
> Dan Laska
> Frontier Technologies Corp.
> Email: [email-masked]
> ==========================================

-Pat
--
Patrick C. Richard - [email-masked]
Public Key Available via LDAP

"All informational objects are candidates for PKI-based ACLs."
       - yhe

Date:         Wed, 3 Dec 1997 13:25:11 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Luis Valente <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

At 03:14 PM 12/3/97 -0500, you wrote:
>>I'm having trouble figuring out what exactly you mean by your last
>>sentence above.  Are you suggesting that if the sender and receiver are
>>under the same CA then non-repudiation cannot really be achieved?  Any
>>clarification would be helpful...
>
>
>I said 'authority', not 'certificate authority' and used it in the context
>of 'controlled by'. If I own and operate two machines at different locations
>and believe the machines to be equally trustworthy the value of ensuring
>that a communication is non repudiable is pretty questionable. What is the
>value of preventing repudiation by me of messages I am sending to myself?
>
>The question is whether the advantages of allowing this mode of use are
>worth the cost of supporting it. I doubt this is the case but if I turn out
>to be wrong for some reason I would prefer folk to use 'unsignd OCSP' than
>inventing a new protocol whose only real difference was avoiding signing.

Phil,

I have an application that operates under the scenario you described above,
i.e., a set of client machines that fully trust a secure server for the
purpose of online checking of a certificate's status. Thus, if OCSP forces
me to sign every response, I will have to invent the "unsigned OCSP"
protocol, as you surmised.

>
>Proposal:
>
>I suggest that unless there is an immediate need for this mode of operation
>it is left out of the current draft except possibly to note it as an option
>if people feel there is a major demand.

Personally, I support Dan Laska's suggestion of mentioning SSL (or other
external mechanism) as an alternative authentication mechanism for OCSP
(with all the caveats about non-repudiation that will let folks here sleep
at night).

>
>
>            Phill
>
>

/Luis
--------------------------------------------------
Luis F. Valente             Phone: +1 650 631-4654
Network Computer, Inc.      Fax:   +1 650 631-4057
www:  http://www.nc.com     Email: [email-masked]

Date:         Wed, 3 Dec 1997 11:21:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

I don't think so.  Although I'm not making much headway in trying to get
OCSP to be more responsive to the nonrepudiation requirement, authenticating
the responder via SSL would not provide any lingering proof of the the
certificate's status.
>
>I am assuming here that the responder is tightly coupled to the CA.
>If the responder's site certificate is revoked then the responder
>itself would have to get disabled or updated by the CA.
>
>==========================================
>Dan Laska
>Frontier Technologies Corp.
>Email: [email-masked]
>==========================================

Bob

Date:         Wed, 3 Dec 1997 12:55:50 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

Hi Dan,
    Going back to the 80,000 foot level, whether you use SSL or
direct signing of the response, both would involve a private key
operation at the OCSP server site. Given the expense of signing
operations, this is likely to limit the number of clients an OCSP
server can server at any given time (I would suspect SSL is quite
a bit more expensive than straight signing for a single connection,
but might get cheaper if a particular client makes multiple
connections to a server and session caching is used).

Also, with either of the two methods - SSL/Signing, the OCSP server
needs to have its private key available for responding to the
request - it needs to be "somewhat" online. So, if an OCSP server
has more clients than it can handle, it would either need to
duplicate its private key and make it available at multiple sites,
or have its clients trust a different private key.

I am writing up a draft on another method of handling certificate
status checking online, that would scale much better.

For early information, check out information about Certificate
Revocation Trees at:
http://www.valicert.com/company/crt.html

Cheers,
Ambarish

Dan Laska wrote:
>
> -----Original Message-----
> From: Phillip M Hallam-Baker <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Wednesday, December 03, 1997 11:10 AM
> Subject: Re: [IETF-PKIX] OCSP using SSL/https
>
> >>It seems that the main purpose of having signed responses in OCSP
> >>is to authenticate the responder.
> >>
> >>Would it be useful, and perhaps simplify things, to permit SSL/https
> >>to be used in the protocol instead of requiring signed responses over
> >>http?
> >
> >
> >Are we talking 'instead of' or 'optionally'?
>
> Sorry. By "permit" I meant "optionally". Maybe "...instead of" made that
> ambiguous.
>
> >
> >Since we don't have a spec proposed for such a transport
> >I think that all we need at most doat this stage is put in some
> >wording to allow the possibility of relying on some other
> >proof of authenticity by prior agreement of both parties in
> >which case only the raw data need be sent.
> >
> >            Phill
> >
>
> I agree that SSL and/or other external means should be mentioned as
> alternative means of authentication in OCSP. I had noticed that the
> language in PKIX-3 was more along these lines (more flexible) rather
> than requiring any of the messages to be signed. It would be nice to
> have the other PKIX specs such as OCSP be consistent.
>
> ==========================================
> Dan Laska
> Frontier Technologies Corp.
> Email: [email-masked]
> ==========================================

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (408) 738-2040
ValiCert, Inc.                                  [email-masked]
333 W. El Camino Real, Suite 270              http://www.valicert.com
Sunnyvale, CA 94087

Date:         Wed, 3 Dec 1997 11:17:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
To: [email-masked]

So that my comments aren't misunderstood, I wasn't arguing for restricting
these attributes to be non-critical. On the contrary, as Bill Burr pointed
out, making use of critical extensions which differentiate between
encryption vs. other uses (plus applications or operating systems which
actually enforce such usages) will significantly ease export problems.

I was merely lamenting the fact that we don't seem to be able to clearly
articulate was digital signature vs. non-repudiation means.

Bob

>>> Simonetti David <[email-masked]> 12/03 7:09 AM >>>
In both the financial and defense communities, this is an important
distinction to make.  Making the extension non-critical means that I can
ignore this distinction, and that is not desirable.

Dave S.

Sharon Boeyen wrote:
>
> There are some pretty simple uses of the keyUsage extension such as the
> difference between an encryption and digital signature key and we make
> heavy use of this today. I'd have no problem making the extension
> non-critical if that's more appropriate.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies

Date:         Wed, 3 Dec 1997 11:10:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [email-masked]
To: [email-masked]

Sharon,

>>>> Sharon Boeyen <[email-masked]> 12/03 6:01 AM >>>
>Bob
>
>Shades of NADF all over again - isn't it!

Deja vu..  You can pay me now, or you can pay me later, but these problems
are going to have to be solved.

>
>At the Washington PKIX meeting, one of the topics which will be
>discussed is whether or not the PKIX WG should define the minimum
>requirements of a schema for support in the directory environment. If
>that work does progress, I personally do not expect it to be a full
>directory schema definition (primarily because in many environments the
>PKI schema components need to fit into a larger schema which addresses
>multiple applications), however I believe there is utility in defining
>the minimum requirements for PKI purposes. I haven't given a lot of
>thought yet to what requirements of names there might be but  we'd be
>defining this schema with directory deployment so that probably would
>dictate a general direction for that piece of work.
>>
>Several people have indicated over the past 6 months or so that they
>think
>some schema work for PKIX would be useful and help move us forward in
>the area of interoperability, so I personally suspect this work item
>will progress (of course there's always the question of whether it
>belongs in the PKIX WG or elsewhere in the IETF). My opinion is that it
>should be tackled in the PKIX WG because that's where the understanding
>of the requirements is.

I'm not going to be able to make the December meeting, but I would certainly
put in my vote to make this a work item -- I think it will be necessary for
interoperability.

Of course the best of all worlds would be dynamic attribute definitions
distributed via the directory, but what good would that do without a
definition of the semantics?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

Date:         Wed, 3 Dec 1997 15:14:56 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

>I'm having trouble figuring out what exactly you mean by your last
>sentence above.  Are you suggesting that if the sender and receiver are
>under the same CA then non-repudiation cannot really be achieved?  Any
>clarification would be helpful...

I said 'authority', not 'certificate authority' and used it in the context
of 'controlled by'. If I own and operate two machines at different locations
and believe the machines to be equally trustworthy the value of ensuring
that a communication is non repudiable is pretty questionable. What is the
value of preventing repudiation by me of messages I am sending to myself?

The question is whether the advantages of allowing this mode of use are
worth the cost of supporting it. I doubt this is the case but if I turn out
to be wrong for some reason I would prefer folk to use 'unsignd OCSP' than
inventing a new protocol whose only real difference was avoiding signing.

Proposal:

I suggest that unless there is an immediate need for this mode of operation
it is left out of the current draft except possibly to note it as an option
if people feel there is a major demand.

            Phill

Date:         Wed, 3 Dec 1997 11:23:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: [email-masked]
To: [email-masked]

Thanks for the speedy response.  Yes, I agree, if the requester, sender, responder are all under the same CA, then doubt as to who is doing stuff is reduced.  In cases where the reliant party is requesting status for a sender's cert that is outside their CA hierarchy, then the case is more significant to know "who" is responding and under what authority.

Michael

>>> Phillip M Hallam-Baker <[email-masked]> 12/03/97 11:14AM >>>
>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>reply in along sequence of requests.".
>
>If each object is not signed, or each data stream signed after the stream
is created (thus becoming one signed object), then SSL by itself does not
provide any evidence of what was sent by whom unless both parties retain
complete records of all the activity within the SSL session from time of
mutual authentication through the end of the session.

What you appear to be saying is that SSL does not provide non-repudiation.
This is of course a major problem. It is not necessarily a critical one
(e.g. both sender and reciever under same authority hence non-repudiation
moot).

This is why I don't like SSL for this application, I certainly don't see it
as being viable as the sole means of providing authentication. It MAY be
sufficiently useful in certain situations to make it an option along with
other external means of establishing authenticity.

        Phill
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Date:         Wed, 3 Dec 1997 13:36:29 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Laska <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

-----Original Message-----
From: Phillip M Hallam-Baker <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 03, 1997 11:10 AM
Subject: Re: [IETF-PKIX] OCSP using SSL/https

>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>
>Are we talking 'instead of' or 'optionally'?

Sorry. By "permit" I meant "optionally". Maybe "...instead of" made that
ambiguous.

>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.
>
>            Phill
>

I agree that SSL and/or other external means should be mentioned as
alternative means of authentication in OCSP. I had noticed that the
language in PKIX-3 was more along these lines (more flexible) rather
than requiring any of the messages to be signed. It would be nice to
have the other PKIX specs such as OCSP be consistent.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [email-masked]
==========================================

Date:         Wed, 3 Dec 1997 14:00:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent:  Wednesday, December 03, 1997 1:14 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>>reply in along sequence of requests.".
>>
>>If each object is not signed, or each data stream signed after the stream
>is created (thus becoming one signed object), then SSL by itself does not
>provide any evidence of what was sent by whom unless both parties retain
>complete records of all the activity within the SSL session from time of
>mutual authentication through the end of the session.
>
>
>What you appear to be saying is that SSL does not provide non-repudiation.
>This is of course a major problem. It is not necessarily a critical one
>(e.g. both sender and reciever under same authority hence non-repudiation
>moot).

My thesaurus entry for "moot" says that the following are synonyms:
controversial, contestable, debatable, arguable, disputable,
questionable, dubious, disputed, doubtful.

I'm having trouble figuring out what exactly you mean by your last
sentence above.  Are you suggesting that if the sender and receiver are
under the same CA then non-repudiation cannot really be achieved?  Any
clarification would be helpful...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 3 Dec 1997 14:04:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent:  Wednesday, December 03, 1997 11:55 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.

This sounds a bit dangerous to me.  It may be too easy for developers to
use this as an excuse for skipping the authentication step most of the
time...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 3 Dec 1997 13:14:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: Mike Smith <[email-masked]>
To: [email-masked]

>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>reply in along sequence of requests.".
>
>If each object is not signed, or each data stream signed after the stream
is created (thus becoming one signed object), then SSL by itself does not
provide any evidence of what was sent by whom unless both parties retain
complete records of all the activity within the SSL session from time of
mutual authentication through the end of the session.

What you appear to be saying is that SSL does not provide non-repudiation.
This is of course a major problem. It is not necessarily a critical one
(e.g. both sender and reciever under same authority hence non-repudiation
moot).

This is why I don't like SSL for this application, I certainly don't see it
as being viable as the sole means of providing authentication. It MAY be
sufficiently useful in certain situations to make it an option along with
other external means of establishing authenticity.

        Phill

Date:         Wed, 3 Dec 1997 11:10:57 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] X.509 certificates and RADIUS
To: [email-masked]

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     All,

        Just a heads up that I submitted a draft to the RADIUS WG a few
     weeks back which describes a mechanism to carry X.509 certificates
     within a RADIUS message. Although it was sent to the secretariat well
     over a week prior to the deadline, it is still not in the archives.

        I am sending the draft within this message (I do appologize for
     readers who do not have mime capability).

        I, unfortunately, cannot discuss this draft in DC since the PKIX
     meetings conflict with a WG that I chair and another that I have 3
     drafts pending :(

        Comments would be appreciated,

        PatC
Content-Type: text/basic; name="radx509.txt"
Content-Transfer-Encoding: 7bit
Content-Description: MS-DOS text file
Content-Disposition: attachment; filename="radx509.txt"

Attachment converted: Lutefisk:radx509.txt (TEXT/R*ch) (0001D378)

Date:         Wed, 3 Dec 1997 10:10:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
Comments: To: [email-masked]
To: [email-masked]

In the case where a central repository services multiple CA's for OCSP, then that repository should sign (timestamp?) the response.  I'm not sure whether this will be a "tightly couple" relationship as some have suggested.  The CRL's used by the repository should, of course be signed by the original issuing CA.  The repository may even archive all of these CRL's issued and their signatures.

Michael
>>> Tim Moses <[email-masked]> 12/03/97 09:03AM >>>
Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Wed, 3 Dec 1997 10:17:57 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: [email-masked]
To: [email-masked]

In your response, SSL is said "would avoid the need to sign each HTTP/1.1
reply in along sequence of requests.".

If each object is not signed, or each data stream signed after the stream is created (thus becoming one signed object), then SSL by itself does not provide any evidence of what was sent by whom unless both parties retain complete records of all the activity within the SSL session from time of mutual authentication through the end of the session.

It seems that retaining object signing for each request or each batch of requests then lets each signed object stand by itself or either party.

Michael
>>> Phillip M Hallam-Baker <[email-masked]> 12/03/97 09:55AM >>>
>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill

Date:         Wed, 3 Dec 1997 11:55:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill

Date:         Wed, 3 Dec 1997 11:03:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
To: [email-masked]

Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Wed, 3 Dec 1997 09:55:08 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Laska <[email-masked]>
Subject:      [IETF-PKIX] OCSP using SSL/https
To: [email-masked]

It seems that the main purpose of having signed responses in OCSP
is to authenticate the responder.

Would it be useful, and perhaps simplify things, to permit SSL/https
to be used in the protocol instead of requiring signed responses over
http?

I am assuming here that the responder is tightly coupled to the CA.
If the responder's site certificate is revoked then the responder
itself would have to get disabled or updated by the CA.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [email-masked]
==========================================

Date:         Wed, 3 Dec 1997 08:34:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

As usual, Bob, I find myself agreeing with your statements.

A certificate is issued under a certain set of authority policies.  If someone wishes to rely on a certificate issued under those policies, then the software they use must be able to process all of the critical extensions established under that policy or not honor the certificate.

If someone does accept a certificate or signature issued with critical extensions that are ignored or interpreted other than the intent of the issuing CA, then, it is my belief, the reliant party (and, possibly the entity that modified the code to accept or ignore the critical extensions) has just relieved the CA of any and all liability regarding that critical extension and, quite possibly, the whole certificate's issued purpose.

Michael

>>> Bob Jueneman <[email-masked]> 12/02/97 11:12AM >>>
Sharon and David,

My tongue in cheek suggestion that we deprecate the keyUsage field was made
as a result of my confusion and exasperation in trying to sort though all of
these different issues.  But if we can't agree on some relatively simple
meaning, I submit that using the fields will actually be WORSE than
deprecating them, for one person will think that they mean one thing, and
another person will interpret them differently.

What good does it do to mark an attribute as critical, if the semantics are
as undefined or ambiguous as these are?

And to bring up a somewhat different ubject that I mentioned before, but
never got closure on, I think that it is completely UNACCEPTABLE to say that
if some particular application does not have, understand, or chose to
implement a security policy, it should be free to simply ignore the critical
marking on a Policy OID constraint. This simply turns the definition of
critical on its head.  The critical usage is provided primarily to protect
the CA and/or the subject of the certificate from unreasonable reliance on
the certificate, and to provide a means for IT administrators to centrally
control what kinds of policies are to be enforced.

Bob

>Bob,
>
>First let me say that I highly respect all of the opinions that I've
>received.
>
>The key usage flags do play a useful role.  As a single example, they
>allow me to restrict use of my RSA key to either digital signature or
>key encipherment, but never both.  There is enough importance in this
>single role to warrant the extension be made "critical" when used.
>
>If this thread has proved anything, it's at least shown that there is no
>universal interpretation of non-repudiation or how to best implement
>it.  I think we should leave it up to individual communities of users to
>determine how to best implement this in their situation because there is
>not one right answer.  Certificate policies are going to play a mighty
>important role.
>
>Dave Simonetti
>
>Bob Jueneman wrote:
>>
>> >I, in turn, propose that digitalSignature is the mechanism.  If
>> >nonRepudiation is turned on, then the non-repudiation service is
>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>> >provided.  Why can't it be this simple?
>> >
>> >Dave Simonetti
>> >
>> >
>> I'd like to think that those who have ventured an opinion in this area
are
>> reasonably knowledgable about the subject.
>>
>> But if we cannot agree as what these bits mean, it is not likely that
either
>> CAs or client software will understand or correctly implement the
semantics,
>> no matter what the bottom line is.
>>
>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>> they seem to be doing more harm than good.
>>
>> Can someone make a case for why we should bother with them, if there is
this
>> much confusion about their meaning?
>>
>> Bob

Date:         Wed, 3 Dec 1997 08:36:06 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

Maybe I'm missing something with the X.500 compatibility issue and X.509 certifcates.  I thought that, with version 3, X.500 is just one schema tht the X.509v3 certificate processing systems should be "backward compatible" with.

Michael

>>> Andreas Berger <[email-masked]> 12/03/97 04:24AM >>>
Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas

Date:         Wed, 3 Dec 1997 09:27:37 -0500
Reply-To: Judie Mulholland <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Judie Mulholland <[email-masked]>
Subject:      [IETF-PKIX] ITU recommendations v. IETF drafts
To: [email-masked]

i'd like to know if anyone on this list has seen/read the following
document:

[X.509] Recommendation X.509 (11/93) - Information technology - Open
Systems Interconnection - The directory: Authentication framework
Posted: 1996-01-29

http://www.itu.int/itudoc/itu-t/rec/x/x500up/x509_27505.html

in order to get access this paper, the reader must pay 20 swiss francs
(i.e., pay first, read later) and before doing so, i'd like to know the
following:

1) if someone could explain to me what the differences are between the
docs that are being published by the ITU and the ones that are being
produced under the auspices of the IETF.

2) judging by the publication date, it seems that the material must be
grossly out of date? am i correct in this assumption? if yes, where and
what should i be looking at? if not, is it worth paying for?

tia

/judie

ps

oops, i forgot to mention that i am doing my disseration in the area of
e-commerce and rights management. in particular, i am focusing on the
implementation of certificate authorities and digital signatures in the
state of florida.

Ph.D. Candidate                         Voice: (850) 644-5775
School of Information Studies           Fax:   (850) 644-6253
Florida State University                Email: [email-masked]
Tallahassee, FL 32306                   [email-masked]

Date:         Wed, 3 Dec 1997 09:09:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]

In both the financial and defense communities, this is an important
distinction to make.  Making the extension non-critical means that I can
ignore this distinction, and that is not desirable.

Dave S.

Sharon Boeyen wrote:
>
> There are some pretty simple uses of the keyUsage extension such as the
> difference between an encryption and digital signature key and we make
> heavy use of this today. I'd have no problem making the extension
> non-critical if that's more appropriate.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[email-masked]       Tel: (613) 247-3181
> http://www.entrust.com          Fax: (613) 247-3690
>          Orchestrating Enterprise Security
>
> >----------
> >From:  Bob Jueneman[SMTP:[email-masked]]
> >Sent:  December 2, 1997 1:12 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
> >
> >Sharon and David,
> >
> >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> >as a result of my confusion and exasperation in trying to sort though all of
> >these different issues.  But if we can't agree on some relatively simple
> >meaning, I submit that using the fields will actually be WORSE than
> >deprecating them, for one person will think that they mean one thing, and
> >another person will interpret them differently.
> >
> >What good does it do to mark an attribute as critical, if the semantics are
> >as undefined or ambiguous as these are?
> >
> >And to bring up a somewhat different ubject that I mentioned before, but
> >never got closure on, I think that it is completely UNACCEPTABLE to say that
> >if some particular application does not have, understand, or chose to
> >implement a security policy, it should be free to simply ignore the critical
> >marking on a Policy OID constraint. This simply turns the definition of
> >critical on its head.  The critical usage is provided primarily to protect
> >the CA and/or the subject of the certificate from unreasonable reliance on
> >the certificate, and to provide a means for IT administrators to centrally
> >control what kinds of policies are to be enforced.
> >
> >Bob
> >
> >>Bob,
> >>
> >>First let me say that I highly respect all of the opinions that I've
> >>received.
> >>
> >>The key usage flags do play a useful role.  As a single example, they
> >>allow me to restrict use of my RSA key to either digital signature or
> >>key encipherment, but never both.  There is enough importance in this
> >>single role to warrant the extension be made "critical" when used.
> >>
> >>If this thread has proved anything, it's at least shown that there is no
> >>universal interpretation of non-repudiation or how to best implement
> >>it.  I think we should leave it up to individual communities of users to
> >>determine how to best implement this in their situation because there is
> >>not one right answer.  Certificate policies are going to play a mighty
> >>important role.
> >>
> >>Dave Simonetti
> >>
> >>Bob Jueneman wrote:
> >>>
> >>> >I, in turn, propose that digitalSignature is the mechanism.  If
> >>> >nonRepudiation is turned on, then the non-repudiation service is
> >>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
> >>> >provided.  Why can't it be this simple?
> >>> >
> >>> >Dave Simonetti
> >>> >
> >>> >
> >>> I'd like to think that those who have ventured an opinion in this area
> >are
> >>> reasonably knowledgable about the subject.
> >>>
> >>> But if we cannot agree as what these bits mean, it is not likely that
> >either
> >>> CAs or client software will understand or correctly implement the
> >semantics,
> >>> no matter what the bottom line is.
> >>>
> >>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
> >>> they seem to be doing more harm than good.
> >>>
> >>> Can someone make a case for why we should bother with them, if there is
> >this
> >>> much confusion about their meaning?
> >>>
> >>> Bob
> >

Date:         Wed, 3 Dec 1997 08:23:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]

Andreas,

I think your proposal of guidelines and best practices is a good one and
probably about as far as we could go in this area. There are 2 different
sets of requirements, both of which need to be accommodated. In one case
we want the names to be simple and easily retreivable and in the other
case we need to address both PKI-specific repositories and repositories
that are shared directories with other applications.

There are some guidelines that clearly fit into both environments, such
as recommending that only "standard" attribute types be used in names
and possibly recommending which ones (increasing the likelihood that
they can be retrieved), use of numeric values to disambiguate (although
3-4 years ago people would have thrown up their arms in opposition to
that I think that has changed along with the realization that these
don't normally get displayed to end-users anyway) ... just a few early
thoughts.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Andreas Berger[SMTP:[email-masked]]
>Sent:  December 3, 1997 6:24 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Question about SubjectAltNames
>
>Bob Jueneman wrote:
>>
>> >Phil,
>> >
>> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
>> >require "Distinguished Names" to be "Directory Names"?
>
>To my opinion, the X.509 certificates were intended to authenticate
>users for access of the X.500 directory system. Certificates must
>contain an acceptable name for the application in question. Therefore,
>distinguished names for the X.500 are the appropriate namespace for this
>application. For other applications there may well be other namespaces
>acceptable.
>
>> 1.  Does the DN in a certificate have to be globally unambiguous, so that
>>no
>> two people with the same common name could possibly be confused?
>>
>> Answering that question "yes" will force name subordination to be applied
>> everywhere, even in cases where the obvious ways of doing it (geopolitical
>> name qualification, down to the street address level) are either
>> unacceptable (e.g., due to privacy concerns), or not workable (because the
>> state or locality entities have not bought into the system, or because the
>> natural domain of a CA (e.g., an ISP) is not confined by regional
>> boundaries. This in turn tends to force the use of multiple RDNs as the
>>leaf
>> component, in order to avoid changing someone's common name while still
>> maintaining global unambiguity.
>>
>> Answering the question "no" seems (at least on the surface) to
>>significantly
>> weaken the legal status of a digital signature for purposes of commerce,
>> unless some other name mechanism (e.g., a unique account number) is
>>included
>> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
>> system was somewhat cavalier about the assignment of names -- in fact it
>> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
>> mark, whether unique or not.  But more recently, the issue of who owns
>> domain names has become increasingly contentious. Whereas at one time Apple
>> the computer company and Apple the music company had little to do with each
>> other, today the separation is much less clean cut.  Even today, if there
>> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no
>>significant
>> legal confusion is likely to result. But who can say what will happen
>> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
>> have an e-mail account with CompuServe. or some other domestic ISP).
>
>We don't need a global unique name for users in a certificate in the way
>you described it. We have to be very careful not to mix the attributes
>of a person (Name, Address...) with the requirement of the technical
>"name". That is a problem that X.500 created with typed RDNs.
>
>For electronic commerce applications (or legally binding transactions)
>we need a name that is acceptable to the other party. This acceptance
>depends largely on the trustworthiness of the issuer of the certificate
>and defined measures to get hold of the physical person in case a
>dispute arises. Therefore, it should be enough to identify an end entity
>relativly unique to the issuer. And this identification may well be made
>by a number or some other means. People may have several identities in
>this respect - and nobody will care unless the resolution of these
>pseudonymity is required.
>
>> 2. Does the use of X.509 envision at least the possibility of a globally
>> interconnected directory to be used for certificate retrieval and perhaps
>> CRL retrieval?  If so, doesn't require the assumption that the DN in the
>> certificate is one to one with respect to the DIT?  If we don't start out
>> deploying certificates with that assumption in mind, will it not prove to
>>be
>> impossible to migrate to such a scheme later on?
>
>If an application accepts simple DNs (such as CN=High Speed Modem) it
>has to have some knowledge on how to retrieve such names from a
>directory (if a directory is employed at all). I would not want to make
>very piece of equiment in a corporate network "worldwide unique". And
>yes, this certificate would have no meaning outside the corporate
>network, but is this really necessary?
>
>For the (relativly simple) operations needed for retrieving security
>attribute from directories (i.e. find a certificate for a person,
>retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
>FINGER or something similar). We do not need a very complex "directory
>service" for these operations.
>
>But I agree that we should develop some guidelines for creating DNs. Or
>at least write down what is already there (see the NT4 LDAP server,
>verisign certificates, X.400 mailaddresses an so on). Perhaps we can
>converge on an accepted practice. We should stress the point that these
>DNs are automatically resolvable to machine/service names (on the
>internet or other) so that applications (e.g. eMail clients or payment
>systems) can access a direcory service to retrieve additional
>information desired.
>
>> 3.  And speaking of schemes, what schema is to be assumed for acceptable
>> components of a DN in a certificate, if we are to ever move toward a common
>> directory?  At present, I am not aware of any definition of what
>>constitutes
>> allowable, deprecated, or not allowable attribute types within a PKIX DN,
>> yet if we ever expect that the current islands of LDAP usage will ever
>>merge
>> into archipelagoes, and finally continents, some agreement on acceptable
>> schemas will have to be enforced.  Should we just leave it up to the public
>> CAs like VeriSign to say what kinds of DN attributes they will support, and
>> let all of the directory providers eat dirt?  Or vice versa?
>I doubt that we will get a common directory for each and every entity on
>the planet. Companies will severly restrict access to corporate
>directories and even I personally would not want to publish a massive
>amount of information globally.
>
>> I believe that the working consensus is still the same that it was in the
>> PEM days -- that we should strive to be interoperable with X.500
>> directories, but should not presume their existence to be either necessary
>> or sufficient.
>Agreed. But what I would like to see is the seperation of the DN as a
>name for an entry from identity information needed in certificates. The
>DN for an entry is just a name (like an URL or bettern URN) that - in my
>opionion - may be changed as often. What matters is the content of the
>entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
>to the application, it should put these into the certificate as well -
>but not as part of the DN.
>
>Andreas
>--
> Andreas Berger, GMD - German National         eMail:
>[email-masked]
> Research Center for Information Technology,
> Institute for Telecooperation Technology      Tel:   +49-6151-869-715
> Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   +49-6151-869-704
>

Date:         Tue, 2 Dec 1997 11:12:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
To: [email-masked]
Status:

Sharon and David,

My tongue in cheek suggestion that we deprecate the keyUsage field was made
as a result of my confusion and exasperation in trying to sort though all of
these different issues.  But if we can't agree on some relatively simple
meaning, I submit that using the fields will actually be WORSE than
deprecating them, for one person will think that they mean one thing, and
another person will interpret them differently.

What good does it do to mark an attribute as critical, if the semantics are
as undefined or ambiguous as these are?

And to bring up a somewhat different ubject that I mentioned before, but
never got closure on, I think that it is completely UNACCEPTABLE to say that
if some particular application does not have, understand, or chose to
implement a security policy, it should be free to simply ignore the critical
marking on a Policy OID constraint. This simply turns the definition of
critical on its head.  The critical usage is provided primarily to protect
the CA and/or the subject of the certificate from unreasonable reliance on
the certificate, and to provide a means for IT administrators to centrally
control what kinds of policies are to be enforced.

Bob

>Bob,
>
>First let me say that I highly respect all of the opinions that I've
>received.
>
>The key usage flags do play a useful role.  As a single example, they
>allow me to restrict use of my RSA key to either digital signature or
>key encipherment, but never both.  There is enough importance in this
>single role to warrant the extension be made "critical" when used.
>
>If this thread has proved anything, it's at least shown that there is no
>universal interpretation of non-repudiation or how to best implement
>it.  I think we should leave it up to individual communities of users to
>determine how to best implement this in their situation because there is
>not one right answer.  Certificate policies are going to play a mighty
>important role.
>
>Dave Simonetti
>
>Bob Jueneman wrote:
>>
>> >I, in turn, propose that digitalSignature is the mechanism.  If
>> >nonRepudiation is turned on, then the non-repudiation service is
>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>> >provided.  Why can't it be this simple?
>> >
>> >Dave Simonetti
>> >
>> >
>> I'd like to think that those who have ventured an opinion in this area
are
>> reasonably knowledgable about the subject.
>>
>> But if we cannot agree as what these bits mean, it is not likely that
either
>> CAs or client software will understand or correctly implement the
semantics,
>> no matter what the bottom line is.
>>
>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>> they seem to be doing more harm than good.
>>
>> Can someone make a case for why we should bother with them, if there is
this
>> much confusion about their meaning?
>>
>> Bob

Date:         Tue, 2 Dec 1997 17:04:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
To: [email-masked]
Status:

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?

In a similar way:  OCSP responses are either signed by the CA or signed
by the OCSP responder.

The latter is used if responders are separately certified, although my
understanding is that Mike was thinking of dropping this possibility
because of the added complexity of checking the revocation status of the
OCSP responder's certificate (which boils down to a second OCSP request
(i.e., one to the OCSP responder and one to the CA) thereby doubling
network traffic without reducing CA bandwidth).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 2 Dec 1997 14:31:28 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [email-masked]
To: [email-masked]
Status:

>Phil,
>
>I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
>require "Distinguished Names" to be "Directory Names"?
>
>I am of the opinion that X.509 is not tied inextricably to X.500, and
>that Authorities and Relying Parties should be free to use the
>SEQUENCE OF RelativeDistinguishedName syntax (and the associated
>nameConstraints extension) in any way that makes sense to them.  Under
>this scenario, it would be completely legal to have a subjectName of
>"CN = High Speed Modem".
>
>Unfortunately, this example is not a Directory Name, because it is
>not unique identifier within the DIT.  Many user communities (such as
>MISSI) will restrict usage to Directory Names because that convention
>makes many things simpler.  But does X.509 require this restriction?
>
>Consensus, anyone?

David, this is a question which has plagued us since the PEM days. In
addition to the technical ramifications (which were some of the reasons why
the spki group developed their own agenda), it has legal ramifications as
well.

I believe the appropriate questions to ask are:

1.  Does the DN in a certificate have to be globally unambiguous, so that no
two people with the same common name could possibly be confused?

Answering that question "yes" will force name subordination to be applied
everywhere, even in cases where the obvious ways of doing it (geopolitical
name qualification, down to the street address level) are either
unacceptable (e.g., due to privacy concerns), or not workable (because the
state or locality entities have not bought into the system, or because the
natural domain of a CA (e.g., an ISP) is not confined by regional
boundaries. This in turn tends to force the use of multiple RDNs as the leaf
component, in order to avoid changing someone's common name while still
maintaining global unambiguity.

Answering the question "no" seems (at least on the surface) to significantly
weaken the legal status of a digital signature for purposes of commerce,
unless some other name mechanism (e.g., a unique account number) is included
somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
system was somewhat cavalier about the assignment of names -- in fact it
doesn't matter if you sign your checks as "Santa Claus" -- it is still your
mark, whether unique or not.  But more recently, the issue of who owns
domain names has become increasingly contentious. Whereas at one time Apple
the computer company and Apple the music company had little to do with each
other, today the separation is much less clean cut.  Even today, if there
exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
legal confusion is likely to result. But who can say what will happen
tomorrow? On the Internet, no one knows you live in Uganda (at least if you
have an e-mail account with CompuServe. or some other domestic ISP).

2. Does the use of X.509 envision at least the possibility of a globally
interconnected directory to be used for certificate retrieval and perhaps
CRL retrieval?  If so, doesn't require the assumption that the DN in the
certificate is one to one with respect to the DIT?  If we don't start out
deploying certificates with that assumption in mind, will it not prove to be
impossible to migrate to such a scheme later on?

3.  And speaking of schemes, what schema is to be assumed for acceptable
components of a DN in a certificate, if we are to ever move toward a common
directory?  At present, I am not aware of any definition of what constitutes
allowable, deprecated, or not allowable attribute types within a PKIX DN,
yet if we ever expect that the current islands of LDAP usage will ever merge
into archipelagoes, and finally continents, some agreement on acceptable
schemas will have to be enforced.  Should we just leave it up to the public
CAs like VeriSign to say what kinds of DN attributes they will support, and
let all of the directory providers eat dirt?  Or vice versa?

I believe that the working consensus is still the same that it was in the
PEM days -- that we should strive to be interoperable with X.500
directories, but should not presume their existence to be either necessary
or sufficient.

But that still leaves us a lot of questions to answer.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are tring to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

Date:         Tue, 2 Dec 1997 13:38:54 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

Russ, I haven't made the last couple of IETF meetings, but this sounds like
it might be quite important.  When is that meeting?

bob

>>> Russ Housley <[email-masked]> 11/26 8:54 AM >>>
I understand that notary and trusted-timesatmps will be discussed at the
upcoming meeting in Washington.

Russ

At 08:08 PM 11/26/97 +1100, Hamid Homayouni wrote:
>On Wednesday, November 26, 1997 1:25 AM, Russ Housley  wrote:
>> So, when you hand sign a guest register at a wedding, a credit card
>> receipt, and a mortgage, how do you distinguish which needs
>> non-repudiation?  You do not (except that you are forced to use black
>ink).
>>  If the transaction is really important, you get a notary involved, but
>> otherwise the same mechanism is used to provide different services.
>
>That's right, but also remember that there are various degrees of
>importance. I certainly would not get a notary involved in a credit card
>transaction, but I have to and WILL use my signature that is on the back of
>my mag stripe card. Although, I may choose not use that same signature for
>a guest register!
>
>Just out of curiosity, what's the equivalent of a notary in PKI if a CA
>with proper processes, and liability covers, etc is not considered one?
>
>-Hamid
>
>>
>> Russ
>>
>>
>> At 02:20 PM 11/25/97 +1100, Hamid Homayouni wrote:
>> >Similar to Bill, I've not been involved in the discussions that led to
>this
>> >proposal. So please bear with me.
>> >
>> >The technical mechanisms for both digital signature and non-repudiation
>are
>> >the same. The only thing that can enforce non-repudiation is proper
>> >legislation behind it.
>> >At the same time, as a user, I'd prefer to separate my key usage into
>> >"digital signature" for day-to-day I&A use, and "non-repudiation". ie. I
>> >really want to consciously sign something and not get it mixed up with
>my
>> >day-to-day activity of using my I&A keys. Similar to what I actually do
>> >with my normal hand signature. I've one (the short version) that I use
>> >within the office for memos, etc, and one that I use for financial
>> >transactions (ie, I'm consciously accepting a bigger responsibility).
>[...]
>
>> >> >>
>> >> >
>> >> >
>> >> Regards,
>> >>
>> >> Bill Burr
>>
>>
>

Date:         Tue, 2 Dec 1997 11:43:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
To: [email-masked]
Status:

Tim:

the digital signature on the CRL returned by HTTP or FTP provides teh
authentication.  How is comperable authentication provided in the alternative?

Russ

At 09:17 AM 12/2/97 -0500, you wrote:
>Colleagues - I have been reviewing the OCSP and the 'FTP and HTTP'
>drafts, and it occurs to me that OCSP can be considered to be a special
>case of the latter scheme.  This would not be the case if OCSP could
>offer a 'live' response in a large-scale system, but clearly this is not
>practical.
>
>I assume that OCSP is designed to provide notification of revocation
>over the Internet in the absence of a replicated directory.  Clearly,
>there is a need to solve this problem.  But the use of CRLs over HTTP
>offers a more general solution to the same problem.  In addition, it is
>a more robust solution, offers greater flexibility in engineering
>implementations, exhibits lower cost and makes better re-use of existing
>software.  HTTP-caching must be used with either protocol, in order to
>achieve adequate scalability.  In which case, the CA can control the
>cache retention interval in intermediate HTTP servers, in order to
>ensure that they will be refreshed when new revocation status
>information is scheduled to become available.
>
>An illustrative example to support these conclusions is provided at the
>end.
>
>Summary
>
>OCSP places a heavy load on the most highly shared components of the
>system, making it unnecessarily expensive to offer a scaleable and
>compliant service.  This is because dividing revocation information into
>its smallest parts makes the probability of a cache hit in the periphery
>of the network insignificant.  This may be appropriate if, for some
>reason, one wants to ensure that each individual revocation status
>request is serviced directly by the CA, but a more general solution is
>required for situations where this is not a consideration.  Moreover,
>the general solution can, if necessary, be engineered to provide a
>service equivalent to that offered by OCSP where this is appropriate.
>
>Conclusions
>
>OCSP and the 'single monolithic CRL for the entire subscriber-base'
>approaches represent two extremes of the general solution represented by
>CRL distribution points accessed over the HTTP infrastructure.  OCSP can
>be considered equivalent to assignment of a single subscriber to each
>distribution point, and the single monolithic CRL can be considered
>equivalent to the assignment of the entire subscriber-base to a single
>distribution point.
>
>The special case of OCSP leads to a solution which minimizes the
>consumption of network resource in the dedicated data-link between the
>relying party and its ISP.  But, this is not a scarce resource (largely
>because it is not shared).  The penalty paid for this is that there is
>increased demand placed on the most highly shared components (the
>data-link between the Internet and the CA and the CA's signature
>facility).  This leads to excessive hardware and communication costs.
>
>Using CRLs over HTTP represents the general solution of which the other
>two can be considered special cases.  Therefore, each implementation of
>the general case can be engineered, as appropriate, to satisfy the
>requirements of the specific application.  Those for whom the
>characteristics of OCSP are attractive may tailor the general solution
>to recreate OCSP-like characteristics.  Others can make different
>choices, without having to modify the operation of the relying party
>software.
>
>So, I propose that we examine the Internet Draft protocol for
>distributing CRLs over HTTP and ensure that it adequately accommodates
>the concerns that led to the proposal for the OCSP protocol.
>
>Analysis
>
>The effect of caching at the periphery of the Internet becomes apparent
>by considering this illustrative example.
>
>The architecture consists of ten components connected linearly in order
>from 1 to 10.
>
>Component 1: The relying party.
>Component 2: The relying party's HTTP cache.
>Component 3: The relying party's data-link to its ISP.
>Component 4: The ISP (let's assume that each ISP serves 1,000 relying
>parties).
>Component 5: The ISP's HTTP cache.
>Component 6: The ISP's data-link to the Internet backbone.
>Component 7: The Internet (let's assume that all the relying parties are
>represented by 1,000 ISPs).
>Component 8: The data-link connecting the Internet backbone to the CA.
>Component 9: The CA's HTTP cache.
>Component 10: The CA's signature facility.
>
>In this architecture, the CA serves 1 million subscribers and 1 million
>relying parties, via 1,000 ISPs.
>
>Other assumptions we need are these.
>
>Assumption 1.  Each use of the OCSP protocol consumes 6 kilobits of
>network resource.  This number includes the signature on the OCSP
>response (assumed to be 1024b or 170 base64 characters), but it also
>includes bits associated with establishing and destroying a TCP
>connection and sending the HTTP message.
>
>Assumption 2.  In the case of CRLs over HTTP, let's assume that the 1
>million subscribers are assigned to 500 distribution points, and that
>10% of subscribers are revoked at all times.  This situation might
>obtain in a corporate setting, where certificates are issued with a one
>year validity, they are revoked when the holder leaves the corporation
>and the corporation suffers a 10% staff turnover.  I believe these are
>very conservative assumptions.  Under these assumptions, the network
>resource consumed by retrieving a distribution point entry may be 50kb,
>including the bits associated with the connection and message.  While
>this number is almost ten times that for OCSP, it is much more
>efficient, because it conveys information about 2,000 certificates.
>
>Assumption 3.  Each relying party validates 0.01 certificates per second
>during the "busy-hour" (this pattern of behavior  is consistent with use
>for signed and encrypted email, in which all relying parties work
>through their "overnight" email first thing in the morning).
>
>Assumption 4.  The relying parties are spread geographically over three
>time zones.
>
>Assumption 5.  In order to keep delays caused by contention for shared
>resources to an acceptable level, shared components will be engineered
>with a capacity three times the calculated busy-hour average demand.
>
>In the case of the OCSP protocol ...
>
>OCSP component 2 (relying party HTTP cache).  The probability of a hit
>on the relying party's cache is zero.
>
>OCSP component 3 (relying party data-link).  The average resource
>consumption in the data-link between the relying party and the ISP is
>6kb * 0.01 per sec = 60b/s.
>
>OCSP component 5 (ISP HTTP cache).  The probability of a hit on the
>ISP's cache is essentially zero (the ISP receives 36,000 requests during
>the busy-hour.  If you pick at random, from 1 million items, 36,000
>times (replacing them after each pick), then the probability of picking
>the same item twice is negligible).
>
>OCSP component 6 (ISP data-link).  Each ISP passes 36,000 requests per
>hour to the Internet backbone.  So, the resource consumed in the
>data-link between the ISP and the Internet backbone is 1,000 * 60b/s =
>60kb/s.  Applying Assumption 5, a 256kb/s data link is required.
>
>OCSP component 8 (CA data-link).  If the ISPs each serve one time zone,
>then 333 of them will be generating busy-hour traffic levels at the same
>time.  Therefore, resource consumption in the data-link between the
>Internet and the CA will be 333 * 60kb/s = 20Mb/s.  So again, by
>Assumption 5, a 60Mb/s ATM link is required.
>
>OCSP component 9 (CA HTTP cache).  The CA's cache outputs is 36,000 *
>333 = 12 million requests per hour.  So, a database capable of serving
>3,333 read operations per second is required.
>
>OCSP component 10 (CA signature facility).  If the CA takes 3 hours to
>replenish its cache with a new entry for each of its 1 million
>subscribers, then the CA's signature facility must support a rate of 90
>signatures per second, and responses may be up to three hours out of
>date.
>
>In the case of the CRLs over HTTP protocol. ...
>
>CRLs over HTTP component 2 (relying party HTTP cache).  The probability
>of a hit on the relying party's cache is zero.
>
>CRLs over HTTP component 3 (relying party data-link).  The average
>resource consumption in the data-link between the relying party and the
>ISP is 50kb * 0.01 per sec = 500b/s.
>
>CRLs over HTTP component 5 (ISP HTTP Cache).  The ISP's HTTP cache
>receives 36,000 requests per hour for one of 500 distribution points.
>Therefore, the probability of a cache hit is 0.986.  Although each
>request consumes about ten times as much network resource, only slightly
>more than one in every hundred requests are transferred to the Internet.
> So the amount of Internet traffic generated is approximately one tenth.
>
>CRLs over HTTP component 6 (ISP data-link). The average data rate
>transferred by the ISP cache to the Internet is the number of relying
>parties times the average data rate per relying party times one minus
>the efficiency of the case.  I.e. 1,000 * 500 * (1 - 0.986) b/s.= 7
>kb/s.  Therefore, by Assumption 5, a 32kb/s link would be adequate
>between the ISP and the Internet backbone.
>
>CRLs over HTTP component 8 (CA data-link).  If the ISPs each serve one
>time zone, then 333 of them will be generating busy-hour traffic levels
>at the same time.  Therefore, resource consumption in the data-link
>between the Internet and the CA will be 333 * 7 kb/s = 2.3 Mb/s.  So, by
>Assumption 5, a 7Mb/s data link is required between the Internet and the
>CA.
>
>CRLs over HTTP component 9 (CA HTTP cache).  The CA's cache receives 333
>* 500 requests per hour.   So, a database capable of servicing 50 read
>operations per second is required.
>
>CRLs over HTTP component 10 (CA signature facility).  If the CA were
>capable of performing 90 signature operations per second, then
>theoretically, it could update all of its 500 entries once every six
>seconds.  If, however, it were to update them every three hours, then
>its signature capacity must be 0.04 signatures per second.
>
>
>--------------------------------------------------------------
>Tim Moses, Entrust Technologies,
>Tel: 613 247 3183,
>email: [email-masked].
>

Date:         Tue, 2 Dec 1997 10:30:21 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

> From: "Phillip H. Griffin" <[email-masked]>
>
> Jim,
>
> X.520 indicates that commonName is a reasonable solution. It
> states that:
>
>    "The Common Name attribute type specifies an identifier of an object.
>    A Common Name is not a directory name; it is a (possibly ambiguous)
>    name by which the object is commonly known in some limited scope
>    (such as an organization) and conforms to the naming conventions of
>    the country or culture with which it is associated."
>
> This seems to cover your need. Examples are also given there:
>
>    "Examples:
>
>       CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE";
>       CN = "Divisional Coordination Committee";
>       CN = "High Speed Modem".

Phil,

I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
require "Distinguished Names" to be "Directory Names"?

I am of the opinion that X.509 is not tied inextricably to X.500, and
that Authorities and Relying Parties should be free to use the
SEQUENCE OF RelativeDistinguishedName syntax (and the associated
nameConstraints extension) in any way that makes sense to them.  Under
this scenario, it would be completely legal to have a subjectName of
"CN = High Speed Modem".

Unfortunately, this example is not a Directory Name, because it is
not unique identifier within the DIT.  Many user communities (such as
MISSI) will restrict usage to Directory Names because that convention
makes many things simpler.  But does X.509 require this restriction?

Consensus, anyone?

Date:         Tue, 2 Dec 1997 08:15:17 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

Jim,

X.520 indicates that commonName is a reasonable solution. It
states that:

   "The Common Name attribute type specifies an identifier of an object.
   A Common Name is not a directory name; it is a (possibly ambiguous)
   name by which the object is commonly known in some limited scope
   (such as an organization) and conforms to the naming conventions of
   the country or culture with which it is associated."

This seems to cover your need. Examples are also given there:

   "Examples:

      CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE";
      CN = "Divisional Coordination Committee";
      CN = "High Speed Modem".

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Jim Schaad (Exchange) wrote:
>
> I have a situation where the subject DN for a certificate does not
> contain a good displayable name for the person that the certificate is
> issued for. I would put a displayable name of some type in the
> subjectAltName field, but cannot figure out how this should work.  This
> is no such thing as a Universial Name field in the GeneralName
> structure.  Is the correct way to go about this to create an x500Address
> with a cn field? or somthing else?  I've looked in serveral places and
> cannot figure this out.  I would expect due to the uniqueness of a
> Subject DN that this problem may crop up in more that one context.  Is
> this something that needs to be addressed in the PKIX documents?
>
> jim schaad

Date:         Tue, 2 Dec 1997 09:17:15 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Moses <[email-masked]>
Subject:      [IETF-PKIX] OCSP v CRLs over HTTP
To: [email-masked]
Status:

Colleagues - I have been reviewing the OCSP and the 'FTP and HTTP'
drafts, and it occurs to me that OCSP can be considered to be a special
case of the latter scheme.  This would not be the case if OCSP could
offer a 'live' response in a large-scale system, but clearly this is not
practical.

I assume that OCSP is designed to provide notification of revocation
over the Internet in the absence of a replicated directory.  Clearly,
there is a need to solve this problem.  But the use of CRLs over HTTP
offers a more general solution to the same problem.  In addition, it is
a more robust solution, offers greater flexibility in engineering
implementations, exhibits lower cost and makes better re-use of existing
software.  HTTP-caching must be used with either protocol, in order to
achieve adequate scalability.  In which case, the CA can control the
cache retention interval in intermediate HTTP servers, in order to
ensure that they will be refreshed when new revocation status
information is scheduled to become available.

An illustrative example to support these conclusions is provided at the
end.

Summary

OCSP places a heavy load on the most highly shared components of the
system, making it unnecessarily expensive to offer a scaleable and
compliant service.  This is because dividing revocation information into
its smallest parts makes the probability of a cache hit in the periphery
of the network insignificant.  This may be appropriate if, for some
reason, one wants to ensure that each individual revocation status
request is serviced directly by the CA, but a more general solution is
required for situations where this is not a consideration.  Moreover,
the general solution can, if necessary, be engineered to provide a
service equivalent to that offered by OCSP where this is appropriate.

Conclusions

OCSP and the 'single monolithic CRL for the entire subscriber-base'
approaches represent two extremes of the general solution represented by
CRL distribution points accessed over the HTTP infrastructure.  OCSP can
be considered equivalent to assignment of a single subscriber to each
distribution point, and the single monolithic CRL can be considered
equivalent to the assignment of the entire subscriber-base to a single
distribution point.

The special case of OCSP leads to a solution which minimizes the
consumption of network resource in the dedicated data-link between the
relying party and its ISP.  But, this is not a scarce resource (largely
because it is not shared).  The penalty paid for this is that there is
increased demand placed on the most highly shared components (the
data-link between the Internet and the CA and the CA's signature
facility).  This leads to excessive hardware and communication costs.

Using CRLs over HTTP represents the general solution of which the other
two can be considered special cases.  Therefore, each implementation of
the general case can be engineered, as appropriate, to satisfy the
requirements of the specific application.  Those for whom the
characteristics of OCSP are attractive may tailor the general solution
to recreate OCSP-like characteristics.  Others can make different
choices, without having to modify the operation of the relying party
software.

So, I propose that we examine the Internet Draft protocol for
distributing CRLs over HTTP and ensure that it adequately accommodates
the concerns that led to the proposal for the OCSP protocol.

Analysis

The effect of caching at the periphery of the Internet becomes apparent
by considering this illustrative example.

The architecture consists of ten components connected linearly in order
from 1 to 10.

Component 1: The relying party.
Component 2: The relying party's HTTP cache.
Component 3: The relying party's data-link to its ISP.
Component 4: The ISP (let's assume that each ISP serves 1,000 relying
parties).
Component 5: The ISP's HTTP cache.
Component 6: The ISP's data-link to the Internet backbone.
Component 7: The Internet (let's assume that all the relying parties are
represented by 1,000 ISPs).
Component 8: The data-link connecting the Internet backbone to the CA.
Component 9: The CA's HTTP cache.
Component 10: The CA's signature facility.

In this architecture, the CA serves 1 million subscribers and 1 million
relying parties, via 1,000 ISPs.

Other assumptions we need are these.

Assumption 1.  Each use of the OCSP protocol consumes 6 kilobits of
network resource.  This number includes the signature on the OCSP
response (assumed to be 1024b or 170 base64 characters), but it also
includes bits associated with establishing and destroying a TCP
connection and sending the HTTP message.

Assumption 2.  In the case of CRLs over HTTP, let's assume that the 1
million subscribers are assigned to 500 distribution points, and that
10% of subscribers are revoked at all times.  This situation might
obtain in a corporate setting, where certificates are issued with a one
year validity, they are revoked when the holder leaves the corporation
and the corporation suffers a 10% staff turnover.  I believe these are
very conservative assumptions.  Under these assumptions, the network
resource consumed by retrieving a distribution point entry may be 50kb,
including the bits associated with the connection and message.  While
this number is almost ten times that for OCSP, it is much more
efficient, because it conveys information about 2,000 certificates.

Assumption 3.  Each relying party validates 0.01 certificates per second
during the "busy-hour" (this pattern of behavior  is consistent with use
for signed and encrypted email, in which all relying parties work
through their "overnight" email first thing in the morning).

Assumption 4.  The relying parties are spread geographically over three
time zones.

Assumption 5.  In order to keep delays caused by contention for shared
resources to an acceptable level, shared components will be engineered
with a capacity three times the calculated busy-hour average demand.

In the case of the OCSP protocol …

OCSP component 2 (relying party HTTP cache).  The probability of a hit
on the relying party's cache is zero.

OCSP component 3 (relying party data-link).  The average resource
consumption in the data-link between the relying party and the ISP is
6kb * 0.01 per sec = 60b/s.

OCSP component 5 (ISP HTTP cache).  The probability of a hit on the
ISP's cache is essentially zero (the ISP receives 36,000 requests during
the busy-hour.  If you pick at random, from 1 million items, 36,000
times (replacing them after each pick), then the probability of picking
the same item twice is negligible).

OCSP component 6 (ISP data-link).  Each ISP passes 36,000 requests per
hour to the Internet backbone.  So, the resource consumed in the
data-link between the ISP and the Internet backbone is 1,000 * 60b/s =
60kb/s.  Applying Assumption 5, a 256kb/s data link is required.

OCSP component 8 (CA data-link).  If the ISPs each serve one time zone,
then 333 of them will be generating busy-hour traffic levels at the same
time.  Therefore, resource consumption in the data-link between the
Internet and the CA will be 333 * 60kb/s = 20Mb/s.  So again, by
Assumption 5, a 60Mb/s ATM link is required.

OCSP component 9 (CA HTTP cache).  The CA's cache outputs is 36,000 *
333 = 12 million requests per hour.  So, a database capable of serving
3,333 read operations per second is required.

OCSP component 10 (CA signature facility).  If the CA takes 3 hours to
replenish its cache with a new entry for each of its 1 million
subscribers, then the CA's signature facility must support a rate of 90
signatures per second, and responses may be up to three hours out of
date.

In the case of the CRLs over HTTP protocol. …

CRLs over HTTP component 2 (relying party HTTP cache).  The probability
of a hit on the relying party's cache is zero.

CRLs over HTTP component 3 (relying party data-link).  The average
resource consumption in the data-link between the relying party and the
ISP is 50kb * 0.01 per sec = 500b/s.

CRLs over HTTP component 5 (ISP HTTP Cache).  The ISP's HTTP cache
receives 36,000 requests per hour for one of 500 distribution points.
Therefore, the probability of a cache hit is 0.986.  Although each
request consumes about ten times as much network resource, only slightly
more than one in every hundred requests are transferred to the Internet.
 So the amount of Internet traffic generated is approximately one tenth.

CRLs over HTTP component 6 (ISP data-link). The average data rate
transferred by the ISP cache to the Internet is the number of relying
parties times the average data rate per relying party times one minus
the efficiency of the case.  I.e. 1,000 * 500 * (1 - 0.986) b/s.= 7
kb/s.  Therefore, by Assumption 5, a 32kb/s link would be adequate
between the ISP and the Internet backbone.

CRLs over HTTP component 8 (CA data-link).  If the ISPs each serve one
time zone, then 333 of them will be generating busy-hour traffic levels
at the same time.  Therefore, resource consumption in the data-link
between the Internet and the CA will be 333 * 7 kb/s = 2.3 Mb/s.  So, by
Assumption 5, a 7Mb/s data link is required between the Internet and the
CA.

CRLs over HTTP component 9 (CA HTTP cache).  The CA's cache receives 333
* 500 requests per hour.   So, a database capable of servicing 50 read
operations per second is required.

CRLs over HTTP component 10 (CA signature facility).  If the CA were
capable of performing 90 signature operations per second, then
theoretically, it could update all of its 500 entries once every six
seconds.  If, however, it were to update them every three hours, then
its signature capacity must be 0.04 signatures per second.

--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: [email-masked].

Date:         Mon, 1 Dec 1997 21:08:24 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Question about SubjectAltNames
To: [email-masked]
Status:

I have a situation where the subject DN for a certificate does not
contain a good displayable name for the person that the certificate is
issued for. I would put a displayable name of some type in the
subjectAltName field, but cannot figure out how this should work.  This
is no such thing as a Universial Name field in the GeneralName
structure.  Is the correct way to go about this to create an x500Address
with a cn field? or somthing else?  I've looked in serveral places and
cannot figure this out.  I would expect due to the uniqueness of a
Subject DN that this problem may crop up in more that one context.  Is
this something that needs to be addressed in the PKIX documents?

jim schaad

Date:         Tue, 2 Dec 1997 14:16:22 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

Snip
:
:Alternative resolutions are:
:- prohibit the option (the status quo);
:- permit the option freely;
:- permit the option but recommend against its use because of
:interoperability concerns.
:
:The third alternative seems to have most support, and seems to me to
:present the best resolution.

I can  support this solution, as a reasonable compromise.

:
:Warwick
:
:
:
:At 09:33 AM 12/1/97 -0500, Simonetti David wrote:
:>Sharon et al,
:>
:>I agree with you, and also agree with the text proposed by Tim Polk
:>which is largely similar to that used in the ISO draft cert management
:>standard.  I was surprised when the revision of X.509 posted in October
:>did not address the defect report that you generated which was accepted
:>in July.
:>
:>I do recommend one additional statement be added which I had discussed
:>with you, Sharon, at a previous time:
:>
:>"If this extension is flagged critical and a certificate using system
:>does not recognize the extension field type, then the system must
:>consider the certificate invalid."
:>
:>Most might not think that there is merit in this statement, since it is
:>basically the blanket statement that appears in X.509 for processing
:>critical extensions.  However, the conflicting opinion is that even if
:>the extension is critical and cannot be processed, the processing system
:>can always default to the full CRL published by the CA.  I do not agree
:>with this reasoning, and it is absolutely not true when the defect
:>report text is entered into X.509.  Hence, I recommend that it be made
:>explicitly obvious.
:>
:>Dave Simonetti
:>
:>Sharon Boeyen wrote:
:>>
:>> There already is a defect report issued against X.509. There was lengthy
:>> debate on the X.500 list prior to submission of that defect report (back
:>> about 10 months ago now) and at that time the consensus on the X.509
:>> list was that the full CRL WAS still required UNLESS all certificates
:>> issued by a CA contained the crlDistributionPoints extension as critical
:>> AND the crlDistributionPoints themselves (as a set) addressed all
:>> revocation reasons and all certificates issued by the CA. The defect
:>> report only addresses that case because it was the only case the group
:>> felt was a defect.
:>>
:>> Why do we think that those that opposed loosening the restrictions 10
:>> months ago would support it now? and what has changed in that time?
:>>
:>> I still have paper copies of some of the email interactions from that
:>> earlier discussion (I probably deleted the soft copies) if you're
:>> interested in the nature of the debate back then. I was quite surprised
:>> that more people who are on both lists didn't participate in the
:>> discussion at that time.
:>>
:>> ------------------
:>> Sharon Boeyen
:>> Entrust Technologies
:>>
:>> mailto:[email-masked]       Tel: (613) 247-3181
:>> http://www.entrust.com          Fax: (613) 247-3690
:>>          Orchestrating Enterprise Security
:>>
:>> >----------
:>> >From:  Warwick Ford[SMTP:[email-masked]]
:>> >Sent:  November 30, 1997 3:51 PM
:>> >To:    Sharon Boeyen; [email-masked]
:>> >Subject:       Re: [IETF-PKIX] Comment on PKIX-1
:>> >
:>> >Sharon:
:>> >
:>> >I have discussed this issue, from the X.509 perspective, with Hoyt.  He
:>> >concurs with me that the fault lies in the X.509 text, in permitting
:one to
:>> >interpret that "in order to conform to X.509, a CA MUST also publish a
:full
:>> >CRL at the CA entry".  This is certainly not the intent.  Whether or
not a
:>> >CA publishes a CRL is a matter of policy.  Under some policies (e.g.,
SET
:>> >Cardholder) CRLs may never be used.  Furthermore, other revocation
schemes
:>> >may well replace CRLs in some environments soon.  We shall clarify this
in
:>> >a defect report at the first opportunity.
:>> >
:>> >Therefore, there is no need, stemming from this argument, to permit the
:CRL
:>> >Distribution Points extension to be critical.  Given the
interoperability
:>> >problems that would result from making this extension critical, I see
good
:>> >reason to keep Part I as is.
:>> >
:>> >Regards,
:>> >Warwick
:>> >
:>> >
:>> >At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
:>> >>In a final runthrough of the PKIX-1 text I noticed what I believe to
be
:>> >>an overlooked error.
:>> >>
:>> >>For crlDistributionPoints PKIX-1 currently mandates that this
extension
:>> >>be non-critical. Surely it needs to allow that this be optionally made
:>> >>critical.
:>> >>
:>> >>If they are non-critical, then in order to conform to X.509, a CA MUST
:>> >>also publish a full CRL at the CA entry, in addition to the individual
:>> >>distribution points CRLs.
:>> >>
:>> >>It is ONLY when all certs issued by a CA have the CRL Distribution
:>> >>Points extension CRITICAL, that duplication of the crl info at the CA
:>> >>entry as a single monstrous CRL is optional.
:>> >>
:>> >>This is, I believe, the ONLY scaleable way to issue revocation lists
:>> >>today and PKIX-1 should not mandate that it be disallowed.
:>> >>
:>> >>Sorry for this coming in so late, but I only caught it in my final
:>> >>reading.
:>> >>
:>> >>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
:>> >>you separately.
:>> >>
:>> >>Sharon
:>> >>
:>> >>
:>> >>------------------
:>> >>Sharon Boeyen
:>> >>Entrust Technologies
:>> >>
:>> >>mailto:[email-masked]       Tel: (613) 247-3181
:>> >>http://www.entrust.com          Fax: (613) 247-3690
:>> >>         Orchestrating Enterprise Security
:>> >>
:>> >>
:>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
:>> >>
:>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
:>> >>
:>> >---------------------------------------------------------------------
:>> >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:>> >   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:>> >---------------------------------------------------------------------
:>> >
:>> >
:>
:>
:---------------------------------------------------------------------
:Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:---------------------------------------------------------------------

Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 7 (????/----) (0001D36D)

Date:         Mon, 1 Dec 1997 14:54:30 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      [IETF-PKIX] Security of International Commercial Transactions
To: [email-masked]
Status:

FYI ....

>     ===================================================================
>     Michael Versace
>     Federal Reserve Financial Services
>     Retail Payments Office
>     617-973-5958
>     [email-masked]
>
>
>
>  The International Chamber of Commerce today issued guidelines for ensuring
>  trustworthy digital transactions over the Internet.  The guidelines,
>  "General Usage in International Digitally Ensured Commerce" ("GUIDEC") are
>  available at www.iccwbo.org.  GUIDEC was announced at the Int'l Chamber's
>  commerce in Paris.
>
>  Peter Brown
>  [email-masked]
>

Date:         Mon, 1 Dec 1997 13:23:59 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

I agree as well.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Simonetti David[SMTP:[email-masked]]
>Sent:  December 1, 1997 1:20 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>
>I support the third alternative as well, and believe that the text Tim
>proposed addresses it well.
>
>Dave S.
>
>Warwick Ford wrote:
>>
><snip>
>>
>> Alternative resolutions are:
>> - prohibit the option (the status quo);
>> - permit the option freely;
>> - permit the option but recommend against its use because of
>> interoperability concerns.
>>
>> The third alternative seems to have most support, and seems to me to
>> present the best resolution.
>>
>> Warwick
>>
>

Date:         Mon, 1 Dec 1997 13:20:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

I support the third alternative as well, and believe that the text Tim
proposed addresses it well.

Dave S.

Warwick Ford wrote:
>
<snip>
>
> Alternative resolutions are:
> - prohibit the option (the status quo);
> - permit the option freely;
> - permit the option but recommend against its use because of
> interoperability concerns.
>
> The third alternative seems to have most support, and seems to me to
> present the best resolution.
>
> Warwick
>

Date:         Mon, 1 Dec 1997 13:03:12 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

Let me try to unravel the different issues we seem to have here.

First is the broad question of whether X.509 should mandate issuance of
CRLs.  This has apparently been discussed on the X.500 list, and it has
been agreed that a defect resolution is needed to clarify the situation.
It also appears that there are different opinions on what the resolution
should be.  My view, which does not derive from anything to do with
criticality of CRL Distribution Points, is that X.509 should not mandate
issuance of CRLs of any sort.  It is entirely a matter of policy as to
whether a CA issues full CRLs, no CRLs, CRLs-from-distribution-points, or
uses OCSP or a list taped to the wall.  The certificate policy in use may
well require some particular revocation practice, but this is different to
mandating a practice in X.509.  Frankly I cannot see anything more
stringent being acceptable to the X.509 user community at large.

As a separate point, we can observe that X.509 does permit CRL Distribution
Points to be critical and, for that circumstance, defines the semantics.
This is an option that communities can choose to use if they wish.

The current question for the PKIX community is whether we want to support
the above option in the PKIX profile.  Clearly, some participants see this
option as being useful.  The objection to it is that use of this option is
likely to lead to non-interoperability, whereas if they used noncritical
CRL Distribution Points instead they would achieve all the scalability
benefits of CRL distribution points with reduced interoperability exposure.

Alternative resolutions are:
- prohibit the option (the status quo);
- permit the option freely;
- permit the option but recommend against its use because of
interoperability concerns.

The third alternative seems to have most support, and seems to me to
present the best resolution.

Warwick

At 09:33 AM 12/1/97 -0500, Simonetti David wrote:
>Sharon et al,
>
>I agree with you, and also agree with the text proposed by Tim Polk
>which is largely similar to that used in the ISO draft cert management
>standard.  I was surprised when the revision of X.509 posted in October
>did not address the defect report that you generated which was accepted
>in July.
>
>I do recommend one additional statement be added which I had discussed
>with you, Sharon, at a previous time:
>
>"If this extension is flagged critical and a certificate using system
>does not recognize the extension field type, then the system must
>consider the certificate invalid."
>
>Most might not think that there is merit in this statement, since it is
>basically the blanket statement that appears in X.509 for processing
>critical extensions.  However, the conflicting opinion is that even if
>the extension is critical and cannot be processed, the processing system
>can always default to the full CRL published by the CA.  I do not agree
>with this reasoning, and it is absolutely not true when the defect
>report text is entered into X.509.  Hence, I recommend that it be made
>explicitly obvious.
>
>Dave Simonetti
>
>Sharon Boeyen wrote:
>>
>> There already is a defect report issued against X.509. There was lengthy
>> debate on the X.500 list prior to submission of that defect report (back
>> about 10 months ago now) and at that time the consensus on the X.509
>> list was that the full CRL WAS still required UNLESS all certificates
>> issued by a CA contained the crlDistributionPoints extension as critical
>> AND the crlDistributionPoints themselves (as a set) addressed all
>> revocation reasons and all certificates issued by the CA. The defect
>> report only addresses that case because it was the only case the group
>> felt was a defect.
>>
>> Why do we think that those that opposed loosening the restrictions 10
>> months ago would support it now? and what has changed in that time?
>>
>> I still have paper copies of some of the email interactions from that
>> earlier discussion (I probably deleted the soft copies) if you're
>> interested in the nature of the debate back then. I was quite surprised
>> that more people who are on both lists didn't participate in the
>> discussion at that time.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies
>>
>> mailto:[email-masked]       Tel: (613) 247-3181
>> http://www.entrust.com          Fax: (613) 247-3690
>>          Orchestrating Enterprise Security
>>
>> >----------
>> >From:  Warwick Ford[SMTP:[email-masked]]
>> >Sent:  November 30, 1997 3:51 PM
>> >To:    Sharon Boeyen; [email-masked]
>> >Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>> >
>> >Sharon:
>> >
>> >I have discussed this issue, from the X.509 perspective, with Hoyt.  He
>> >concurs with me that the fault lies in the X.509 text, in permitting
one to
>> >interpret that "in order to conform to X.509, a CA MUST also publish a
full
>> >CRL at the CA entry".  This is certainly not the intent.  Whether or not a
>> >CA publishes a CRL is a matter of policy.  Under some policies (e.g., SET
>> >Cardholder) CRLs may never be used.  Furthermore, other revocation schemes
>> >may well replace CRLs in some environments soon.  We shall clarify this in
>> >a defect report at the first opportunity.
>> >
>> >Therefore, there is no need, stemming from this argument, to permit the
CRL
>> >Distribution Points extension to be critical.  Given the interoperability
>> >problems that would result from making this extension critical, I see good
>> >reason to keep Part I as is.
>> >
>> >Regards,
>> >Warwick
>> >
>> >
>> >At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>> >>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>> >>an overlooked error.
>> >>
>> >>For crlDistributionPoints PKIX-1 currently mandates that this extension
>> >>be non-critical. Surely it needs to allow that this be optionally made
>> >>critical.
>> >>
>> >>If they are non-critical, then in order to conform to X.509, a CA MUST
>> >>also publish a full CRL at the CA entry, in addition to the individual
>> >>distribution points CRLs.
>> >>
>> >>It is ONLY when all certs issued by a CA have the CRL Distribution
>> >>Points extension CRITICAL, that duplication of the crl info at the CA
>> >>entry as a single monstrous CRL is optional.
>> >>
>> >>This is, I believe, the ONLY scaleable way to issue revocation lists
>> >>today and PKIX-1 should not mandate that it be disallowed.
>> >>
>> >>Sorry for this coming in so late, but I only caught it in my final
>> >>reading.
>> >>
>> >>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>> >>you separately.
>> >>
>> >>Sharon
>> >>
>> >>
>> >>------------------
>> >>Sharon Boeyen
>> >>Entrust Technologies
>> >>
>> >>mailto:[email-masked]       Tel: (613) 247-3181
>> >>http://www.entrust.com          Fax: (613) 247-3690
>> >>         Orchestrating Enterprise Security
>> >>
>> >>
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>> >>
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>> >>
>> >---------------------------------------------------------------------
>> >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>> >   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>> >---------------------------------------------------------------------
>> >
>> >
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 1 Dec 1997 12:15:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] DER Encoding of Key Usage Extension?
To: [email-masked]
Status:

> From: Anette Byskov <[email-masked]>
>
> A short question: how to encode the key usage extension with, let's say,
> bit 0, 1, and 3 set. Is it
>
>       03 02 04 D0  (BIT STRING with value '1101')
> or
>       03 02 04 B0  (BIT STRING with value '1011')
>
> I know this sort of question has been asked before on this list but in
> that example bit 0 and 4  were set (which is encoded 03 02 03 88 in both
> cases).

X.680 Section 19.2: "The first bit in a bit string is called bit zero."

X.690 Section 6.2: "the bits of an octet are numbered from 8 to 1, where
  bit 8 is the "most significant bit", and bit 1 is the "least significant
  bit"."

X.690 Section 8.6.2.1: "The bits in a bitstring, commencing with the first
  bit and proceeding to the last bit, shall be placed in bits 8 to 1 of
  the first ... octet, followed by ..."

So, bit 0 of the bitstring would go in bit 8 of the first octet, and
your first example (BIT STRING '1101' -> BER octets '03 02 04 D0')
is the correct one.

Date:         Mon, 1 Dec 1997 09:43:50 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

David, I agree with the additional phrase that you'd like added.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Simonetti David[SMTP:[email-masked]]
>Sent:  December 1, 1997 9:33 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>
>Sharon et al,
>
>I agree with you, and also agree with the text proposed by Tim Polk
>which is largely similar to that used in the ISO draft cert management
>standard.  I was surprised when the revision of X.509 posted in October
>did not address the defect report that you generated which was accepted
>in July.
>
>I do recommend one additional statement be added which I had discussed
>with you, Sharon, at a previous time:
>
>"If this extension is flagged critical and a certificate using system
>does not recognize the extension field type, then the system must
>consider the certificate invalid."
>
>Most might not think that there is merit in this statement, since it is
>basically the blanket statement that appears in X.509 for processing
>critical extensions.  However, the conflicting opinion is that even if
>the extension is critical and cannot be processed, the processing system
>can always default to the full CRL published by the CA.  I do not agree
>with this reasoning, and it is absolutely not true when the defect
>report text is entered into X.509.  Hence, I recommend that it be made
>explicitly obvious.
>
>Dave Simonetti
>
>Sharon Boeyen wrote:
>>
>> There already is a defect report issued against X.509. There was lengthy
>> debate on the X.500 list prior to submission of that defect report (back
>> about 10 months ago now) and at that time the consensus on the X.509
>> list was that the full CRL WAS still required UNLESS all certificates
>> issued by a CA contained the crlDistributionPoints extension as critical
>> AND the crlDistributionPoints themselves (as a set) addressed all
>> revocation reasons and all certificates issued by the CA. The defect
>> report only addresses that case because it was the only case the group
>> felt was a defect.
>>
>> Why do we think that those that opposed loosening the restrictions 10
>> months ago would support it now? and what has changed in that time?
>>
>> I still have paper copies of some of the email interactions from that
>> earlier discussion (I probably deleted the soft copies) if you're
>> interested in the nature of the debate back then. I was quite surprised
>> that more people who are on both lists didn't participate in the
>> discussion at that time.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies
>>
>> mailto:[email-masked]       Tel: (613) 247-3181
>> http://www.entrust.com          Fax: (613) 247-3690
>>          Orchestrating Enterprise Security
>>
>> >----------
>> >From:  Warwick Ford[SMTP:[email-masked]]
>> >Sent:  November 30, 1997 3:51 PM
>> >To:    Sharon Boeyen; [email-masked]
>> >Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>> >
>> >Sharon:
>> >
>> >I have discussed this issue, from the X.509 perspective, with Hoyt.  He
>> >concurs with me that the fault lies in the X.509 text, in permitting one
>>to
>> >interpret that "in order to conform to X.509, a CA MUST also publish a
>>full
>> >CRL at the CA entry".  This is certainly not the intent.  Whether or not a
>> >CA publishes a CRL is a matter of policy.  Under some policies (e.g., SET
>> >Cardholder) CRLs may never be used.  Furthermore, other revocation schemes
>> >may well replace CRLs in some environments soon.  We shall clarify this in
>> >a defect report at the first opportunity.
>> >
>> >Therefore, there is no need, stemming from this argument, to permit the
>>CRL
>> >Distribution Points extension to be critical.  Given the interoperability
>> >problems that would result from making this extension critical, I see good
>> >reason to keep Part I as is.
>> >
>> >Regards,
>> >Warwick
>> >
>> >
>> >At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>> >>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>> >>an overlooked error.
>> >>
>> >>For crlDistributionPoints PKIX-1 currently mandates that this extension
>> >>be non-critical. Surely it needs to allow that this be optionally made
>> >>critical.
>> >>
>> >>If they are non-critical, then in order to conform to X.509, a CA MUST
>> >>also publish a full CRL at the CA entry, in addition to the individual
>> >>distribution points CRLs.
>> >>
>> >>It is ONLY when all certs issued by a CA have the CRL Distribution
>> >>Points extension CRITICAL, that duplication of the crl info at the CA
>> >>entry as a single monstrous CRL is optional.
>> >>
>> >>This is, I believe, the ONLY scaleable way to issue revocation lists
>> >>today and PKIX-1 should not mandate that it be disallowed.
>> >>
>> >>Sorry for this coming in so late, but I only caught it in my final
>> >>reading.
>> >>
>> >>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>> >>you separately.
>> >>
>> >>Sharon
>> >>
>> >>
>> >>------------------
>> >>Sharon Boeyen
>> >>Entrust Technologies
>> >>
>> >>mailto:[email-masked]       Tel: (613) 247-3181
>> >>http://www.entrust.com          Fax: (613) 247-3690
>> >>         Orchestrating Enterprise Security
>> >>
>> >>
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>> >>
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>> >>
>> >---------------------------------------------------------------------
>> >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>> >   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>> >---------------------------------------------------------------------
>> >
>> >
>

Date:         Mon, 1 Dec 1997 09:48:47 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

Unless someone has performed some CRL modeling and would like to
volunteer their data, I am opposed to restrictions on CRL
implementations.  We may very well find that full CRLs are completely
unmanagable, and that partial CRLs (by reason code) or OCSP are the only
practical solutions.  Until someone has some data that can back up one
or the other, I am opposed to saying one or the other is the "correct"
solution.

Hence, I agree with Sharon's statement that systems BE ALLOWED to
implement CRL distribution points as they see fit.  There is no
interoperability problem here.  If the extension is critical and you
can't process it, then fail just like any other critical extension.

Dave Simonetti

Charles Moore wrote:
>
> -----Original Message-----
> From: Sharon Boeyen <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Saturday, 29 November 1997 8:25
> Subject: Re: [IETF-PKIX] Comment on PKIX-1
>
> :Charles,
> :
> :The use of  distribution points is not tied necessarily to any reason
> :codes. The main purpose of distribution points is to allow the CA to
> :publish its revocation list in "chunks" in a set of directory entries
> :rather than as a single monolithic attribute value at the CA entry
> :(which I believe everyone agrees is NOT scalable).
> There are a number of issues assocaited with "scalablity" here as it means
> differnt things depending on the "implementation one has in mind".
> :
> :Let's also separate the functionality and requirements of a CA from
> :those of the certificate processing software. CA's are (and should be)
> :free to determine their own means for dealing with the revocation of
> :certificates.
> In a closed community Yes, in a global PKI depending on what we want to
> achieve.
> I would like to start with interoperability at the technical level ( what we
> are discussing) and allow policy to determine
> what communities will interwork, We should not define a technical solution
> that is broken from the start.
>
> :Some may choose (if they are in very small domains) to use
> :a single monolithic revocation list and publish this at the CA entry,
> :others may choose to use distribution points, others may choose to use
> :OCSP, or other protocols and some may choose a combination of these
> :approaches.
> Agree.
>
> : What I am proposing is that a CA be ALLOWED to choose the
> :distribution point option and be ALLOWED to make that extension
> :critical.
> Only if it does not break the infrastructure for everyone else; closed
> systems can always do as they choose.
>
> :One reason to allow that option is that it is the only way to
> :remain conformant with X.509
>
> What my latest copy says:
> "Inclusion of any extension in a certificate or CRL is at the option of the
> authority issuing that certificate or CRL.
> In a certificate or CRL, an extension is flagged as being either critical or
> non-critical. If an extension is flagged critical and a certificate-using
> system does not recognize the extension field type or does not implement the
> semantics of the extension, then that system shall consider the certificate
> invalid. If an extension is flagged non-critical, a certificate-using system
> that does not recognize or implement that extension type may process the
> remainder of the certificate ignoring the extension. Extension type
> definitions in this Directory Specification indicate if the extension is
> always critical, always non-critical, or if criticality can be decided by
> the certificate or CRL issuer. The reason for requiring some extensions to
> be always non-critical is to allow certificate-using implementations which
> do not need to use such extensions to omit support for them without
> jeopardizing the ability to interoperate with all certification authorities"
>
> I believe the point is well defined in the last sentence: namely "The reason
> for requiring some extensions to be always non-critical is to allow
> certificate-using implementations which do not need to use such extensions
> to omit support for them without jeopardizing the ability to interoperate
> with all certification authorities"
>
> The use of  non-critical extension allows both, the support for critical
> breaks the infrastructure.
>
> It is this lack of interoperability that is the concern.
>
> : and NOT require the duplication of effort
> :with a full crl.
> The CRL is always there, so there should not be a duplication of effort; my
> understanding of the proposal is to support key compromise issues and speed
> of CRL probagation?
>
> :However, there may be other reasons a CA chooses to set
> :this critical, some may be policy related. I am merely saying that this
> :should be allowed.
>
> :
> :If a certificate using system does not support this extension then it
> :can't trust that certificate, as stated in X.509.
> See above.
> :
> :If you issue certificates with the crlDistributionPoint extension
> :non-critical then either you conform with X.509 and publish a full crl
> :at the CA entry for use by certificate using systems that don't support
> :the extension (in some cases that can be impossible  given its potential
> :size) or you don't confom with X.509 and don't publish the full CRL.. In
> :the first case you have totally defeated the purpose of distribution
> :points and I don't think anyone would agree that it is a reasonable
> :approach.
> If you start with a design that makes CRL's not work then this is a self
> fullfilling argument; I dont support this as an absolute
> condition.
>
> I will agree that you can design a system to achive this result, but this
> can probally always be done.
>
> I dont see in the standard or anywhere else a requiremnt that
> CrlDistribution points are a replacement for CRL's as you propose
>  otherwise it would have been defined as critical in the standard.).
>
> : In the second case the certificate using system can't trust
> :the certificate anyway so you have achieved nothing.
> See above.
> :
> :snip..
> :
> :I hope this clarifies what I intended.
>
> Yes, but not resolution of the issue at hand.
>
> The extension should remain non-critical, for the reasons above.
>
> :
> :Sharon
> :
> :
> :
> :------------------
> :Sharon Boeyen
> :Entrust Technologies
> :
> :mailto:[email-masked]       Tel: (613) 247-3181
> :http://www.entrust.com          Fax: (613) 247-3690
> :         Orchestrating Enterprise Security
> :
> :
> :>----------
> :>From:  Charles Moore[SMTP:[email-masked]]
> :>Sent:  November 28, 1997 4:09 PM
> :>To:    [email-masked]
> :>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
> :>
> :><<File: smime.p7s>>
> :>
> :>-----Original Message-----
> :>From: Tim Polk <[email-masked]>
> :>To: [email-masked] <[email-masked]>
> :>Date: Saturday, 29 November 1997 5:33
> :>Subject: Re: [IETF-PKIX] Comment on PKIX-1
> :>
> :>
> :>:Sharon,
> :>:
> :>My understanding of the proposal is to force all client processing systems
> :>to handle
> :>distribution point processing ( if they dont then the certificates are not
> :>usable ) purely to support key or CA compromise
> :>probagation.
> :>
> :>I would disagree that the proposal is scalable as it requires special
> :>processing in all end systems in case someone uses this extension. The
> :>result is more likely to be a loss of interoperability for the existing
> :>systems or those that wish to handle
> :>key compromise or other issues via say OCSP.
> :>
> :>I believe the text should stay as is, and disagree in making the CRL
> :>distribution
> :>point extension critical, as it will not help either interoperability or
> :>address the issue of probagation of compromise
> :>within a hetrogenious client envionment.
> :>
> :>
> :>:I would agree that scalability *demands* the ability to split CRLs with
> :>:the distribution point mechanism.  The original rationale for
> :>:non-critical status for distribution points was something like
> :>:>>>>
> :>:> If the CA only issues CRLs through distribution points and the client
> :>:> does not implement distribution points, it will not find a CRL and
> :>:> will reject the path.  This is the same result as encountering an
> :>:> unrecognized critical extension, so there is no reason to make it
> :>:> critical.
> :>:<<<<
> :>:
> :>:This is contradicted by the X.509 requirement for full CRLs unless the
> :>:distribution point is critical.  So, I would say you are correct;
> :>:optionally critical is the better choice.  I would propose to insert two
> :>:paragraphs from X.509 into the profile....
> :>:>>>>
> :>:> This extension may, at the option of the certificate issuer, be either
> :>:> critical or non-critical. In the interests of interoperability, it is
> :>:> recommended that it be flagged non-critical. If the CRL distribution
> :>:> point extension is made critical, the CA shall ensure that the
> :>:> distribution points cover reason codes keyCompromise and/or
> :>:> cACompromise whichever is applicable.
> :>:>
> :>:> If this extension is flagged critical then a certificate-using system
> :>:> shall not use the certificate without first retrieving and checking a
> :>:> CRL from one of the nominated distribution points covering, at a
> :>:> minimum, the reason code keyCompromise (for an end-entity certificate)
> :>:> or cACompromise (for a CA-certificate).
> :>:>
> :>:<<<<
> :>:
> :>:I believe the change would be appropriate.  Any other opinions?
> :>:
> :>:Tim Polk
> :>:
> :>:At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
> :>:>In a final runthrough of the PKIX-1 text I noticed what I believe to be
> :>:
> :>:>an overlooked error.
> :>:>
> :>:>For crlDistributionPoints PKIX-1 currently mandates that this extension
> :>:
> :>:>be non-critical. Surely it needs to allow that this be optionally made
> :>:>critical.
> :>:>
> :>:>If they are non-critical, then in order to conform to X.509, a CA MUST
> :>:>also publish a full CRL at the CA entry, in addition to the individual
> :>:>distribution points CRLs.
> :>:>
> :>:>It is ONLY when all certs issued by a CA have the CRL Distribution
> :>:>Points extension CRITICAL, that duplication of the crl info at the CA
> :>:>entry as a single monstrous CRL is optional.
> :>:>
> :>:>This is, I believe, the ONLY scaleable way to issue revocation lists
> :>:>today and PKIX-1 should not mandate that it be disallowed.
> :>:>
> :>:>Sorry for this coming in so late, but I only caught it in my final
> :>:>reading.
> :>:>
> :>:>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
> :>:>you separately.
> :>:>
> :>:>Sharon
> :>:>
> :>:>
> :>:>------------------
> :>:>Sharon Boeyen
> :>:>Entrust Technologies
> :>:>
> :>:>mailto:[email-masked]       Tel: (613) 247-3181
> :>:>http://www.entrust.com          Fax: (613) 247-3690
> :>:>         Orchestrating Enterprise Security
> :>:>
> :>:>
> :>:>Attachment Converted: "c:\program
> :>:files\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
> :>:>
> :>:>Attachment Converted: "c:\program
> :>:files\eudora\attach\%-1%Body_Txt.txt.ent.ent"
> :>:>
> :>
> :>

Date:         Mon, 1 Dec 1997 09:28:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

See comments interspersed below.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  November 28, 1997 7:37 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>
>
>:Some may choose (if they are in very small domains) to use
>:a single monolithic revocation list and publish this at the CA entry,
>:others may choose to use distribution points, others may choose to use
>:OCSP, or other protocols and some may choose a combination of these
>:approaches.
>Agree.
>
>: What I am proposing is that a CA be ALLOWED to choose the
>:distribution point option and be ALLOWED to make that extension
>:critical.
>Only if it does not break the infrastructure for everyone else; closed
>systems can always do as they choose.

If it is critical to a CA that the revocation information be checked
prior to the certificate being trusted and the CA is using distribution
points to distribute their revocation information, the CA should be
permitted to make that critical. If a processing system can't handle the
distribution point, the certificate can't be trusted. That doe not mean
that the system are not interoperable, just that the certificate can't
be trusted which was the intent of the CA when it issued the certificate
containing that extension.
>
>:One reason to allow that option is that it is the only way to
>:remain conformant with X.509
>
>What my latest copy says:
>"Inclusion of any extension in a certificate or CRL is at the option of the
...STUFF DELETED ...

>the certificate or CRL issuer. The reason for requiring some extensions to
>be always non-critical is to allow certificate-using implementations which
>do not need to use such extensions to omit support for them without
>jeopardizing the ability to interoperate with all certification authorities"
>
>I believe the point is well defined in the last sentence: namely "The reason
>for requiring some extensions to be always non-critical is to allow
>certificate-using implementations which do not need to use such extensions
>to omit support for them without jeopardizing the ability to interoperate
>with all certification authorities"

As a direct contributor to that work I am very familiar with its text.
Note as well the phrase in that sentence "which do not need to use such
extensions". The case I am talking about is one where the certificate
using implementations DO need to use the extension if they want to be
able to trust the certificate.
>
>The use of  non-critical extension allows both, the support for critical
>breaks the infrastructure.

I disagree. The use of non-critical breaks trust, unless the certificate
using system can check revocation information and a full CRL can be too
large to be possible. The size of a single CRL is the reason crl
distribution points were created in the first place!
>
>The CRL is always there, so there should not be a duplication of effort; my
>understanding of the proposal is to support key compromise issues and speed
>of CRL probagation?

That is a misunderstanding of the proposal. CRL distribution points are
a way to break revocation information into smaller lists. These lists
can be based on revocation reasons or may include all reasons. The
proposal has nothing specific to do with key compromise whatsoever. I
think you misunderstand distribution points completely. In X.509 we
defined these with the intent that it would allow a CA to publishe these
instead of a single CRL, or in addition to a full  CRL, or not at all,
depending on the environment in which that CA operates. In largescale
PKI, any option that requires a single full CRL to be published as a
single entity is simply not workable. That was definitely the intent
when these were defined in X.509.
>
>
>I dont see in the standard or anywhere else a requiremnt that
>CrlDistribution points are a replacement for CRL's as you propose
> otherwise it would have been defined as critical in the standard.).

Perhaps you have an outdated interim version of X.509. Check the
reference below for the final text.

As stated in 12.6.2 of X.509 "This extension may, at the option of the
certificate issuer, be either critical or non-critical".  That same
clause does recommend that it be flagged non-critical in the interests
of interoperability. and further require that where it is marked
critical it at least address the reason codes of key compromise or CA
key compromise.

Three points in that section.

First - it is recognized that there are environments where this will
have to be set to critical (e.g. very large PKI where full CRLs are too
big).

Second - it recommends that the extension be set to non-critical. I have
no problem with PKIX saying the same thing, but at the same time
recogizing that in some cases it will be critical.

Check also Note 5 of section 11.2 (Management of Certificates) in X.509
which states "If an extension affects the treatment of the list (e.g.
multiple CRLs must be scanned to examine the entire list of revoked
certificates, or an entry may represent a range of certificates) then
that extension SHALL be indicated as critical in the crlExtensions
field..." This is just another example of where X.509 recognizes that
this must be permitted and I am only asking that PKIX allow it as well.

Third is the discussion of key compromise. This is the minimum required
of a certificate using system when dealing with critical distribution
points - it must at least check a revocation list that covers this
reason code (according to 12.6.2). That should not be interpreted to
mean that distribtution points are used for key compromise and key
compromise only.
>
>

Date:         Mon, 1 Dec 1997 09:33:50 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

Sharon et al,

I agree with you, and also agree with the text proposed by Tim Polk
which is largely similar to that used in the ISO draft cert management
standard.  I was surprised when the revision of X.509 posted in October
did not address the defect report that you generated which was accepted
in July.

I do recommend one additional statement be added which I had discussed
with you, Sharon, at a previous time:

"If this extension is flagged critical and a certificate using system
does not recognize the extension field type, then the system must
consider the certificate invalid."

Most might not think that there is merit in this statement, since it is
basically the blanket statement that appears in X.509 for processing
critical extensions.  However, the conflicting opinion is that even if
the extension is critical and cannot be processed, the processing system
can always default to the full CRL published by the CA.  I do not agree
with this reasoning, and it is absolutely not true when the defect
report text is entered into X.509.  Hence, I recommend that it be made
explicitly obvious.

Dave Simonetti

Sharon Boeyen wrote:
>
> There already is a defect report issued against X.509. There was lengthy
> debate on the X.500 list prior to submission of that defect report (back
> about 10 months ago now) and at that time the consensus on the X.509
> list was that the full CRL WAS still required UNLESS all certificates
> issued by a CA contained the crlDistributionPoints extension as critical
> AND the crlDistributionPoints themselves (as a set) addressed all
> revocation reasons and all certificates issued by the CA. The defect
> report only addresses that case because it was the only case the group
> felt was a defect.
>
> Why do we think that those that opposed loosening the restrictions 10
> months ago would support it now? and what has changed in that time?
>
> I still have paper copies of some of the email interactions from that
> earlier discussion (I probably deleted the soft copies) if you're
> interested in the nature of the debate back then. I was quite surprised
> that more people who are on both lists didn't participate in the
> discussion at that time.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[email-masked]       Tel: (613) 247-3181
> http://www.entrust.com          Fax: (613) 247-3690
>          Orchestrating Enterprise Security
>
> >----------
> >From:  Warwick Ford[SMTP:[email-masked]]
> >Sent:  November 30, 1997 3:51 PM
> >To:    Sharon Boeyen; [email-masked]
> >Subject:       Re: [IETF-PKIX] Comment on PKIX-1
> >
> >Sharon:
> >
> >I have discussed this issue, from the X.509 perspective, with Hoyt.  He
> >concurs with me that the fault lies in the X.509 text, in permitting one to
> >interpret that "in order to conform to X.509, a CA MUST also publish a full
> >CRL at the CA entry".  This is certainly not the intent.  Whether or not a
> >CA publishes a CRL is a matter of policy.  Under some policies (e.g., SET
> >Cardholder) CRLs may never be used.  Furthermore, other revocation schemes
> >may well replace CRLs in some environments soon.  We shall clarify this in
> >a defect report at the first opportunity.
> >
> >Therefore, there is no need, stemming from this argument, to permit the CRL
> >Distribution Points extension to be critical.  Given the interoperability
> >problems that would result from making this extension critical, I see good
> >reason to keep Part I as is.
> >
> >Regards,
> >Warwick
> >
> >
> >At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
> >>In a final runthrough of the PKIX-1 text I noticed what I believe to be
> >>an overlooked error.
> >>
> >>For crlDistributionPoints PKIX-1 currently mandates that this extension
> >>be non-critical. Surely it needs to allow that this be optionally made
> >>critical.
> >>
> >>If they are non-critical, then in order to conform to X.509, a CA MUST
> >>also publish a full CRL at the CA entry, in addition to the individual
> >>distribution points CRLs.
> >>
> >>It is ONLY when all certs issued by a CA have the CRL Distribution
> >>Points extension CRITICAL, that duplication of the crl info at the CA
> >>entry as a single monstrous CRL is optional.
> >>
> >>This is, I believe, the ONLY scaleable way to issue revocation lists
> >>today and PKIX-1 should not mandate that it be disallowed.
> >>
> >>Sorry for this coming in so late, but I only caught it in my final
> >>reading.
> >>
> >>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
> >>you separately.
> >>
> >>Sharon
> >>
> >>
> >>------------------
> >>Sharon Boeyen
> >>Entrust Technologies
> >>
> >>mailto:[email-masked]       Tel: (613) 247-3181
> >>http://www.entrust.com          Fax: (613) 247-3690
> >>         Orchestrating Enterprise Security
> >>
> >>
> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
> >>
> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
> >>
> >---------------------------------------------------------------------
> >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
> >   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
> >---------------------------------------------------------------------
> >
> >

Date:         Sun, 30 Nov 1997 16:34:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
Comments: To: Warwick Ford <[email-masked]>
To: [email-masked]
Status:

There already is a defect report issued against X.509. There was lengthy
debate on the X.500 list prior to submission of that defect report (back
about 10 months ago now) and at that time the consensus on the X.509
list was that the full CRL WAS still required UNLESS all certificates
issued by a CA contained the crlDistributionPoints extension as critical
AND the crlDistributionPoints themselves (as a set) addressed all
revocation reasons and all certificates issued by the CA. The defect
report only addresses that case because it was the only case the group
felt was a defect.

Why do we think that those that opposed loosening the restrictions 10
months ago would support it now? and what has changed in that time?

I still have paper copies of some of the email interactions from that
earlier discussion (I probably deleted the soft copies) if you're
interested in the nature of the debate back then. I was quite surprised
that more people who are on both lists didn't participate in the
discussion at that time.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  November 30, 1997 3:51 PM
>To:    Sharon Boeyen; [email-masked]
>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>
>Sharon:
>
>I have discussed this issue, from the X.509 perspective, with Hoyt.  He
>concurs with me that the fault lies in the X.509 text, in permitting one to
>interpret that "in order to conform to X.509, a CA MUST also publish a full
>CRL at the CA entry".  This is certainly not the intent.  Whether or not a
>CA publishes a CRL is a matter of policy.  Under some policies (e.g., SET
>Cardholder) CRLs may never be used.  Furthermore, other revocation schemes
>may well replace CRLs in some environments soon.  We shall clarify this in
>a defect report at the first opportunity.
>
>Therefore, there is no need, stemming from this argument, to permit the CRL
>Distribution Points extension to be critical.  Given the interoperability
>problems that would result from making this extension critical, I see good
>reason to keep Part I as is.
>
>Regards,
>Warwick
>
>
>At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>>an overlooked error.
>>
>>For crlDistributionPoints PKIX-1 currently mandates that this extension
>>be non-critical. Surely it needs to allow that this be optionally made
>>critical.
>>
>>If they are non-critical, then in order to conform to X.509, a CA MUST
>>also publish a full CRL at the CA entry, in addition to the individual
>>distribution points CRLs.
>>
>>It is ONLY when all certs issued by a CA have the CRL Distribution
>>Points extension CRITICAL, that duplication of the crl info at the CA
>>entry as a single monstrous CRL is optional.
>>
>>This is, I believe, the ONLY scaleable way to issue revocation lists
>>today and PKIX-1 should not mandate that it be disallowed.
>>
>>Sorry for this coming in so late, but I only caught it in my final
>>reading.
>>
>>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>>you separately.
>>
>>Sharon
>>
>>
>>------------------
>>Sharon Boeyen
>>Entrust Technologies
>>
>>mailto:[email-masked]       Tel: (613) 247-3181
>>http://www.entrust.com          Fax: (613) 247-3690
>>         Orchestrating Enterprise Security
>>
>>
>>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>>
>>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>
>

Date:         Sun, 30 Nov 1997 12:51:20 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
Comments: To: [email-masked]
To: [email-masked]
Status:

Sharon:

I have discussed this issue, from the X.509 perspective, with Hoyt.  He
concurs with me that the fault lies in the X.509 text, in permitting one to
interpret that "in order to conform to X.509, a CA MUST also publish a full
CRL at the CA entry".  This is certainly not the intent.  Whether or not a
CA publishes a CRL is a matter of policy.  Under some policies (e.g., SET
Cardholder) CRLs may never be used.  Furthermore, other revocation schemes
may well replace CRLs in some environments soon.  We shall clarify this in
a defect report at the first opportunity.

Therefore, there is no need, stemming from this argument, to permit the CRL
Distribution Points extension to be critical.  Given the interoperability
problems that would result from making this extension critical, I see good
reason to keep Part I as is.

Regards,
Warwick

At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>an overlooked error.
>
>For crlDistributionPoints PKIX-1 currently mandates that this extension
>be non-critical. Surely it needs to allow that this be optionally made
>critical.
>
>If they are non-critical, then in order to conform to X.509, a CA MUST
>also publish a full CRL at the CA entry, in addition to the individual
>distribution points CRLs.
>
>It is ONLY when all certs issued by a CA have the CRL Distribution
>Points extension CRITICAL, that duplication of the crl info at the CA
>entry as a single monstrous CRL is optional.
>
>This is, I believe, the ONLY scaleable way to issue revocation lists
>today and PKIX-1 should not mandate that it be disallowed.
>
>Sorry for this coming in so late, but I only caught it in my final
>reading.
>
>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>you separately.
>
>Sharon
>
>
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>
>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sat, 29 Nov 1997 10:37:29 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

-----Original Message-----
From: Sharon Boeyen <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Saturday, 29 November 1997 8:25
Subject: Re: [IETF-PKIX] Comment on PKIX-1

:Charles,
:
:The use of  distribution points is not tied necessarily to any reason
:codes. The main purpose of distribution points is to allow the CA to
:publish its revocation list in "chunks" in a set of directory entries
:rather than as a single monolithic attribute value at the CA entry
:(which I believe everyone agrees is NOT scalable).
There are a number of issues assocaited with "scalablity" here as it means
differnt things depending on the "implementation one has in mind".
:
:Let's also separate the functionality and requirements of a CA from
:those of the certificate processing software. CA's are (and should be)
:free to determine their own means for dealing with the revocation of
:certificates.
In a closed community Yes, in a global PKI depending on what we want to
achieve.
I would like to start with interoperability at the technical level ( what we
are discussing) and allow policy to determine
what communities will interwork, We should not define a technical solution
that is broken from the start.

:Some may choose (if they are in very small domains) to use
:a single monolithic revocation list and publish this at the CA entry,
:others may choose to use distribution points, others may choose to use
:OCSP, or other protocols and some may choose a combination of these
:approaches.
Agree.

: What I am proposing is that a CA be ALLOWED to choose the
:distribution point option and be ALLOWED to make that extension
:critical.
Only if it does not break the infrastructure for everyone else; closed
systems can always do as they choose.

:One reason to allow that option is that it is the only way to
:remain conformant with X.509

What my latest copy says:
"Inclusion of any extension in a certificate or CRL is at the option of the
authority issuing that certificate or CRL.
In a certificate or CRL, an extension is flagged as being either critical or
non-critical. If an extension is flagged critical and a certificate-using
system does not recognize the extension field type or does not implement the
semantics of the extension, then that system shall consider the certificate
invalid. If an extension is flagged non-critical, a certificate-using system
that does not recognize or implement that extension type may process the
remainder of the certificate ignoring the extension. Extension type
definitions in this Directory Specification indicate if the extension is
always critical, always non-critical, or if criticality can be decided by
the certificate or CRL issuer. The reason for requiring some extensions to
be always non-critical is to allow certificate-using implementations which
do not need to use such extensions to omit support for them without
jeopardizing the ability to interoperate with all certification authorities"

I believe the point is well defined in the last sentence: namely "The reason
for requiring some extensions to be always non-critical is to allow
certificate-using implementations which do not need to use such extensions
to omit support for them without jeopardizing the ability to interoperate
with all certification authorities"

The use of  non-critical extension allows both, the support for critical
breaks the infrastructure.

It is this lack of interoperability that is the concern.

: and NOT require the duplication of effort
:with a full crl.
The CRL is always there, so there should not be a duplication of effort; my
understanding of the proposal is to support key compromise issues and speed
of CRL probagation?

:However, there may be other reasons a CA chooses to set
:this critical, some may be policy related. I am merely saying that this
:should be allowed.

:
:If a certificate using system does not support this extension then it
:can't trust that certificate, as stated in X.509.
See above.
:
:If you issue certificates with the crlDistributionPoint extension
:non-critical then either you conform with X.509 and publish a full crl
:at the CA entry for use by certificate using systems that don't support
:the extension (in some cases that can be impossible  given its potential
:size) or you don't confom with X.509 and don't publish the full CRL.. In
:the first case you have totally defeated the purpose of distribution
:points and I don't think anyone would agree that it is a reasonable
:approach.
If you start with a design that makes CRL's not work then this is a self
fullfilling argument; I dont support this as an absolute
condition.

I will agree that you can design a system to achive this result, but this
can probally always be done.

I dont see in the standard or anywhere else a requiremnt that
CrlDistribution points are a replacement for CRL's as you propose
 otherwise it would have been defined as critical in the standard.).

: In the second case the certificate using system can't trust
:the certificate anyway so you have achieved nothing.
See above.
:
:snip..
:
:I hope this clarifies what I intended.

Yes, but not resolution of the issue at hand.

The extension should remain non-critical, for the reasons above.

:
:Sharon
:
:
:
:------------------
:Sharon Boeyen
:Entrust Technologies
:
:mailto:[email-masked]       Tel: (613) 247-3181
:http://www.entrust.com          Fax: (613) 247-3690
:         Orchestrating Enterprise Security
:
:
:>----------
:>From:  Charles Moore[SMTP:[email-masked]]
:>Sent:  November 28, 1997 4:09 PM
:>To:    [email-masked]
:>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
:>
:><<File: smime.p7s>>
:>
:>-----Original Message-----
:>From: Tim Polk <[email-masked]>
:>To: [email-masked] <[email-masked]>
:>Date: Saturday, 29 November 1997 5:33
:>Subject: Re: [IETF-PKIX] Comment on PKIX-1
:>
:>
:>:Sharon,
:>:
:>My understanding of the proposal is to force all client processing systems
:>to handle
:>distribution point processing ( if they dont then the certificates are not
:>usable ) purely to support key or CA compromise
:>probagation.
:>
:>I would disagree that the proposal is scalable as it requires special
:>processing in all end systems in case someone uses this extension. The
:>result is more likely to be a loss of interoperability for the existing
:>systems or those that wish to handle
:>key compromise or other issues via say OCSP.
:>
:>I believe the text should stay as is, and disagree in making the CRL
:>distribution
:>point extension critical, as it will not help either interoperability or
:>address the issue of probagation of compromise
:>within a hetrogenious client envionment.
:>
:>
:>:I would agree that scalability *demands* the ability to split CRLs with
:>:the distribution point mechanism.  The original rationale for
:>:non-critical status for distribution points was something like
:>:>>>>
:>:> If the CA only issues CRLs through distribution points and the client
:>:> does not implement distribution points, it will not find a CRL and
:>:> will reject the path.  This is the same result as encountering an
:>:> unrecognized critical extension, so there is no reason to make it
:>:> critical.
:>:<<<<
:>:
:>:This is contradicted by the X.509 requirement for full CRLs unless the
:>:distribution point is critical.  So, I would say you are correct;
:>:optionally critical is the better choice.  I would propose to insert two
:>:paragraphs from X.509 into the profile....
:>:>>>>
:>:> This extension may, at the option of the certificate issuer, be either
:>:> critical or non-critical. In the interests of interoperability, it is
:>:> recommended that it be flagged non-critical. If the CRL distribution
:>:> point extension is made critical, the CA shall ensure that the
:>:> distribution points cover reason codes keyCompromise and/or
:>:> cACompromise whichever is applicable.
:>:>
:>:> If this extension is flagged critical then a certificate-using system
:>:> shall not use the certificate without first retrieving and checking a
:>:> CRL from one of the nominated distribution points covering, at a
:>:> minimum, the reason code keyCompromise (for an end-entity certificate)
:>:> or cACompromise (for a CA-certificate).
:>:>
:>:<<<<
:>:
:>:I believe the change would be appropriate.  Any other opinions?
:>:
:>:Tim Polk
:>:
:>:At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
:>:>In a final runthrough of the PKIX-1 text I noticed what I believe to be
:>:
:>:>an overlooked error.
:>:>
:>:>For crlDistributionPoints PKIX-1 currently mandates that this extension
:>:
:>:>be non-critical. Surely it needs to allow that this be optionally made
:>:>critical.
:>:>
:>:>If they are non-critical, then in order to conform to X.509, a CA MUST
:>:>also publish a full CRL at the CA entry, in addition to the individual
:>:>distribution points CRLs.
:>:>
:>:>It is ONLY when all certs issued by a CA have the CRL Distribution
:>:>Points extension CRITICAL, that duplication of the crl info at the CA
:>:>entry as a single monstrous CRL is optional.
:>:>
:>:>This is, I believe, the ONLY scaleable way to issue revocation lists
:>:>today and PKIX-1 should not mandate that it be disallowed.
:>:>
:>:>Sorry for this coming in so late, but I only caught it in my final
:>:>reading.
:>:>
:>:>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
:>:>you separately.
:>:>
:>:>Sharon
:>:>
:>:>
:>:>------------------
:>:>Sharon Boeyen
:>:>Entrust Technologies
:>:>
:>:>mailto:[email-masked]       Tel: (613) 247-3181
:>:>http://www.entrust.com          Fax: (613) 247-3690
:>:>         Orchestrating Enterprise Security
:>:>
:>:>
:>:>Attachment Converted: "c:\program
:>:files\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
:>:>
:>:>Attachment Converted: "c:\program
:>:files\eudora\attach\%-1%Body_Txt.txt.ent.ent"
:>:>
:>
:>

Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 6 (????/----) (0001D359)

Date:         Fri, 28 Nov 1997 15:30:39 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Neil Correa <[email-masked]>
Subject:      Re: [IETF-PKIX] Returned mail: User unknown
To: [email-masked]
Status:

Please remove the following from your list.

At 03:05 PM 11/28/97 -0800, you wrote:
>The original message was received at Fri, 28 Nov 1997 15:05:23 -0800
>from smap@localhost
>
>   ----- The following addresses had delivery problems -----
><[email-masked]>  (unrecoverable error)
><[email-masked]>  (unrecoverable error)
>
>   ----- Transcript of session follows -----
>... while talking to defender.cylink.com.:
>>>> RCPT To:<[email-masked]>
><<< 550 <[email-masked]>... User unknown
>550 <[email-masked]>... User unknown
>>>> RCPT To:<[email-masked]>
><<< 550 <[email-masked]>... User unknown
>550 <[email-masked]>... User unknown
>
>   ----- Message header follows -----
>Return-Path: <[email-masked]>
>Received: by  cylink.com (SMI-8.6/SMI-SVR4)
>       id PAA29024; Fri, 28 Nov 1997 15:05:23 -0800
>Received: from talia-100.mis.tandem.com(130.252.226.155) by
enforcer.cylink.com via smap (V2.0)
>       id xma029022; Fri, 28 Nov 97 15:05:11 -0800
>Received: from suntan (suntan.tandem.com [192.216.221.8])
>       by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA14721;
>       Fri, 28 Nov 1997 14:21:08 -0800 (PST)
>Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release
>          1.8c) with spool id 1474 for [email-masked]; Fri, 28
Nov
>          1997 14:21:01 -0800
>Received: from gatekeeper.entrust.com (gatekeeper.entrust.com
>          [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id
OAA27180
>          for <[email-masked]>; Fri, 28 Nov 1997 14:10:59 -0800
>          (PST)
>Received: tid RAA05569; Fri, 28 Nov 1997 17:07:11 -0500
>Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet
>          Mail Connector Version 4.0.995.52) id
>          <[email-masked]>; Fri, 28 Nov 1997 17:04:07
-0500
>X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version
4.0.995.52
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>Message-ID:
<c=CA%a=_%p=NorTel_Secure_Ne%l=[email-masked]>
>Date:         Fri, 28 Nov 1997 17:04:05 -0500
>Reply-To: "IETF X.509-based public key infrastructure mailing list"
>              <[email-masked]>
>Sender: "IETF X.509-based public key infrastructure mailing list"
>              <[email-masked]>
>From: Sharon Boeyen <[email-masked]>
>Subject:      Re: [IETF-PKIX] Comment on PKIX-1
>To: [email-masked]
>content-length: 7555
>
>   ----- Message body suppressed -----
>
>

Date:         Fri, 28 Nov 1997 17:04:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

Charles,

The use of  distribution points is not tied necessarily to any reason
codes. The main purpose of distribution points is to allow the CA to
publish its revocation list in "chunks" in a set of directory entries
rather than as a single monolithic attribute value at the CA entry
(which I believe everyone agrees is NOT scalable).

Let's also separate the functionality and requirements of a CA from
those of the certificate processing software. CA's are (and should be)
free to determine their own means for dealing with the revocation of
certificates. Some may choose (if they are in very small domains) to use
a single monolithic revocation list and publish this at the CA entry,
others may choose to use distribution points, others may choose to use
OCSP, or other protocols and some may choose a combination of these
approaches. What I am proposing is that a CA be ALLOWED to choose the
distribution point option and be ALLOWED to make that extension
critical. One reason to allow that option is that it is the only way to
remain conformant with X.509 and NOT require the duplication of effort
with a full crl. However, there may be other reasons a CA chooses to set
this critical, some may be policy related. I am merely saying that this
should be allowed.

If a certificate using system does not support this extension then it
can't trust that certificate, as stated in X.509.

If you issue certificates with the crlDistributionPoint extension
non-critical then either you conform with X.509 and publish a full crl
at the CA entry for use by certificate using systems that don't support
the extension (in some cases that can be impossible  given its potential
size) or you don't confom with X.509 and don't publish the full CRL.. In
the first case you have totally defeated the purpose of distribution
points and I don't think anyone would agree that it is a reasonable
approach. In the second case the certificate using system can't trust
the certificate anyway so you have achieved nothing.

Also this has nothing to do with environments which will want to use
OCSP and in fact I suspect that we will some  CAs offer both CRL based
revocation as well as online status checking. Although I haven't had a
chance to review the latest OCSP draft all previous drafts and I suspect
the current one, talked about this same situation. I am in no way
suggesting that is not also an option which CAs should have.

As for existing systems there are many today which use CRL Distribution
Points and not just for key compromise situations. They are definitely
scalable in that you may set up as many as you need to satisfy the user
community in which you are working. They need not be differentiated by
reason code at all and can be a very easy way to simply split what might
be a rediculously large CRL into smaller chunks (e.g. one for every x
number of certificates issued by a CA, covering all revocation reasons)
which can be placed in reasonably sized directory entries and downloaded
with much less overhead.

I hope this clarifies what I intended.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  November 28, 1997 4:09 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comment on PKIX-1
>
><<File: smime.p7s>>
>
>-----Original Message-----
>From: Tim Polk <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Saturday, 29 November 1997 5:33
>Subject: Re: [IETF-PKIX] Comment on PKIX-1
>
>
>:Sharon,
>:
>My understanding of the proposal is to force all client processing systems
>to handle
>distribution point processing ( if they dont then the certificates are not
>usable ) purely to support key or CA compromise
>probagation.
>
>I would disagree that the proposal is scalable as it requires special
>processing in all end systems in case someone uses this extension. The
>result is more likely to be a loss of interoperability for the existing
>systems or those that wish to handle
>key compromise or other issues via say OCSP.
>
>I believe the text should stay as is, and disagree in making the CRL
>distribution
>point extension critical, as it will not help either interoperability or
>address the issue of probagation of compromise
>within a hetrogenious client envionment.
>
>
>:I would agree that scalability *demands* the ability to split CRLs with
>:the distribution point mechanism.  The original rationale for
>:non-critical status for distribution points was something like
>:>>>>
>:> If the CA only issues CRLs through distribution points and the client
>:> does not implement distribution points, it will not find a CRL and
>:> will reject the path.  This is the same result as encountering an
>:> unrecognized critical extension, so there is no reason to make it
>:> critical.
>:<<<<
>:
>:This is contradicted by the X.509 requirement for full CRLs unless the
>:distribution point is critical.  So, I would say you are correct;
>:optionally critical is the better choice.  I would propose to insert two
>:paragraphs from X.509 into the profile....
>:>>>>
>:> This extension may, at the option of the certificate issuer, be either
>:> critical or non-critical. In the interests of interoperability, it is
>:> recommended that it be flagged non-critical. If the CRL distribution
>:> point extension is made critical, the CA shall ensure that the
>:> distribution points cover reason codes keyCompromise and/or
>:> cACompromise whichever is applicable.
>:>
>:> If this extension is flagged critical then a certificate-using system
>:> shall not use the certificate without first retrieving and checking a
>:> CRL from one of the nominated distribution points covering, at a
>:> minimum, the reason code keyCompromise (for an end-entity certificate)
>:> or cACompromise (for a CA-certificate).
>:>
>:<<<<
>:
>:I believe the change would be appropriate.  Any other opinions?
>:
>:Tim Polk
>:
>:At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>:>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>:
>:>an overlooked error.
>:>
>:>For crlDistributionPoints PKIX-1 currently mandates that this extension
>:
>:>be non-critical. Surely it needs to allow that this be optionally made
>:>critical.
>:>
>:>If they are non-critical, then in order to conform to X.509, a CA MUST
>:>also publish a full CRL at the CA entry, in addition to the individual
>:>distribution points CRLs.
>:>
>:>It is ONLY when all certs issued by a CA have the CRL Distribution
>:>Points extension CRITICAL, that duplication of the crl info at the CA
>:>entry as a single monstrous CRL is optional.
>:>
>:>This is, I believe, the ONLY scaleable way to issue revocation lists
>:>today and PKIX-1 should not mandate that it be disallowed.
>:>
>:>Sorry for this coming in so late, but I only caught it in my final
>:>reading.
>:>
>:>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>:>you separately.
>:>
>:>Sharon
>:>
>:>
>:>------------------
>:>Sharon Boeyen
>:>Entrust Technologies
>:>
>:>mailto:[email-masked]       Tel: (613) 247-3181
>:>http://www.entrust.com          Fax: (613) 247-3690
>:>         Orchestrating Enterprise Security
>:>
>:>
>:>Attachment Converted: "c:\program
>:files\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>:>
>:>Attachment Converted: "c:\program
>:files\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>:>
>
>

Date:         Fri, 28 Nov 1997 16:25:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject:      [IETF-PKIX] ECDSDA Profile
To: [email-masked]
Status:

Somehow or another, the ECDSA for PKIX draft was submitted but has not
appeared on the ietf web site.  I'll resubmit during the meeting, but it is
available now at http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-ecdsa-01.txt

Thanks,

Tim Polk

Date:         Sat, 29 Nov 1997 07:09:58 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
To: [email-masked]
Status:

-----Original Message-----
From: Tim Polk <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Saturday, 29 November 1997 5:33
Subject: Re: [IETF-PKIX] Comment on PKIX-1

:Sharon,
:
My understanding of the proposal is to force all client processing systems
to handle
distribution point processing ( if they dont then the certificates are not
usable ) purely to support key or CA compromise
probagation.

I would disagree that the proposal is scalable as it requires special
processing in all end systems in case someone uses this extension. The
result is more likely to be a loss of interoperability for the existing
systems or those that wish to handle
key compromise or other issues via say OCSP.

I believe the text should stay as is, and disagree in making the CRL
distribution
point extension critical, as it will not help either interoperability or
address the issue of probagation of compromise
within a hetrogenious client envionment.

:I would agree that scalability *demands* the ability to split CRLs with
:the distribution point mechanism.  The original rationale for
:non-critical status for distribution points was something like
:>>>>
:> If the CA only issues CRLs through distribution points and the client
:> does not implement distribution points, it will not find a CRL and
:> will reject the path.  This is the same result as encountering an
:> unrecognized critical extension, so there is no reason to make it
:> critical.
:<<<<
:
:This is contradicted by the X.509 requirement for full CRLs unless the
:distribution point is critical.  So, I would say you are correct;
:optionally critical is the better choice.  I would propose to insert two
:paragraphs from X.509 into the profile....
:>>>>
:> This extension may, at the option of the certificate issuer, be either
:> critical or non-critical. In the interests of interoperability, it is
:> recommended that it be flagged non-critical. If the CRL distribution
:> point extension is made critical, the CA shall ensure that the
:> distribution points cover reason codes keyCompromise and/or
:> cACompromise whichever is applicable.
:>
:> If this extension is flagged critical then a certificate-using system
:> shall not use the certificate without first retrieving and checking a
:> CRL from one of the nominated distribution points covering, at a
:> minimum, the reason code keyCompromise (for an end-entity certificate)
:> or cACompromise (for a CA-certificate).
:>
:<<<<
:
:I believe the change would be appropriate.  Any other opinions?
:
:Tim Polk
:
:At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
:>In a final runthrough of the PKIX-1 text I noticed what I believe to be
:
:>an overlooked error.
:>
:>For crlDistributionPoints PKIX-1 currently mandates that this extension
:
:>be non-critical. Surely it needs to allow that this be optionally made
:>critical.
:>
:>If they are non-critical, then in order to conform to X.509, a CA MUST
:>also publish a full CRL at the CA entry, in addition to the individual
:>distribution points CRLs.
:>
:>It is ONLY when all certs issued by a CA have the CRL Distribution
:>Points extension CRITICAL, that duplication of the crl info at the CA
:>entry as a single monstrous CRL is optional.
:>
:>This is, I believe, the ONLY scaleable way to issue revocation lists
:>today and PKIX-1 should not mandate that it be disallowed.
:>
:>Sorry for this coming in so late, but I only caught it in my final
:>reading.
:>
:>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
:>you separately.
:>
:>Sharon
:>
:>
:>------------------
:>Sharon Boeyen
:>Entrust Technologies
:>
:>mailto:[email-masked]       Tel: (613) 247-3181
:>http://www.entrust.com          Fax: (613) 247-3690
:>         Orchestrating Enterprise Security
:>
:>
:>Attachment Converted: "c:\program
:files\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
:>
:>Attachment Converted: "c:\program
:files\eudora\attach\%-1%Body_Txt.txt.ent.ent"
:>

Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 5 (????/----) (0001D358)

Date:         Fri, 28 Nov 1997 14:19:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on PKIX-1
Comments: To: Sharon Boeyen <[email-masked]>
To: [email-masked]
Status:

<x-rich>Sharon,

I would agree that scalability *demands* the ability to split CRLs with
the distribution point mechanism.  The original rationale for
non-critical status for distribution points was something like

>>>>

<excerpt>If the CA only issues CRLs through distribution points and the
client does not implement distribution points, it will not find a CRL and
will reject the path.  This is the same result as encountering an
unrecognized critical extension, so there is no reason to make it
critical.

</excerpt><<<<<<<<

This is contradicted by the X.509 requirement for full CRLs unless the
distribution point is critical.  So, I would say you are correct;
optionally critical is the better choice.  I would propose to insert two
paragraphs from X.509 into the profile....

>>>>

<excerpt>This extension may, at the option of the certificate issuer, be
either critical or non-critical. In the interests of interoperability, it
is recommended that it be flagged non-critical. If the CRL distribution
point extension is made critical, the CA shall ensure that the
distribution points cover reason codes keyCompromise and/or cACompromise
whichever is applicable.

If this extension is flagged critical then a certificate-using system
shall not use the certificate without first retrieving and checking a CRL
from one of the nominated distribution points covering, at a minimum, the
reason code keyCompromise (for an end-entity certificate) or cACompromise
(for a CA-certificate).

</excerpt><<<<<<<<

I believe the change would be appropriate.  Any other opinions?

Tim Polk

At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:

>In a final runthrough of the PKIX-1 text I noticed what I believe to
be

>an overlooked error.

>

>For crlDistributionPoints PKIX-1 currently mandates that this
extension

>be non-critical. Surely it needs to allow that this be optionally made

>critical.

>

>If they are non-critical, then in order to conform to X.509, a CA MUST

>also publish a full CRL at the CA entry, in addition to the individual

>distribution points CRLs.

>

>It is ONLY when all certs issued by a CA have the CRL Distribution

>Points extension CRITICAL, that duplication of the crl info at the CA

>entry as a single monstrous CRL is optional.

>

>This is, I believe, the ONLY scaleable way to issue revocation lists

>today and PKIX-1 should not mandate that it be disallowed.

>

>Sorry for this coming in so late, but I only caught it in my final

>reading.

>

>Tim, I noticed a few minor editorials (typos etc) that I'll forward to

>you separately.

>

>Sharon

>

>

>------------------

>Sharon Boeyen

>Entrust Technologies

>

>mailto:[email-masked]       Tel: (613) 247-3181

>http://www.entrust.com          Fax: (613) 247-3690

>         Orchestrating Enterprise Security

>

>

>Attachment Converted: "c:\program
files\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"

>

>Attachment Converted: "c:\program
files\eudora\attach\%-1%Body_Txt.txt.ent.ent"

>
</x-rich>

Date:         Fri, 28 Nov 1997 11:37:05 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] ASN1 question on PKIX part 1
To: [email-masked]
Status:

Dean Povey wrote:
>
> >This is an extract of draft-ietf-pkix-ipki-part1-06.txt
> >from ASN.1 compilable Appendix A
> >
> > DirectoryString ::= CHOICE {
> >           teletexString           TeletexString (SIZE (1..maxSize)),
> >           printableString         PrintableString (SIZE (1..maxSize)),
> >           universalString         UniversalString (SIZE (1..maxSize)),
> >         bmpString               BMPString (SIZE(1..maxSIZE))
> >                               }
> >
> >a) Where should maxSize be defined ?
> >b) What is maxSize value           ?
> >c) Is maxSIZE the same as maxSize  ?
> >
>
> This should actually be 1..MAX.  MAX is an implementation specific limit :-).
> It is the 1 that is important.  This mean that the string cannot be empty.
>
> Dean.
> --
> +----------------------------------------+-------------------------------+
> | Dean Povey,                            |  Email: [email-masked]     |
> | Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       |
> | CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
> +----------------------------------------+-------------------------------+

Yes, MAX is just about as good as can be done with this degraded
version of the original DirectoryString{} ASN.1:1994 parameterized
type. The error above comes from the removal of the productions,
govenor and parameter from the original definition:

   DirectoryString { INTEGER : maxSize } ::= CHOICE {
      teletexString    TeletexString (SIZE (1..maxSize)),
      printableString  PrintableString (SIZE (1..maxSize)),
      universalString  UniversalString (SIZE (1..maxSize)),
      bmpString        BMPString (SIZE (1..maxSize))
   }

This definition is capable of more accurately specifying attributes
in X.520 (where it is defined) than the degraded X.208 version described
above...

   X ::= DirectoryString { 12 }

   Y ::= DirectoryString { 64 }

allowing expected string lengths to be fixed in a protocol at various
reasonable extents. The PKIX X.208 version is crude in contrast, and not
capable of such accuracy. The PKIX version requires that implementors
expect worst case, the machine maximum length for all types defined
with DirectoryString.

This surely does not help to make implementations efficient, but it does
result in a simplicity of sorts, one that comes from the elimination of
specificity in the protocol, and the need for much thinking. Clearly,
the
PKIX X.208 version of DirectoryString is inferior to the X.520
ASN.1:1994
version.

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date:         Fri, 28 Nov 1997 12:49:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Ignore attachments
To: [email-masked]
Status:

Pls ignore the attachments on my earlier message.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

Date:         Fri, 28 Nov 1997 11:25:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Comment on PKIX-1
Comments: cc: Tim Polk <[email-masked]>
To: [email-masked]
Status:

In a final runthrough of the PKIX-1 text I noticed what I believe to be
an overlooked error.

For crlDistributionPoints PKIX-1 currently mandates that this extension
be non-critical. Surely it needs to allow that this be optionally made
critical.

If they are non-critical, then in order to conform to X.509, a CA MUST
also publish a full CRL at the CA entry, in addition to the individual
distribution points CRLs.

It is ONLY when all certs issued by a CA have the CRL Distribution
Points extension CRITICAL, that duplication of the crl info at the CA
entry as a single monstrous CRL is optional.

This is, I believe, the ONLY scaleable way to issue revocation lists
today and PKIX-1 should not mandate that it be disallowed.

Sorry for this coming in so late, but I only caught it in my final
reading.

Tim, I noticed a few minor editorials (typos etc) that I'll forward to
you separately.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

Content-Type: application/octet-stream; name="%-1%Body_Rtf.rtf.ent.ent"

Attachment converted: Lutefisk:%-1%Body_Rtf.rtf.ent.ent (????/----) (0001D356)
Content-Type: application/octet-stream; name="%-1%Body_Txt.txt.ent.ent"

Attachment converted: Lutefisk:%-1%Body_Txt.txt.ent.ent (????/----) (0001D357)

Date:         Fri, 28 Nov 1997 09:52:21 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dean Povey <[email-masked]>
Subject:      Re: [IETF-PKIX] ASN1 question on PKIX part 1
To: [email-masked]
Status:

>This is an extract of draft-ietf-pkix-ipki-part1-06.txt
>from ASN.1 compilable Appendix A
>
> DirectoryString ::= CHOICE {
>           teletexString           TeletexString (SIZE (1..maxSize)),
>           printableString         PrintableString (SIZE (1..maxSize)),
>           universalString         UniversalString (SIZE (1..maxSize)),
>         bmpString               BMPString (SIZE(1..maxSIZE))
>                               }
>
>a) Where should maxSize be defined ?
>b) What is maxSize value           ?
>c) Is maxSIZE the same as maxSize  ?
>

This should actually be 1..MAX.  MAX is an implementation specific limit :-).
It is the 1 that is important.  This mean that the string cannot be empty.

Dean.
--
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       |
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

Date:         Thu, 27 Nov 1997 16:55:02 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Anette Byskov <[email-masked]>
Organization: Cryptomathic
Subject:      [IETF-PKIX] DER Encoding of Key Usage Extension?
To: [email-masked]
Status:

A short question: how to encode the key usage extension with, let's say,
bit 0, 1, and 3 set. Is it

      03 02 04 D0  (BIT STRING with value '1101')
or
      03 02 04 B0  (BIT STRING with value '1011')

I know this sort of question has been asked before on this list but in
that example bit 0 and 4  were set (which is encoded 03 02 03 88 in both
cases).

Thanks,
Anette
------------------------------------------------------------
Anette Byskov                          Cryptomathic A/S
Tel:    +45 86 13 90 20                Klostergade 28
Direct: +45 86 13 90 21 - 113          DK-8000 Aarhus C
Fax:    +45 86 20 29 75                Denmark
Web:    http://www.cryptomathic.dk/
                           - new dimensions in data security
------------------------------------------------------------

Date:         Wed, 26 Nov 1997 13:46:24 -0800
Reply-To: "[email-masked]" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Wolfe <[email-masked]>
Organization: Maithean
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

----------
From:   Info Desk[SMTP:[email-masked]]
Sent:   Tuesday, November 25, 1997 4:19 PM
To:     [email-masked]
Subject:        [IETF-PKIX] Advertisement: Website
Hosting

----------------------------------------------
-------------------------------
If you wish to be excluded from any future
mailings,
reply with "remove" in the subject header.
----------------------------------------------
-------------------------------

http://www.infowatch.net

InfoWatch would like to introduce our complete
Hosting and Promotional
service.

        FOR ONLY $29.95 PER MONTH !

* 30 MB (megabytes) of disk space
* 1000 MB = 1 GB (gigabyte) of data transfer per
month
* 8 E-mail accounts
* INTERNATIONAL Hosting
* Access to your account anytime via the Web
Control Panel
* Full MS Front Page support
* Unlimited FTP updates
* Personal CGI directory for your own scripts (or
use ours)
* Comprehensive statistics program shows you
everything
* E-mail forwarding, auto responders and vacation
reply
* Domain name registration (www.yourname.com)
* Register your domain with over 250 search
engines-FREE
* Friendly customer support

* Inquire about our $24.95 plan

If for any reason you are not satisfied with
InfoWatch's service after 30
days, we will transfer you back to your original
host and pay any transfer fees.

http://www.infowatch.net
[email-masked]

Date:         Wed, 26 Nov 1997 13:38:36 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rick Heiden <[email-masked]>
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

     Remove

______________________________ Reply Separator _________________________________
Subject: [IETF-PKIX] Advertisement: Website Hosting
Author:  <[email-masked]> at SMTPGWY
Date:    11/25/97 7:19 PM

-----------------------------------------------------------------------------
If you wish to be excluded from any future mailings,
reply with "remove" in the subject header.
-----------------------------------------------------------------------------

http://www.infowatch.net

InfoWatch would like to introduce our complete Hosting and Promotional
service.

        FOR ONLY $29.95 PER MONTH !

* 30 MB (megabytes) of disk space
* 1000 MB = 1 GB (gigabyte) of data transfer per month
* 8 E-mail accounts
* INTERNATIONAL Hosting
* Access to your account anytime via the Web Control Panel
* Full MS Front Page support
* Unlimited FTP updates
* Personal CGI directory for your own scripts (or use ours)
* Comprehensive statistics program shows you everything
* E-mail forwarding, auto responders and vacation reply
* Domain name registration (www.yourname.com)
* Register your domain with over 250 search engines-FREE
* Friendly customer support

* Inquire about our $24.95 plan

If for any reason you are not satisfied with InfoWatch's service after 30
days, we will transfer you back to your original host and pay any transfer fees.

http://www.infowatch.net
[email-masked]

Date:         Wed, 26 Nov 1997 13:37:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rick Heiden <[email-masked]>
Subject:      Re: [IETF-PKIX] remove
To: [email-masked]
Status:

     Sorry, I can't remove you from the list!

______________________________ Reply Separator _________________________________
Subject: [IETF-PKIX] remove
Author:  <[email-masked]> at SMTPGWY
Date:    11/26/97 5:15 PM

remove

Date:         Wed, 26 Nov 1997 11:47:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Steve Lusk <[email-masked]>
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

-----Original Message-----
From: Info Desk <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, November 26, 1997 11:09 AM
Subject: [IETF-PKIX] Advertisement: Website Hosting

>---------------------------------------------------------------------------
--
>If you wish to be excluded from any future mailings,
>reply with "remove" in the subject header.
>---------------------------------------------------------------------------
--
>
>http://www.infowatch.net
>
>InfoWatch would like to introduce our complete Hosting and Promotional
>service.
>
>        FOR ONLY $29.95 PER MONTH !
>
>* 30 MB (megabytes) of disk space
>* 1000 MB = 1 GB (gigabyte) of data transfer per month
>* 8 E-mail accounts
>* INTERNATIONAL Hosting
>* Access to your account anytime via the Web Control Panel
>* Full MS Front Page support
>* Unlimited FTP updates
>* Personal CGI directory for your own scripts (or use ours)
>* Comprehensive statistics program shows you everything
>* E-mail forwarding, auto responders and vacation reply
>* Domain name registration (www.yourname.com)
>* Register your domain with over 250 search engines-FREE
>* Friendly customer support
>
>* Inquire about our $24.95 plan
>
>If for any reason you are not satisfied with InfoWatch's service after 30
>days, we will transfer you back to your original host and pay any transfer
fees.
>
>http://www.infowatch.net
>[email-masked]
>

Date:         Wed, 26 Nov 1997 12:04:21 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

Let me get one thing straight:  I am avidly against recommending any
changes to X.509.  It's taken too long to get where it is, and I am
against further inhibiting it.

I am all for profiling the key usages and clarifying their use for the
community in question.  We have a tool, keyUsages.  It's up to us to
figure out how to best use it.

Dave Simonetti

Hal Lockhart wrote:
>
> At 05:14 PM 11/25/97 -0700, Bob Jueneman wrote:
>
> >I'd like to think that those who have ventured an opinion in this area are
> >reasonably knowledgable about the subject.
> >
> >But if we cannot agree as what these bits mean, it is not likely that either
> >CAs or client software will understand or correctly implement the semantics,
> >no matter what the bottom line is.
> >
> >Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
> >they seem to be doing more harm than good.
> >
> >Can someone make a case for why we should bother with them, if there is this
> >much confusion about their meaning?
>
> The usual reason given is that in some security domains, there is a desire
> to use certain keys only for certain purposes.  In these domains, the CA
> wishes to enforce these policies by marking the certs as to the allowable
> usage(s). A couple of examples:
>
> A) I may have a (relatively) short key that I use in my smart card to login
> to online services.  My smart card processor is slow, so I need to use a
> short key to keep the time reasonable. On the other hand, I have a very
> long key I use for signing contracts that may be in force for 30 years or
> more.
>
> B) My organization wishes to be able to recover data that has been
> encrypted in an emergency.  For this reason, keys used for encrypting data
> are duplicated in some offline storage.  However, it is both unnecessary
> and undesirable to copy keys used for signatures.  Therefore the certs
> indicate the allowed uses.
>
> I think this discussion has confused two problems.  If we separate them, we
> may be able to make some progress.
>
> 1) Assuming you accept the need to identify the permitted uses of a key,
> there needs to be some list of possible uses.  As David Kemp has explained
> previously, the ones that have to do with signing things currently are:
>
> f) sign a cert
> g) sign a CRL
> b) sign user data
> a) sign something else (usually means sign ephemeral data as part of an
> authentication protocol)
>
> So the first issue is: are these the right categories?  My sense is that
> most people on the list think they are.  Since we are profiling X.509, I
> believe our only choices are a) accept the categories or b) leave out key
> usage entirely.
>
> 2) What should we call the categories?  Here there is general agreement
> that the choice of nonrepudiation for (b) and digital signature for (a) is
> confusing.  Many people look at these terms and apply all kinds of
> additional semantics to them.
>
> I am not sure what the rules allow, but David's message (and others)
> suggest that we can choose new terms that will not produce confusion.  I
> heard suggestions like "sign data" for (b) and either "authentication" or
> "other" for (a).  If this is allowed, let's agree on new, less confusing
> terms and stop debating whether the use of the "nonrepudiation" bit implies
> something about the CA's insurance coverage. ;-)
>
> Hal
>
> =================================================================
> Harold W. Lockhart Jr.            Platinum Solutions Inc.
> Chief Technical Architect         8 New England Executive Park
> Email: [email-masked]            Burlington, MA 01803 USA
> Voice: (781)273-6406              Fax: (781)229-2969
> =================================================================

Date:         Wed, 26 Nov 1997 13:08:26 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Joe Wood <[email-masked]>
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

At 07:19 PM 11/25/97 -0500, you wrote:
>-----------------------------------------------------------------------------
>If you wish to be excluded from any future mailings,
>reply with "remove" in the subject header.
>-----------------------------------------------------------------------------
>
>http://www.infowatch.net
>
>InfoWatch would like to introduce our complete Hosting and Promotional
>service.
>
>        FOR ONLY $29.95 PER MONTH !
>
>* 30 MB (megabytes) of disk space
>* 1000 MB = 1 GB (gigabyte) of data transfer per month
>* 8 E-mail accounts
>* INTERNATIONAL Hosting
>* Access to your account anytime via the Web Control Panel
>* Full MS Front Page support
>* Unlimited FTP updates
>* Personal CGI directory for your own scripts (or use ours)
>* Comprehensive statistics program shows you everything
>* E-mail forwarding, auto responders and vacation reply
>* Domain name registration (www.yourname.com)
>* Register your domain with over 250 search engines-FREE
>* Friendly customer support
>
>* Inquire about our $24.95 plan
>
>If for any reason you are not satisfied with InfoWatch's service after 30
>days, we will transfer you back to your original host and pay any transfer
fees.
>
>http://www.infowatch.net
>[email-masked]
>

Date:         Wed, 26 Nov 1997 17:15:55 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jesper Drud Nielsen <[email-masked]>
Organization: Cryptomathic A/S
Subject:      [IETF-PKIX] remove
To: [email-masked]
Status:

remove
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 1 (????/----) (0001D351)

Date:         Wed, 26 Nov 1997 10:28:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

At 05:14 PM 11/25/97 -0700, Bob Jueneman wrote:

>I'd like to think that those who have ventured an opinion in this area are
>reasonably knowledgable about the subject.
>
>But if we cannot agree as what these bits mean, it is not likely that either
>CAs or client software will understand or correctly implement the semantics,
>no matter what the bottom line is.
>
>Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>they seem to be doing more harm than good.
>
>Can someone make a case for why we should bother with them, if there is this
>much confusion about their meaning?

The usual reason given is that in some security domains, there is a desire
to use certain keys only for certain purposes.  In these domains, the CA
wishes to enforce these policies by marking the certs as to the allowable
usage(s). A couple of examples:

A) I may have a (relatively) short key that I use in my smart card to login
to online services.  My smart card processor is slow, so I need to use a
short key to keep the time reasonable. On the other hand, I have a very
long key I use for signing contracts that may be in force for 30 years or
more.

B) My organization wishes to be able to recover data that has been
encrypted in an emergency.  For this reason, keys used for encrypting data
are duplicated in some offline storage.  However, it is both unnecessary
and undesirable to copy keys used for signatures.  Therefore the certs
indicate the allowed uses.

I think this discussion has confused two problems.  If we separate them, we
may be able to make some progress.

1) Assuming you accept the need to identify the permitted uses of a key,
there needs to be some list of possible uses.  As David Kemp has explained
previously, the ones that have to do with signing things currently are:

f) sign a cert
g) sign a CRL
b) sign user data
a) sign something else (usually means sign ephemeral data as part of an
authentication protocol)

So the first issue is: are these the right categories?  My sense is that
most people on the list think they are.  Since we are profiling X.509, I
believe our only choices are a) accept the categories or b) leave out key
usage entirely.

2) What should we call the categories?  Here there is general agreement
that the choice of nonrepudiation for (b) and digital signature for (a) is
confusing.  Many people look at these terms and apply all kinds of
additional semantics to them.

I am not sure what the rules allow, but David's message (and others)
suggest that we can choose new terms that will not produce confusion.  I
heard suggestions like "sign data" for (b) and either "authentication" or
"other" for (a).  If this is allowed, let's agree on new, less confusing
terms and stop debating whether the use of the "nonrepudiation" bit implies
something about the CA's insurance coverage. ;-)

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 25 Nov 1997 19:19:21 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Info Desk <[email-masked]>
Subject:      [IETF-PKIX] Advertisement: Website Hosting
To: [email-masked]
Status:

-----------------------------------------------------------------------------
If you wish to be excluded from any future mailings,
reply with "remove" in the subject header.
-----------------------------------------------------------------------------

http://www.infowatch.net

InfoWatch would like to introduce our complete Hosting and Promotional
service.

        FOR ONLY $29.95 PER MONTH !

* 30 MB (megabytes) of disk space
* 1000 MB = 1 GB (gigabyte) of data transfer per month
* 8 E-mail accounts
* INTERNATIONAL Hosting
* Access to your account anytime via the Web Control Panel
* Full MS Front Page support
* Unlimited FTP updates
* Personal CGI directory for your own scripts (or use ours)
* Comprehensive statistics program shows you everything
* E-mail forwarding, auto responders and vacation reply
* Domain name registration (www.yourname.com)
* Register your domain with over 250 search engines-FREE
* Friendly customer support

* Inquire about our $24.95 plan

If for any reason you are not satisfied with InfoWatch's service after 30
days, we will transfer you back to your original host and pay any transfer fees.

http://www.infowatch.net
[email-masked]

Date:         Wed, 26 Nov 1997 10:54:27 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

I understand that notary and trusted-timesatmps will be discussed at the
upcoming meeting in Washington.

Russ

At 08:08 PM 11/26/97 +1100, Hamid Homayouni wrote:
>On Wednesday, November 26, 1997 1:25 AM, Russ Housley  wrote:
>> So, when you hand sign a guest register at a wedding, a credit card
>> receipt, and a mortgage, how do you distinguish which needs
>> non-repudiation?  You do not (except that you are forced to use black
>ink).
>>  If the transaction is really important, you get a notary involved, but
>> otherwise the same mechanism is used to provide different services.
>
>That's right, but also remember that there are various degrees of
>importance. I certainly would not get a notary involved in a credit card
>transaction, but I have to and WILL use my signature that is on the back of
>my mag stripe card. Although, I may choose not use that same signature for
>a guest register!
>
>Just out of curiosity, what's the equivalent of a notary in PKI if a CA
>with proper processes, and liability covers, etc is not considered one?
>
>-Hamid
>
>>
>> Russ
>>
>>
>> At 02:20 PM 11/25/97 +1100, Hamid Homayouni wrote:
>> >Similar to Bill, I've not been involved in the discussions that led to
>this
>> >proposal. So please bear with me.
>> >
>> >The technical mechanisms for both digital signature and non-repudiation
>are
>> >the same. The only thing that can enforce non-repudiation is proper
>> >legislation behind it.
>> >At the same time, as a user, I'd prefer to separate my key usage into
>> >"digital signature" for day-to-day I&A use, and "non-repudiation". ie. I
>> >really want to consciously sign something and not get it mixed up with
>my
>> >day-to-day activity of using my I&A keys. Similar to what I actually do
>> >with my normal hand signature. I've one (the short version) that I use
>> >within the office for memos, etc, and one that I use for financial
>> >transactions (ie, I'm consciously accepting a bigger responsibility).
>[...]
>
>> >> >>
>> >> >
>> >> >
>> >> Regards,
>> >>
>> >> Bill Burr
>>
>>
>

Date:         Wed, 26 Nov 1997 09:46:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

At 05:14 PM 11/25/97 -0700, Bob Jueneman wrote:

>I'd like to think that those who have ventured an opinion in this area are
>reasonably knowledgable about the subject.
>
>But if we cannot agree as what these bits mean, it is not likely that either
>CAs or client software will understand or correctly implement the semantics,
>no matter what the bottom line is.
>
I suppose that the authors of this part of the DAM had something specific
in mind, probably what Dave Kemp has stated. But my feeling is, as I have
said, that they tried to slice and dice things rather too finely, while
mixing apples and oranges, and this causes a lot of unnecessary confusion.
We have now 512 possible combinations, many of which don't make obvious
sense (e.g., dataEncipherment and decipherOnly both set).  What are the
obligations of certificate using systems when they process this field if
they encounter strange combinations?

>Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>they seem to be doing more harm than good.
>
It does seem to me that we need a way to distinguish key management keys
from digital signature keys.  And perhaps also a way to tell CA
keys/certificates from other keys/certificates.  It seems that
basicConstraints could take care of that though.

>Can someone make a case for why we should bother with them, if there is this
>much confusion about their meaning?

One reason we probably should bother is more political than technical.  It
may be useful for export or similar purposes to maintain the fiction that
this key/certificate can't be used for encryption because the because the
keyEncipherment, dataEncipherment, keyAgreement, encipherOnly and
decipherOnly bits are all not set.

The other one is that it does make sense to separate key
management/encryption keys from signature keys, and have separate
certificates for them, entirely aside from the various export/law
enforcement issues.  If so, we do need a way to say which cert. is for
which application.

Inventing another way to do this is perhaps too radical surgery at this point.

>
>Bob
>
>
Regards,

Bill Burr

Date:         Wed, 26 Nov 1997 15:59:13 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Luc Creti <[email-masked]>
Subject:      [IETF-PKIX] ASN1 question on PKIX part 1
To: [email-masked]
Status:

This is an extract of draft-ietf-pkix-ipki-part1-06.txt
from ASN.1 compilable Appendix A

 DirectoryString ::= CHOICE {
           teletexString           TeletexString (SIZE (1..maxSize)),
           printableString         PrintableString (SIZE (1..maxSize)),
           universalString         UniversalString (SIZE (1..maxSize)),
         bmpString               BMPString (SIZE(1..maxSIZE))
                               }

a) Where should maxSize be defined ?
b) What is maxSize value           ?
c) Is maxSIZE the same as maxSize  ?

Thanks for your help,
--
Luc Creti                            mailto:[email-masked]
BULL SA - ISM AccessMaster
Rue Jean Jaures - A5/145             Tel: +33 (0)1 30 80 63 83
F-78340 Les Clayes sous Bois         Fax: +33 (0)1 30 80 77 99

Date:         Wed, 26 Nov 1997 09:20:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob,

First let me say that I highly respect all of the opinions that I've
received.

The key usage flags do play a useful role.  As a single example, they
allow me to restrict use of my RSA key to either digital signature or
key encipherment, but never both.  There is enough importance in this
single role to warrant the extension be made "critical" when used.

If this thread has proved anything, it's at least shown that there is no
universal interpretation of non-repudiation or how to best implement
it.  I think we should leave it up to individual communities of users to
determine how to best implement this in their situation because there is
not one right answer.  Certificate policies are going to play a mighty
important role.

Dave Simonetti

Bob Jueneman wrote:
>
> >I, in turn, propose that digitalSignature is the mechanism.  If
> >nonRepudiation is turned on, then the non-repudiation service is
> >provided; if nonRepudiation is turned off, then non-repuditiation is not
> >provided.  Why can't it be this simple?
> >
> >Dave Simonetti
> >
> >
> I'd like to think that those who have ventured an opinion in this area are
> reasonably knowledgable about the subject.
>
> But if we cannot agree as what these bits mean, it is not likely that either
> CAs or client software will understand or correctly implement the semantics,
> no matter what the bottom line is.
>
> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
> they seem to be doing more harm than good.
>
> Can someone make a case for why we should bother with them, if there is this
> much confusion about their meaning?
>
> Bob
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Date:         Wed, 26 Nov 1997 08:01:45 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

The keyUsage extension can be critical or non-critical remember. When it
is non-critical it indicates the "intended" purpose(s) of the key and is
useful in finding the correct key/certificate. It's use should NOT be
deprecated, however I do find it a bit odd that PKIX-1 currently
recommends that when it is used it be critical. The non-critical use is
a very real and practical one.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  November 25, 1997 7:14 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
>
>>I, in turn, propose that digitalSignature is the mechanism.  If
>>nonRepudiation is turned on, then the non-repudiation service is
>>provided; if nonRepudiation is turned off, then non-repuditiation is not
>>provided.  Why can't it be this simple?
>>
>>Dave Simonetti
>>
>>
>I'd like to think that those who have ventured an opinion in this area are
>reasonably knowledgable about the subject.
>
>But if we cannot agree as what these bits mean, it is not likely that either
>CAs or client software will understand or correctly implement the semantics,
>no matter what the bottom line is.
>
>Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>they seem to be doing more harm than good.
>
>Can someone make a case for why we should bother with them, if there is this
>much confusion about their meaning?
>
>Bob
>

Date:         Wed, 26 Nov 1997 07:22:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Blake Greenlee <[email-masked]>
Subject:      Re: [IETF-PKIX] Consideration about country-legal aspect
To: [email-masked]
Status:

Dear Alessio:

An ISO CA standard is in process in Working Group 8 of TC68/SC2. We are always looking for participants from the financial community in SC2 member nations of which Italy is one.

The Italian Bankers Association is on the distribution list for copies of drafts - If you can't get a copy from them, send me an E-mail with your address, and I'll send you a copy.

Blake Greenlee
Convenor

-----Original Message-----
From:   Alessio Dragoni [SMTP:[email-masked]]
Sent:   Tuesday, November 25, 1997 6:13 AM
To:     [email-masked]
Subject:        [IETF-PKIX] Consideration about country-legal aspect

Hi!

        I work around the possibility to use the PKI proposed standard here in
Italy and
        trying to propose a main PCA for Europe that will have discussed to the new
        ISIS European Committee in January 1998.
        The scheme proposed in the drafts actually available is really good
        but speaking with some legal experts it seem to be difficult to come true.
        I need to gather together the tecnichal aspect and the legal aspect.

        thanks in advance for any help

        Alessio Dragoni

--

Alessio Dragoni ([email-masked])
Network Manager ATS-Link Communication
Member of IETF Security Workgroup

Head Office Arezzo | Rome Office | Internet Site
tel +39-575-985636 | tel +39-6-8546378 | http://www.ats.it
fax +39-575-984268 | fax +39-6-8546259 | http://www.webspace.it

PGP Fingerprint:
F390 959D 5674 7A07 C49B B1D7 8666 2F91 0A9E F2B2