Subject: Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
From: Hamid Homayouni <[email-masked]>
To: [email-masked]
Date: Wed, 26 Nov 1997 20:08:46 +1100

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 19:57:03 +1100
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: Hamid Homayouni <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

On Wednesday, November 26, 1997 1:38 AM, David P. Kemp  wrote:
> > From: Hamid Homayouni <[email-masked]>
> >
> > 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.
>
> Sounds good so far.
>
> > 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).
>
> Whoa!  It is one thing to have a signature key to be used for everyday
> I&A, where the key does not sign anything written by you.  But it is
> something quite different to have an everyday signature key that can be
> used for memos.
>
Wasn't it clear enough that the "memo" signature had nothing to do with any
electronic signature at all? I was just using the handwritten signature as
an analogy.

> I agree 100% with Bill Burr that the concept of a lightweight or
> repudiable signature key for messages ought to be squashed, at least

Where did this "repudiable" msg key idea come from?? I assumed it was
needless to say that one's message key is non-repudiable in its context (ie
I&A)!

> in connection with keyUsage bits.  If the legal framework to support
> such a separation between lightweight and "legally binding for contracts"
> keys is ever developed, then it might be implemented in the PKI using
> the certificatePolicies or extendedKeyUsage extensions, both of which

True. And as stated previously the technology and bits can just play ONE
role in the big picture of litigation process (maybe similar to an expert
witness). End of the day the judgement and ruling will be "subjective" like
most other court rulings and in fact may depend on who hired the more
expensive lawyer :-) So maybe it's too early to get to this level of
detailed discussion on this!

My point was and is that I'd prefer to be aware of digitally signing a
document, email, etc and not to mix it with my day-to-day I&A. And in an
extreme case (I know there are work arounds for this, but this is an
example) I don't end up giving the opportunity to a hacker to hi-jack my
challenge-response session and replace the challenge with "Bob go ahead and
buy those fantastic shares that you mentioned. Signed Alice".

Whether this can be best achieved by keyUsage extensions or cert policies,
or too early to worry about is another question.

> have an unlimited range of expression.  But the keyUsage extension bits
> are intended to be simple and unambiguous, and encode only a few broad
> application areas for keys.  The keyUsage extension should NOT be used to
> create a class of "repudiable message signature" keys.
>

Please see above.

-Hamid Homayouni

Date:         Tue, 25 Nov 1997 17:28: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: Dwight Arthur <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and nonrepudiation -- a modest proposal
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> >>> Carlisle Adams <[email-masked]> 11/20 3:33 PM >>>
> >Hi Bob,
> >
> >One small point:
> >
>
> >>
> >>If a certificate was still valid at the time a digital signature was
> >>received, it was obviously valid at the time the transaction was signed,
> and
> >>so the precise time at which that occurred is irrelevant, at least for
> >>purposes of (technical) nonrepudiation.
> >
> >Not quite true.  The document could conceivably have been signed prior
> >to the certificate being valid (e.g., before the public key was actually
> >certified, or while the certificate was "on hold" before becoming
> >valid).
> >
> >Sometimes time is useful...
> >
> >Carlisle.

<thorough and helpful discussion of operational periods and velidity
periods elided>

I am sorry to say that I missed the beginning of this thread. If I am
restating what has gone before, please just hit your delete button
...now.

Validity check may not occur at the time the cert is accepted. In the
case where an agent submits many transactions in the course of a day
which are then settled overnight or later, there may be some
efficiencies to be gained in accumulating transactions by unique
originator and doing a single end-of-day certificate validity check on
each originator's certificate. In most cases the certificate will be
found to have been valid all day or invalid all day. In cases where the
certificate was revoked during the day, prudence would seem to dictate
rejection of all transactions on that certificate that day.  However,
there may be cases where transactions made before revocation must be
honored, making the time an important factor.

-Dwight

Date:         Tue, 25 Nov 1997 17:14:07 -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:

>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, 25 Nov 1997 13:55:40 -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] ASN.1 for CertificatePolicies extension
To: [email-masked]
Status:

David P. Kemp wrote:
>
> Those not interested in ASN.1 trivia can hit the delete key now.
>
>  .
>  .
>  .
>  .
>
> The certificatePolicies extension includes the policyQualifierInfo
> structure, which is defined on page 65 of part 1 draft -06 as:
>
>     PolicyQualifierInfo ::= SEQUENCE {
>         policyQualifierId    PolicyQualifierId,
>         qualifier            ANY DEFINED BY policyQualifierId }
>
>     PolicyQualifierId ::= OBJECT IDENTIFIER
>
> and on page 82-83 as:
>
>     PolicyQualifierInfo ::= SEQUENCE {
>         policyQualifierId    CERT-POLICY-QUALIFIER.&id
>                                ({SupportedPolicyQualifiers}),
>         qualifier            CERT-POLICY-QUALIFIER.&Qualifier
>                                ({SupportedPolicyQualifiers}
>                                 {@policyQualifierId}) OPTIONAL }
>
> There are two PKIX-defined qualifier types: it-qt-cps and id-qt-unotice,
> with the respective qualifier syntaxes CPSuri and UserNotice.
>
> I have two questions about the encoding of this extension using the
> PKIX-defined qualifier types:
>
>  1) is qualifier OPTIONAL?  (it is not defined as OPTIONAL
>        on pages 25 and 65, and it is defined as OPTIONAL on page 83.)

Yes, qualifier is OPTIONAL in X.509x97, and a notation that allows
objects of class CERT-POLICY-QUALIFIER to be created without an
optional associated type is provided in the class definition:

  WITH SYNTAX { POLICY-QUALIFIER-ID &id [QUALIFIER-TYPE &Qualifier] }

>
>  2) is qualifier encoded as a DER transfer string encapsulated in an
>        OCTET STRING (as is the case with extension values), or is
>        qualifier encoded directly after policyQualifierId?
>

It may be either in a given context. A note in X.509x97 states:

  A qualifier may be specified as having any ASN.1 type. When the
qualifier
  is anticipated to be used primarily with applications that do not have
  ASN.1 decoding functions, it is recommended that the type OCTET STRING
  be specified. The ASN.1 OCTET STRING value can then convey a qualifier
  value encoded according to any convention specified by the policy
element
  defining organization.

> My guesses are that:
>
>  1) qualifier should NOT be optional - a particular policyQualifierId
>     might specify that there is no associated qualifier, but if a
>     particular Id has a defined qualifier, that qualifier must always
>     be present.  (The syntax for a particular qualifier may in turn
>     have OPTIONAL elements, or be entirely OPTIONAL.)

The information object set, SupportedPolicyQualifiers, is used to
provide
a table constraint on the two components of type PolicyQualifierInfo. An
extensible set of objects is defined in X.509x97:

  SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... }

An application would modify this set to include objects it needs to
know how to process. These might include OIDs associated with a
specific type, or OIDs that are not so associated:

SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= {
   --                   Unique OID    Some ASN.1 Type  --
   --                      &id           &Qualifier    --
   --                                                  --
   { POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE IA5String } |
   { POLICY-QUALIFIER-ID id-madeUp                          },
   ...
}

>
>  2) qualifier is NOT a DER transfer string inside an OCTET STRING.
>     The encoding of id-qt-cps would be:
>
>       SEQUENCE {
>          OID id-qt-cps
>          IA5String ... }
>
>     and not
>
>       SEQUENCE {
>          OID id-qt-cps
>          OCTET STRING ... }
>

It could be specified in either manner by the note
included above. I prefer your suggested ASN.1
representation that eliminates the octet hole.

> Comments?
>
> Dave Kemp

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, 25 Nov 1997 11:09: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: "David P. Kemp" <[email-masked]>
Subject:      [IETF-PKIX] ASN.1 for CertificatePolicies extension
To: [email-masked]
Status:

Those not interested in ASN.1 trivia can hit the delete key now.

 .
 .
 .
 .

The certificatePolicies extension includes the policyQualifierInfo
structure, which is defined on page 65 of part 1 draft -06 as:

    PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId    PolicyQualifierId,
        qualifier            ANY DEFINED BY policyQualifierId }

    PolicyQualifierId ::= OBJECT IDENTIFIER

and on page 82-83 as:

    PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId    CERT-POLICY-QUALIFIER.&id
                               ({SupportedPolicyQualifiers}),
        qualifier            CERT-POLICY-QUALIFIER.&Qualifier
                               ({SupportedPolicyQualifiers}
                                {@policyQualifierId}) OPTIONAL }

There are two PKIX-defined qualifier types: it-qt-cps and id-qt-unotice,
with the respective qualifier syntaxes CPSuri and UserNotice.

I have two questions about the encoding of this extension using the
PKIX-defined qualifier types:

 1) is qualifier OPTIONAL?  (it is not defined as OPTIONAL
       on pages 25 and 65, and it is defined as OPTIONAL on page 83.)

 2) is qualifier encoded as a DER transfer string encapsulated in an
       OCTET STRING (as is the case with extension values), or is
       qualifier encoded directly after policyQualifierId?

My guesses are that:

 1) qualifier should NOT be optional - a particular policyQualifierId
    might specify that there is no associated qualifier, but if a
    particular Id has a defined qualifier, that qualifier must always
    be present.  (The syntax for a particular qualifier may in turn
    have OPTIONAL elements, or be entirely OPTIONAL.)

 2) qualifier is NOT a DER transfer string inside an OCTET STRING.
    The encoding of id-qt-cps would be:

      SEQUENCE {
         OID id-qt-cps
         IA5String ... }

    and not

      SEQUENCE {
         OID id-qt-cps
         OCTET STRING ... }

Comments?

Dave Kemp

Date:         Tue, 25 Nov 1997 15:25:51 +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: Alain Zahm <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
To: [email-masked]
Status:

If the signature is the same in all cases, the protocol set up to prove
your identity is not the same.
UPS just asks the one who open the door to sign a paper.
When I am asking for 1 M $ credit my banker is asking me more than just
proving who I am....

----------
> De : Sam Schaen <[email-masked]>
> A : [email-masked]
> Objet : Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
> Date : mardi 25 novembre 1997 15:04
>
> I believe too much is being made of the difference between
> digitalSignature and nonRepudiation.  What we seem to be ignoring is the
> context of the signature.  In the "wet signature" world, my same
> handwritten signature can be used to sign a $10 check at the grocery
> store, a $200K mortgage, or acknowledge receipt of a package from UPS.
>
> I claim that in any context, the law will make assumptions about what
> was reasonably intended by a signature and will hold reasonable
> standards for what protections must surround the storage and use of the
> digital signature.  Furthermore, any certificate will have a CPS behind
> it that provides contractual limitations on what the signature can be
> obligated for.
>
> Sam Schaen
>
> 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).
> >
> > So regardless of how it's implemented, the idea of key usage extension
is
> > useful, and I also suggest that the digitalSignature bit be set by
default
> > when nonRepudiation bit is set, but not the other way round. So I end
up
> > conveniently using my nonRepudiation key for both non-rep and I&A when
I've
> > consciously pulled it out. But I won't inadvertently sign a something
while
> > I'm using my other key for day-to-day I&A purposes.
> >
> > Regards,
> >
> > -Hamid Homayouni
> >
> > On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:
> >
> > > It seems to me that these two bits are trying to split much too fine
a
> > > hair.  The best solution would be to eliminate one or the other.  I
> > wasn't
> > > a participant in the discussions that led to the inclusion of both in
the
> > > Key Usage field, and have no real idea what was on the participants
mind
> > in
> > > making this distinction, but there doesn't seem to be any real
agreement
> > > about just what non-repudiation actually means.
> > >
> > > I would say that non-repudiation is, or ought to be, a property,
rather
> > > than a service or a usage, which any digital signature ought to be
> > designed
> > > to have, to as high a degree as practical, and which is greatly
affected
> > by
> > > other circumstances of the signature (e.g., date-time stamps, or
whether
> > a
> > > gun was pointed at the head of the signatory when he executed the
> > signature).
> > >
> > > The idea of an explicitly repudiable digital signature is repugnant.
So,
> > > if setting the digitalDignature bit while not setting the
nonRepudiation
> > > bit means, in effect, "I reserve the right to deny I ever signed
this," I
> > > think I'd like to see that combination banned. If I have such a
> > > certificate, can I use it to authenticate myself to log onto a
system, do
> > > some mischief, then repudiate that I ever logged on?
> > >
> > > If the point of the nonRepudiation bit is just to say this is a bit
> > > stronger kind of a key or signature, then I that may be OK, but
> > > certificatPolicies, if you believe in them, may be a better way to
> > express
> > > this.  At any rate, if this is the case, setting nonRepudiation while
> > > leaving digitalSignature unset, makes no sense.
> > >
> > > I'm afraid that what we have here is another example of the kind of a
> > camel
> > > that we often get from a standards committee, which designs in the
> > abstract
> > > for the ages, and supplies answers for questions that haven't been
and
> > > don't need to be asked.  I'd prefer to see one of the bits eliminated
> > > altogether. Failing that, I'd like to profile both bits as either set
or
> > > not set together, but never just one or the other.
> > >
> > >
> > >
> > > At 04:26 PM 11/22/97 -0700, you wrote:
> > > >I agree in setting both if the CA issuing the cert is issuing it for
> > more
> > > >than just I&A, as would/should most commercial CAs such as banks or
> > > >merchants.
> > > >
> > > >I also believe that, because the options are in the extension, a
lawyer
> > > >could argue against non-repudiation if it is not set, even though
the
> > > >re;liant party knows who signed something and that what was signed
has
> > not
> > > >been altered since signing.
> > > >
> > > >If someone were contesting (attempting to repudiate) a signed
agreement
> > > >because non-repudiation was not set, then that would probably go in
> > front of
> > > >a court fro final arbitration.  If they both were set, then that
reason
> > is
> > > >at least eliminated.
> > > >
> > > >michael
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Simonetti David <[email-masked]>
> > > >To: [email-masked] <[email-masked]>
> > > >Date: Monday, November 17, 1997 1:45 PM
> > > >Subject: digitalSignature vs. nonRepudiation
> > > >
> > > >
> > > >>I am attempting to implement the key usages as defined for the
keyUsage
> > > >>extension.  I am stumbling upon digitalSignature and
nonRepudiation.
> > > >>
> > > >>I define the key usage digitalSignature as a public key which
affords
> > > >>the services of authentication and data integrity.
> > > >>
> > > >>Of course, nonRepudiation affords the service of non-repudiation.
> > > >>
> > > >>My question is, with only nonRepudiation set (and not
> > digitalSignature),
> > > >>is it true that my public key can be used only to provide the
service
> > of
> > > >>non-repudiation, and NOT the services of authentication and data
> > > >>integrity?  If this is true, I'm curious to know how this is
> > > >>implemented.
> > > >>
> > > >>I claim that if the nonRepudiation bit is set, that I can use that
key
> > > >>to implement authentication and data integrity, and also claim
> > > >>nonRepudiation of the originator.  Since authentication and data
> > > >>integrity are services provided under digitalSignature, I believe
that
> > > >>when nonRepudiation is set, digitalSignature should also be set.
> > > >>
> > > >>I'd like to hear agreements or disagreements with my line of
reasoning.
> > > >>
> > > >>Dave Simonetti
> > > >>
> > > >>
> > > >
> > > >
> > > Regards,
> > >
> > > Bill Burr

Date:         Tue, 25 Nov 1997 09:37: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

> From: Hamid Homayouni <[email-masked]>
>
> 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.

Sounds good so far.

> 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).

Whoa!  It is one thing to have a signature key to be used for everyday
I&A, where the key does not sign anything written by you.  But it is
something quite different to have an everyday signature key that can be
used for memos.

I agree 100% with Bill Burr that the concept of a lightweight or
repudiable signature key for messages ought to be squashed, at least
in connection with keyUsage bits.  If the legal framework to support
such a separation between lightweight and "legally binding for contracts"
keys is ever developed, then it might be implemented in the PKI using
the certificatePolicies or extendedKeyUsage extensions, both of which
have an unlimited range of expression.  But the keyUsage extension bits
are intended to be simple and unambiguous, and encode only a few broad
application areas for keys.  The keyUsage extension should NOT be used to
create a class of "repudiable message signature" keys.

Date:         Tue, 25 Nov 1997 09:24: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

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.

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).
>
>So regardless of how it's implemented, the idea of key usage extension is
>useful, and I also suggest that the digitalSignature bit be set by default
>when nonRepudiation bit is set, but not the other way round. So I end up
>conveniently using my nonRepudiation key for both non-rep and I&A when I've
>consciously pulled it out. But I won't inadvertently sign a something while
>I'm using my other key for day-to-day I&A purposes.
>
>Regards,
>
>-Hamid Homayouni
>
>On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:
>
>> It seems to me that these two bits are trying to split much too fine a
>> hair.  The best solution would be to eliminate one or the other.  I
>wasn't
>> a participant in the discussions that led to the inclusion of both in the
>> Key Usage field, and have no real idea what was on the participants mind
>in
>> making this distinction, but there doesn't seem to be any real agreement
>> about just what non-repudiation actually means.
>>
>> I would say that non-repudiation is, or ought to be, a property, rather
>> than a service or a usage, which any digital signature ought to be
>designed
>> to have, to as high a degree as practical, and which is greatly affected
>by
>> other circumstances of the signature (e.g., date-time stamps, or whether
>a
>> gun was pointed at the head of the signatory when he executed the
>signature).
>>
>> The idea of an explicitly repudiable digital signature is repugnant.  So,
>> if setting the digitalDignature bit while not setting the nonRepudiation
>> bit means, in effect, "I reserve the right to deny I ever signed this," I
>> think I'd like to see that combination banned. If I have such a
>> certificate, can I use it to authenticate myself to log onto a system, do
>> some mischief, then repudiate that I ever logged on?
>>
>> If the point of the nonRepudiation bit is just to say this is a bit
>> stronger kind of a key or signature, then I that may be OK, but
>> certificatPolicies, if you believe in them, may be a better way to
>express
>> this.  At any rate, if this is the case, setting nonRepudiation while
>> leaving digitalSignature unset, makes no sense.
>>
>> I'm afraid that what we have here is another example of the kind of a
>camel
>> that we often get from a standards committee, which designs in the
>abstract
>> for the ages, and supplies answers for questions that haven't been and
>> don't need to be asked.  I'd prefer to see one of the bits eliminated
>> altogether. Failing that, I'd like to profile both bits as either set or
>> not set together, but never just one or the other.
>>
>>
>>
>> At 04:26 PM 11/22/97 -0700, you wrote:
>> >I agree in setting both if the CA issuing the cert is issuing it for
>more
>> >than just I&A, as would/should most commercial CAs such as banks or
>> >merchants.
>> >
>> >I also believe that, because the options are in the extension, a lawyer
>> >could argue against non-repudiation if it is not set, even though the
>> >re;liant party knows who signed something and that what was signed has
>not
>> >been altered since signing.
>> >
>> >If someone were contesting (attempting to repudiate) a signed agreement
>> >because non-repudiation was not set, then that would probably go in
>front of
>> >a court fro final arbitration.  If they both were set, then that reason
>is
>> >at least eliminated.
>> >
>> >michael
>> >
>> >
>> >-----Original Message-----
>> >From: Simonetti David <[email-masked]>
>> >To: [email-masked] <[email-masked]>
>> >Date: Monday, November 17, 1997 1:45 PM
>> >Subject: digitalSignature vs. nonRepudiation
>> >
>> >
>> >>I am attempting to implement the key usages as defined for the keyUsage
>> >>extension.  I am stumbling upon digitalSignature and nonRepudiation.
>> >>
>> >>I define the key usage digitalSignature as a public key which affords
>> >>the services of authentication and data integrity.
>> >>
>> >>Of course, nonRepudiation affords the service of non-repudiation.
>> >>
>> >>My question is, with only nonRepudiation set (and not
>digitalSignature),
>> >>is it true that my public key can be used only to provide the service
>of
>> >>non-repudiation, and NOT the services of authentication and data
>> >>integrity?  If this is true, I'm curious to know how this is
>> >>implemented.
>> >>
>> >>I claim that if the nonRepudiation bit is set, that I can use that key
>> >>to implement authentication and data integrity, and also claim
>> >>nonRepudiation of the originator.  Since authentication and data
>> >>integrity are services provided under digitalSignature, I believe that
>> >>when nonRepudiation is set, digitalSignature should also be set.
>> >>
>> >>I'd like to hear agreements or disagreements with my line of reasoning.
>> >>
>> >>Dave Simonetti
>> >>
>> >>
>> >
>> >
>> Regards,
>>
>> Bill Burr
>

Date:         Tue, 25 Nov 1997 09:04:30 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sam Schaen <[email-masked]>
Organization: MITRE Corporation
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

I believe too much is being made of the difference between
digitalSignature and nonRepudiation.  What we seem to be ignoring is the
context of the signature.  In the "wet signature" world, my same
handwritten signature can be used to sign a $10 check at the grocery
store, a $200K mortgage, or acknowledge receipt of a package from UPS.

I claim that in any context, the law will make assumptions about what
was reasonably intended by a signature and will hold reasonable
standards for what protections must surround the storage and use of the
digital signature.  Furthermore, any certificate will have a CPS behind
it that provides contractual limitations on what the signature can be
obligated for.

Sam Schaen

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).
>
> So regardless of how it's implemented, the idea of key usage extension is
> useful, and I also suggest that the digitalSignature bit be set by default
> when nonRepudiation bit is set, but not the other way round. So I end up
> conveniently using my nonRepudiation key for both non-rep and I&A when I've
> consciously pulled it out. But I won't inadvertently sign a something while
> I'm using my other key for day-to-day I&A purposes.
>
> Regards,
>
> -Hamid Homayouni
>
> On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:
>
> > It seems to me that these two bits are trying to split much too fine a
> > hair.  The best solution would be to eliminate one or the other.  I
> wasn't
> > a participant in the discussions that led to the inclusion of both in the
> > Key Usage field, and have no real idea what was on the participants mind
> in
> > making this distinction, but there doesn't seem to be any real agreement
> > about just what non-repudiation actually means.
> >
> > I would say that non-repudiation is, or ought to be, a property, rather
> > than a service or a usage, which any digital signature ought to be
> designed
> > to have, to as high a degree as practical, and which is greatly affected
> by
> > other circumstances of the signature (e.g., date-time stamps, or whether
> a
> > gun was pointed at the head of the signatory when he executed the
> signature).
> >
> > The idea of an explicitly repudiable digital signature is repugnant.  So,
> > if setting the digitalDignature bit while not setting the nonRepudiation
> > bit means, in effect, "I reserve the right to deny I ever signed this," I
> > think I'd like to see that combination banned. If I have such a
> > certificate, can I use it to authenticate myself to log onto a system, do
> > some mischief, then repudiate that I ever logged on?
> >
> > If the point of the nonRepudiation bit is just to say this is a bit
> > stronger kind of a key or signature, then I that may be OK, but
> > certificatPolicies, if you believe in them, may be a better way to
> express
> > this.  At any rate, if this is the case, setting nonRepudiation while
> > leaving digitalSignature unset, makes no sense.
> >
> > I'm afraid that what we have here is another example of the kind of a
> camel
> > that we often get from a standards committee, which designs in the
> abstract
> > for the ages, and supplies answers for questions that haven't been and
> > don't need to be asked.  I'd prefer to see one of the bits eliminated
> > altogether. Failing that, I'd like to profile both bits as either set or
> > not set together, but never just one or the other.
> >
> >
> >
> > At 04:26 PM 11/22/97 -0700, you wrote:
> > >I agree in setting both if the CA issuing the cert is issuing it for
> more
> > >than just I&A, as would/should most commercial CAs such as banks or
> > >merchants.
> > >
> > >I also believe that, because the options are in the extension, a lawyer
> > >could argue against non-repudiation if it is not set, even though the
> > >re;liant party knows who signed something and that what was signed has
> not
> > >been altered since signing.
> > >
> > >If someone were contesting (attempting to repudiate) a signed agreement
> > >because non-repudiation was not set, then that would probably go in
> front of
> > >a court fro final arbitration.  If they both were set, then that reason
> is
> > >at least eliminated.
> > >
> > >michael
> > >
> > >
> > >-----Original Message-----
> > >From: Simonetti David <[email-masked]>
> > >To: [email-masked] <[email-masked]>
> > >Date: Monday, November 17, 1997 1:45 PM
> > >Subject: digitalSignature vs. nonRepudiation
> > >
> > >
> > >>I am attempting to implement the key usages as defined for the keyUsage
> > >>extension.  I am stumbling upon digitalSignature and nonRepudiation.
> > >>
> > >>I define the key usage digitalSignature as a public key which affords
> > >>the services of authentication and data integrity.
> > >>
> > >>Of course, nonRepudiation affords the service of non-repudiation.
> > >>
> > >>My question is, with only nonRepudiation set (and not
> digitalSignature),
> > >>is it true that my public key can be used only to provide the service
> of
> > >>non-repudiation, and NOT the services of authentication and data
> > >>integrity?  If this is true, I'm curious to know how this is
> > >>implemented.
> > >>
> > >>I claim that if the nonRepudiation bit is set, that I can use that key
> > >>to implement authentication and data integrity, and also claim
> > >>nonRepudiation of the originator.  Since authentication and data
> > >>integrity are services provided under digitalSignature, I believe that
> > >>when nonRepudiation is set, digitalSignature should also be set.
> > >>
> > >>I'd like to hear agreements or disagreements with my line of reasoning.
> > >>
> > >>Dave Simonetti
> > >>
> > >>
> > >
> > >
> > Regards,
> >
> > Bill Burr

Date:         Tue, 25 Nov 1997 08:45: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: John Lowry <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

The observation that a digital signature is (may) be required to
establish authentication and non-repudiation leads many to
believe that the only remaining distinguishing element between the two
is legal.  They therefore believe that - technically - their
job is done.

This is not true.  The distinction is that digital signature is
required in both cases but clearly not sufficient for non-repudiation.
(I won't argue whether it is sufficient for authentication right now.)
There are clearly "legal" requirements like "performance" by the parties
and recognition by the authorities.  However, the performance criteria for
non-repudiation is going to be significantly higher than authentication
and will require additional technical mechanisms in support.  Many of these
show up as requirements for certificate and CRL management techniques.  There
are some that show up as requirements on the user.  For example,
it is unlikely that a user will ever be able to establish non-repudiation
if the key is not protected by a hardware token.  A "softkey" might, however,
be sufficient for authentication in some environments.

One of the additional technical requirements for non-repudiation
is the establishment of a time context (one that is outside the control
of any of the participants).  This means that an authenticated trusted time
source must exist and be available to all communicating parties and the
entity evaluating the claim of repudiation.

I believe that the assertion of the non-repudiation bit in a keyUsage
field may impose some additional "due-diligence" on the CA to be
confident that the claim can be supported.  It is the CA, after all, who
is asserting that the key is to be used for non-repudiation.  At a minimum
the CA must make sure that the key is adequately protected and otherwise
managed.  For example, does it make sense to use a hardware token to protect a
"non-repudiation" key if used by more than one entity ?  Does the CA himself
have to meet any criteria to support a non-repudiation service ?  Does the CA
have to make certain that the user's environment supports a non-repudiation
service ?  Does the CA have to make certain that other TTP services are
available and suitable ?  If I were a CA, instead of a CA technology provider,
I would be loath to assert that non-repudiation bit until I had answers to all
these questions (and more).  Further, if I were the developer of technology
that uses certificates for key management, I would make clear distinctions
between those two bits - particularly when it came to informing the user
as to the service "successfully" applied.  I can think of no system
today that can accurately tell the user that "Non-repudiation can be
established for this communication."  Does a system that inaccurately
make that claim risk liability for its manufacturer if the user
depends on it ?

Regards,

John Lowry

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).
>
>So regardless of how it's implemented, the idea of key usage extension is
>useful, and I also suggest that the digitalSignature bit be set by default
>when nonRepudiation bit is set, but not the other way round. So I end up
>conveniently using my nonRepudiation key for both non-rep and I&A when I've
>consciously pulled it out. But I won't inadvertently sign a something while
>I'm using my other key for day-to-day I&A purposes.
>
>Regards,
>
>-Hamid Homayouni
>
>On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:
>
>> It seems to me that these two bits are trying to split much too fine a
>> hair.  The best solution would be to eliminate one or the other.  I
>wasn't
>> a participant in the discussions that led to the inclusion of both in the
>> Key Usage field, and have no real idea what was on the participants mind
>in
>> making this distinction, but there doesn't seem to be any real agreement
>> about just what non-repudiation actually means.
>>
>> I would say that non-repudiation is, or ought to be, a property, rather
>> than a service or a usage, which any digital signature ought to be
>designed
>> to have, to as high a degree as practical, and which is greatly affected
>by
>> other circumstances of the signature (e.g., date-time stamps, or whether
>a
>> gun was pointed at the head of the signatory when he executed the
>signature).
>>
>> The idea of an explicitly repudiable digital signature is repugnant.  So,
>> if setting the digitalDignature bit while not setting the nonRepudiation
>> bit means, in effect, "I reserve the right to deny I ever signed this," I
>> think I'd like to see that combination banned. If I have such a
>> certificate, can I use it to authenticate myself to log onto a system, do
>> some mischief, then repudiate that I ever logged on?
>>
>> If the point of the nonRepudiation bit is just to say this is a bit
>> stronger kind of a key or signature, then I that may be OK, but
>> certificatPolicies, if you believe in them, may be a better way to
>express
>> this.  At any rate, if this is the case, setting nonRepudiation while
>> leaving digitalSignature unset, makes no sense.
>>
>> I'm afraid that what we have here is another example of the kind of a
>camel
>> that we often get from a standards committee, which designs in the
>abstract
>> for the ages, and supplies answers for questions that haven't been and
>> don't need to be asked.  I'd prefer to see one of the bits eliminated
>> altogether. Failing that, I'd like to profile both bits as either set or
>> not set together, but never just one or the other.
>>
>>
>>
>> At 04:26 PM 11/22/97 -0700, you wrote:
>> >I agree in setting both if the CA issuing the cert is issuing it for
>more
>> >than just I&A, as would/should most commercial CAs such as banks or
>> >merchants.
>> >
>> >I also believe that, because the options are in the extension, a lawyer
>> >could argue against non-repudiation if it is not set, even though the
>> >re;liant party knows who signed something and that what was signed has
>not
>> >been altered since signing.
>> >
>> >If someone were contesting (attempting to repudiate) a signed agreement
>> >because non-repudiation was not set, then that would probably go in
>front of
>> >a court fro final arbitration.  If they both were set, then that reason
>is
>> >at least eliminated.
>> >
>> >michael
>> >
>> >
>> >-----Original Message-----
>> >From: Simonetti David <[email-masked]>
>> >To: [email-masked] <[email-masked]>
>> >Date: Monday, November 17, 1997 1:45 PM
>> >Subject: digitalSignature vs. nonRepudiation
>> >
>> >
>> >>I am attempting to implement the key usages as defined for the keyUsage
>> >>extension.  I am stumbling upon digitalSignature and nonRepudiation.
>> >>
>> >>I define the key usage digitalSignature as a public key which affords
>> >>the services of authentication and data integrity.
>> >>
>> >>Of course, nonRepudiation affords the service of non-repudiation.
>> >>
>> >>My question is, with only nonRepudiation set (and not
>digitalSignature),
>> >>is it true that my public key can be used only to provide the service
>of
>> >>non-repudiation, and NOT the services of authentication and data
>> >>integrity?  If this is true, I'm curious to know how this is
>> >>implemented.
>> >>
>> >>I claim that if the nonRepudiation bit is set, that I can use that key
>> >>to implement authentication and data integrity, and also claim
>> >>nonRepudiation of the originator.  Since authentication and data
>> >>integrity are services provided under digitalSignature, I believe that
>> >>when nonRepudiation is set, digitalSignature should also be set.
>> >>
>> >>I'd like to hear agreements or disagreements with my line of reasoning.
>> >>
>> >>Dave Simonetti
>> >>
>> >>
>> >
>> >
>> Regards,
>>
>> Bill Burr
>
>

Date:         Tue, 25 Nov 1997 12:13:28 +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: Alessio Dragoni <[email-masked]>
Subject:      [IETF-PKIX] Consideration about country-legal aspect
To: [email-masked]
Status:

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

Date:         Tue, 25 Nov 1997 14:20:25 +1100
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: Hamid Homayouni <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

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).

So regardless of how it's implemented, the idea of key usage extension is
useful, and I also suggest that the digitalSignature bit be set by default
when nonRepudiation bit is set, but not the other way round. So I end up
conveniently using my nonRepudiation key for both non-rep and I&A when I've
consciously pulled it out. But I won't inadvertently sign a something while
I'm using my other key for day-to-day I&A purposes.

Regards,

-Hamid Homayouni

On Tuesday, November 25, 1997 3:15 AM, Bill Burr  wrote:

> It seems to me that these two bits are trying to split much too fine a
> hair.  The best solution would be to eliminate one or the other.  I
wasn't
> a participant in the discussions that led to the inclusion of both in the
> Key Usage field, and have no real idea what was on the participants mind
in
> making this distinction, but there doesn't seem to be any real agreement
> about just what non-repudiation actually means.
>
> I would say that non-repudiation is, or ought to be, a property, rather
> than a service or a usage, which any digital signature ought to be
designed
> to have, to as high a degree as practical, and which is greatly affected
by
> other circumstances of the signature (e.g., date-time stamps, or whether
a
> gun was pointed at the head of the signatory when he executed the
signature).
>
> The idea of an explicitly repudiable digital signature is repugnant.  So,
> if setting the digitalDignature bit while not setting the nonRepudiation
> bit means, in effect, "I reserve the right to deny I ever signed this," I
> think I'd like to see that combination banned. If I have such a
> certificate, can I use it to authenticate myself to log onto a system, do
> some mischief, then repudiate that I ever logged on?
>
> If the point of the nonRepudiation bit is just to say this is a bit
> stronger kind of a key or signature, then I that may be OK, but
> certificatPolicies, if you believe in them, may be a better way to
express
> this.  At any rate, if this is the case, setting nonRepudiation while
> leaving digitalSignature unset, makes no sense.
>
> I'm afraid that what we have here is another example of the kind of a
camel
> that we often get from a standards committee, which designs in the
abstract
> for the ages, and supplies answers for questions that haven't been and
> don't need to be asked.  I'd prefer to see one of the bits eliminated
> altogether. Failing that, I'd like to profile both bits as either set or
> not set together, but never just one or the other.
>
>
>
> At 04:26 PM 11/22/97 -0700, you wrote:
> >I agree in setting both if the CA issuing the cert is issuing it for
more
> >than just I&A, as would/should most commercial CAs such as banks or
> >merchants.
> >
> >I also believe that, because the options are in the extension, a lawyer
> >could argue against non-repudiation if it is not set, even though the
> >re;liant party knows who signed something and that what was signed has
not
> >been altered since signing.
> >
> >If someone were contesting (attempting to repudiate) a signed agreement
> >because non-repudiation was not set, then that would probably go in
front of
> >a court fro final arbitration.  If they both were set, then that reason
is
> >at least eliminated.
> >
> >michael
> >
> >
> >-----Original Message-----
> >From: Simonetti David <[email-masked]>
> >To: [email-masked] <[email-masked]>
> >Date: Monday, November 17, 1997 1:45 PM
> >Subject: digitalSignature vs. nonRepudiation
> >
> >
> >>I am attempting to implement the key usages as defined for the keyUsage
> >>extension.  I am stumbling upon digitalSignature and nonRepudiation.
> >>
> >>I define the key usage digitalSignature as a public key which affords
> >>the services of authentication and data integrity.
> >>
> >>Of course, nonRepudiation affords the service of non-repudiation.
> >>
> >>My question is, with only nonRepudiation set (and not
digitalSignature),
> >>is it true that my public key can be used only to provide the service
of
> >>non-repudiation, and NOT the services of authentication and data
> >>integrity?  If this is true, I'm curious to know how this is
> >>implemented.
> >>
> >>I claim that if the nonRepudiation bit is set, that I can use that key
> >>to implement authentication and data integrity, and also claim
> >>nonRepudiation of the originator.  Since authentication and data
> >>integrity are services provided under digitalSignature, I believe that
> >>when nonRepudiation is set, digitalSignature should also be set.
> >>
> >>I'd like to hear agreements or disagreements with my line of reasoning.
> >>
> >>Dave Simonetti
> >>
> >>
> >
> >
> Regards,
>
> Bill Burr

Date:         Mon, 24 Nov 1997 15:04:49 -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] Revised OCSP Draft
To: [email-masked]
Status:

The draft was submitted on Friday but still hasn't shown up yet.  No doubt
there's a backlog.  If you or anyone else would like a direct copy, let me
know.

At 04:14 PM 11/24/97 -0500, Robert Zuccherato wrote:
>Mike;
>
>I have been out of town for the past week and so couldn't take part in
>the lively discussion you have all been having.  I look forward to
>seeing the new document and hope that the concerns that have been
>mentioned here are addressed.  There is still (at least) one issue that
>bothers me.
>
>>----------
>>From:  [email-masked][SMTP:[email-masked]]
>>Sent:  Friday, November 21, 1997 7:36 PM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] Revised OCSP Draft
>>
>>I left the abstraction of the trust model as it stands, although there's
>>some need for refinement to further reduce complexity in the non-CA trust
>>model.
>
>I won't pass judgment until I see the document, but this concerns me.
>As I stated before:
>
>I think a lot of my difficulty with this document comes from the fact
>that I don't really understand the model from which you are working and
>it isn't really well defined in the document.  Perhaps this will become
>more clear as the discussion continues.
>
>I apologize if I missed something in the volume of email I worked
>through today, but I don't think that this issue has adequately been
>addressed.  A short description of the trust model would help to clarify
>many of the problems that people have been having.  I think that we all
>have different implementations of this service in mind when commenting
>on your protocol.
>
>        Robert Zuccherato
>
>
>
>>
>
>

Date:         Mon, 24 Nov 1997 17:38: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

> From: Bill Burr <[email-masked]>
>
> It seems to me that this non-repudiation orange in the barrel of mechanism
> apples is quite evidently causing a lot of confusion.  So, if we take Dave
> Kemp's proposal, which is logically consistent, and consistent with X.509,
> then it means that a certificate with only the digitalSignature bit set may
> be used to sign anything except:
>
> 1. a Certificate
> 2. a CRL
> 3. anything, whatever it is, that is to have the peculiar property of
> non-repudiation.

Item 3 includes anything (every message or item of data meaningful to
a user) that has a signature affixed.

If you have a key with bit 0 set which can't be used for 1, 2, and 3,
then effectively the only thing left which it can be used for is
signing data internal to operation of a communication protocol.  It
seems eminently reasonable that transient data such as nonces would not
"have the peculiar property of non-repudiation" - it isn't meaningful
for a user to "sign" (agree to be bound by) a random number, or record
type codes and length fields, or hashes of handshake messages, or other
such protocol stuff.

The signatures contained in a protocol exchange are clearly intended
to be ephemeral.  You could save them by directing the output of a
sniffer to a file, but the user clearly intended and expected them to
disappear the instant after they had served the purpose of
authentication.  Since such signatures are not intended (authorized by
the user or the CA) to be preserved, there is nothing to repudiate.

> Given all this, it isn't clear to me what if a message signed with a key
> with only digitalSignature set means, and if I should reject the signature,
> or if the signer could then more or less automatically get away with
> repudiating it.

Would it be any clearer if the statement were phrased:

  "... what a message signed with a key with only *authentication* set means,
   and if I should reject the signature, ..."

or

  "... what a message signed with a key with only *dataEncipherment* set means,
   and if I should reject the signature, ..."

In the second case, it's obvious that you can't sign any message with an
encryption-only key, so you should reject the signature.

In the first case, it should be just as obvious that you can't sign any
message with an authentication-only key, so again, you should reject the
signature.

Perhaps the proposal should be to rename keyUsage bit 0 to
"authentication", instead of removing the ability to distinguish between
signed messages and ephemerally-signed random numbers.

Date:         Mon, 24 Nov 1997 17:14:01 -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:

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

Bill Burr wrote:
>
> At 12:08 PM 11/24/97 -0500, you wrote:
> >Bill,
> >
> >       Non-repudiation is a well-defined service that requires more than a
> >digital signature, as noted by others.  One can use a digital signature for
> >authentication applications where there is explicitly no intent that the
> >result be non-repudiable.  At least in part, motivation for being able to
> >declare a key NOT ot be used for non-repudiation purposes, is because some
> >authentication protocols can produce results that might be used to support
> >a non-repudiation claim, when it was not the intent of the key holder to do
> >so.  We can minimize these problems through more careful design of
> >authentication and integrity protocols, but using this flag to make an
> >explciit statement also is an appropriate measure.
> >
> >Steve
> >
> >
> >
>
> Steve,
>
> Going back to the old ISO 7498-2 document, which I take to have the
> official definition of non-repudiation, non-repudiation is a service and
> digital signature is a mechanism.  So everything else in the key usage list
> is a mechanism, or a mechanism restricted to use with a particular very
> specific PKI data object (e.g., signature for certificates), but
> non-repudiation is a broad service.
>
> It seems to me that this non-repudiation orange in the barrel of mechanism
> apples is quite evidently causing a lot of confusion.  So, if we take Dave
> Kemp's proposal, which is logically consistent, and consistent with X.509,
> then it means that a certificate with only the digitalSignature bit set may
> be used to sign anything except:
>
> 1. a Certificate
> 2. a CRL
> 3. anything, whatever it is, that is to have the peculiar property of
> non-repudiation.
>
> Given all this, it isn't clear to me what if a message signed with a key
> with only digitalSignature set means, and if I should reject the signature,
> or if the signer could then more or less automatically get away with
> repudiating it.  I suppose that some folks may see this a great way for PKI
> priests and wizards to  make some money as expert witnesses testifying to
> the accepted or true meaning of nonRepudiation.
>
> It would, in my view, be simpler and more logical if we had separate fields
> for the cryptographic mechanisms (digital signature, encypherment, key
> agreement) associated with the key and the kinds of objects against which
> it could be implied (for signatures: certificates, CRLs, possibly
> certificate status reports, or any other data object.  For encypherment:
> keys, or any other data), and steer clear of services altogether.  But, if
> we try to fix everything that is confusing with X.509 we'll be at it forever.
>
> So my proposal is to treat digitalSignature and nonRepudiation as a single
> bit and refer only to a mechanism, unconfused with a service.  This whole
> thing (i.e, x.509 ane PKIX) is already too complicated and too confusing.
>
> Regards,
>
> Bill Burr

Date:         Mon, 24 Nov 1997 16:14: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] Revised OCSP Draft
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Mike;

I have been out of town for the past week and so couldn't take part in
the lively discussion you have all been having.  I look forward to
seeing the new document and hope that the concerns that have been
mentioned here are addressed.  There is still (at least) one issue that
bothers me.

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Friday, November 21, 1997 7:36 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Revised OCSP Draft
>
>I left the abstraction of the trust model as it stands, although there's
>some need for refinement to further reduce complexity in the non-CA trust
>model.

I won't pass judgment until I see the document, but this concerns me.
As I stated before:

I think a lot of my difficulty with this document comes from the fact
that I don't really understand the model from which you are working and
it isn't really well defined in the document.  Perhaps this will become
more clear as the discussion continues.

I apologize if I missed something in the volume of email I worked
through today, but I don't think that this issue has adequately been
addressed.  A short description of the trust model would help to clarify
many of the problems that people have been having.  I think that we all
have different implementations of this service in mind when commenting
on your protocol.

        Robert Zuccherato

>

Date:         Mon, 24 Nov 1997 15:44:16 -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
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]
Status:

At 12:08 PM 11/24/97 -0500, you wrote:
>Bill,
>
>       Non-repudiation is a well-defined service that requires more than a
>digital signature, as noted by others.  One can use a digital signature for
>authentication applications where there is explicitly no intent that the
>result be non-repudiable.  At least in part, motivation for being able to
>declare a key NOT ot be used for non-repudiation purposes, is because some
>authentication protocols can produce results that might be used to support
>a non-repudiation claim, when it was not the intent of the key holder to do
>so.  We can minimize these problems through more careful design of
>authentication and integrity protocols, but using this flag to make an
>explciit statement also is an appropriate measure.
>
>Steve
>
>
>

Steve,

Going back to the old ISO 7498-2 document, which I take to have the
official definition of non-repudiation, non-repudiation is a service and
digital signature is a mechanism.  So everything else in the key usage list
is a mechanism, or a mechanism restricted to use with a particular very
specific PKI data object (e.g., signature for certificates), but
non-repudiation is a broad service.

It seems to me that this non-repudiation orange in the barrel of mechanism
apples is quite evidently causing a lot of confusion.  So, if we take Dave
Kemp's proposal, which is logically consistent, and consistent with X.509,
then it means that a certificate with only the digitalSignature bit set may
be used to sign anything except:

1. a Certificate
2. a CRL
3. anything, whatever it is, that is to have the peculiar property of
non-repudiation.

Given all this, it isn't clear to me what if a message signed with a key
with only digitalSignature set means, and if I should reject the signature,
or if the signer could then more or less automatically get away with
repudiating it.  I suppose that some folks may see this a great way for PKI
priests and wizards to  make some money as expert witnesses testifying to
the accepted or true meaning of nonRepudiation.

It would, in my view, be simpler and more logical if we had separate fields
for the cryptographic mechanisms (digital signature, encypherment, key
agreement) associated with the key and the kinds of objects against which
it could be implied (for signatures: certificates, CRLs, possibly
certificate status reports, or any other data object.  For encypherment:
keys, or any other data), and steer clear of services altogether.  But, if
we try to fix everything that is confusing with X.509 we'll be at it forever.

So my proposal is to treat digitalSignature and nonRepudiation as a single
bit and refer only to a mechanism, unconfused with a service.  This whole
thing (i.e, x.509 ane PKIX) is already too complicated and too confusing.

Regards,

Bill Burr

Date:         Mon, 24 Nov 1997 12:18:10 -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 M. Mulrooney" <[email-masked]>
Subject:      [IETF-PKIX] Admin - subscription options
Comments: To: [email-masked]
To: [email-masked]
Status:

Folks,

The TIP and ITEF-PKIX lists are now available in once-a-day digest
format.  To query your subscription options, send a message to:

    [email-masked]

In the body of the message, enter the line:

    query <list-name>

replacing <list-name> with TIP or IETF-PKIX.

To change one of the subscription options, send a message to:

    [email-masked]

In the body of the message, enter the line:

    set <list-name> <option>

replacing <list-name> with TIP or IETF-PKIX and <option> with
the option you are changing.

For example, to change your TIP subscription to digest, the
format would be:

    set TIP DIGEST

To return to individual messages, the format would be:

    set TIP NODIGEST

Full documentation on other options and commands can be found at:

http://www.l-soft.com/manuals/userindex.html

Postmaster
Tandem Computers

----- End Included Message -----

Date:         Mon, 24 Nov 1997 13:13: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-05.txt
To: [email-masked]
Status:

While we were all focused on profiling the protocol as our first
priority, yes there was some consideration and some discussion of the
potential need to define some schema elements (at least among the
authors of operational protocol PKIX drafts). I do plan to initiate an
activity in this area and expect some of the other PKIX operational
protocol authors are also planning to be involved in that work,  but I'm
not sure where this would fit in the IETF (under security as part of
PKIX or under applications where other schema work is done).

Steve/Warwick, should this be an agenda item in December?

In the earlier discussions that I mentioned,  I believe there was
agreement that if schema work was done, it should be confined to only
the absolute minimal set of requirements for PKIX. This would enable
those elements of schema to be included in the overall schema definition
of a directory As directories  are typically deployed to satisfy
requirements of a number of applications and not just PKI, we need to be
careful not to overspecify the requirements and impose unnecessary
restrictions on directory deployments but enable the PKIX elements to
dovetail into general purpose directories as well as directories that
are only used for PKIX.

Thoughts?

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

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

>----------
>From:  Salter, Thomas A[SMTP:[email-masked]]
>Sent:  November 20, 1997 12:20 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-05.txt
>
>I don't subscsribe to this list, so pardon me if I'm reopening an old
>issue here.
>
>Have you considered also defining the schema elements required to
>support PKI?  In particular what attributes and syntaxes are required
>and in what entry classes?  Some of these, such as userCerticate, are
>defined in the Ldap V3 drafts, but are not explicitly mentioned in the
>V2 standards, where they are presumed to be inherited from the x.500
>standards.
>
>It would also be helpful to define which attributes can be used to
>search filters, since x.500 based implementations will require matching
>rules for any attributes which are used for searches.
>

Date:         Mon, 24 Nov 1997 12:59:01 -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] Key Usage Profile
Comments: To: Dave Kemp <[email-masked]>
To: [email-masked]
Status:

Dave K.,

Is it your opinion that the nonRepudiation and digitalSignature bits
should be mutually exclusive (i.e., if one is set in a certificate then
the other cannot bet set)?

Also, if nonRepudiation is set, but digitalSignature is not, then can
the certificate be used "to provide the security service of entity
authentication, where the digital signature us used during a protocol
exchange, but not computed over application data"? (quote lifted from
your digSig definition)

Dave Simonetti

Date:         Mon, 24 Nov 1997 12:08: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: Bill Burr <[email-masked]>
To: [email-masked]
Status:

Bill,

        Non-repudiation is a well-defined service that requires more than a
digital signature, as noted by others.  One can use a digital signature for
authentication applications where there is explicitly no intent that the
result be non-repudiable.  At least in part, motivation for being able to
declare a key NOT ot be used for non-repudiation purposes, is because some
authentication protocols can produce results that might be used to support
a non-repudiation claim, when it was not the intent of the key holder to do
so.  We can minimize these problems through more careful design of
authentication and integrity protocols, but using this flag to make an
explciit statement also is an appropriate measure.

Steve

Date:         Mon, 24 Nov 1997 12:17: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

> From: Bill Burr <[email-masked]>
>
> The idea of an explicitly repudiable digital signature is repugnant.  So,
> if setting the digitalDignature bit while not setting the nonRepudiation
> bit means, in effect, "I reserve the right to deny I ever signed this," I
> think I'd like to see that combination banned.

Yes it's repugnant, but no, that's not at all what the DS and NR bits mean.

> If I have such a
> certificate, can I use it to authenticate myself to log onto a system, do
> some mischief, then repudiate that I ever logged on?

It might provide non-repudiable proof that you established a connection
to a system.

But beyond the initial establishment of the connection, there is no
technically non-repudiable proof that you typed any of the mischief-causing
commands.  Because the connection is protected by symmetric keys which,
by definition, must be shared, there is no cryptographic proof that the
subject commands were not typed by, for example, a malicious sysadmin.

This is the big difference between LDAP over SSL, and LDAP with signed
transactions.  Both provide authentication, but only one provides
technical non-repudiation.  (Whether technical NR of LDAP transactions
is or is not needed for audit purposes is a different subject.)

Date:         Mon, 24 Nov 1997 11:54: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] Key Usage Profile
To: [email-masked]
Status:

> From: Bob Jueneman <[email-masked]>
>
> David,, Steve, Denis, and others,
>
> Just to test my understanding of this, if I have a certificate which
> includes the nonRepudiation key usage, I would be ill-advised to use it to
> sign a email message containing a draft contract if I am not prepared to be
> legally bound by it, or unless I needed to be able to substantiate my good
> faith in negotiations, and the drraft was clearly labelled as such. Correct?

That might be a reasonable interpretation, but I don't think that's what
most CAs have in mind when they set the nonRepudiation bit.  Generally
that bit is set for "signing email", regardless of whether the contents
of the email is a draft contract, a real contract, a love letter containing
sweet nothings, or a marriage proposal, or whatever.

This discussion has had the beneficial effect of airing a lot of different
interpretations, many of which are really getting down into the weeds.
My opinion is that the PKIX specification should be unambiguous in areas
which are technically unambiguous, and tread very lightly, if at all, into
the domain of lawyers and policymakers.

There is a big distinction between "technical non-repudiation",
which is merely the cryptographic act of permanently affixing a digital
signature to a piece of data, and "legal non-repudiation", which
involves matters such as the content being signed, the intent of the
signer, the degree of assurance that the signer saw what he thought was
being signed, the degree to which the signer's private key has been
protected, the evidence maintained about the historical validity of a
certification path, yadda yadda yadda.

As far as I know, there are just two distinct technical purposes or
applications of the digital signature cryptographic mechanism:
signing data (permanently attaching a signature to it), and authenticating
a the parties to a communication channel (where the data travelling
through the channel is not itself digitally signed).

Other broad purposes of public key cryptographic mechanisms are
encrypting data, and establishing symmetric keys which could be used
for encryption and/or integrity protection.

Everyone seems to agree that there is a simple, easily understood
distinction to be made between "signing" data and "encrypting" data
or keys.  I don't know why making a similarly simple technical distinction
between "signing" data and "authenticating" a connection using digital
signatures is causing so much angst.

To reiterate previous messages, I believe the X.509 keyUsage bits
should be interpreted exclusively to mean technical usages.  They
should NOT mean security services, as Dave Simonetti suggests, and they
should NOT attempt to make policy or legal distinctions, as in the
questions asked by Bob.  Distinguishing between signed draft contracts
and signed real contracts should be addressed by extendedKeyUsage OIDs,
if the distinction is-to-be / can-be made by PKIX/X.509 at all.  My
opinion is that the distinction can be made only at the application
layer, as by having the word "DRAFT" in big grey capital letters
diagonally across the page, and included in the signature calculation.

The signature-related keyUsage bits should mean:

f), g) - keyCertSign and crlSign (let's not capitalize it cRLSign, OK?,
  and while we're at it, can the former be changed to just certSign?)
  The key is used to verify the digital signature on a certificate
  or CRL.  It says nothing about the "meaning" of certification by
  an authority, the meaning of "identity", the "validity" of the signed
  cert/CRL, or any of 1000 other questions which have been or could be
  asked about the public key certification process.
  If you've got a signed cert or CRL, and you've got an issuer cert
  with these bits set, then you can use the public key in the issuer
  cert to cryptographically verify the digital signature on the
  subject cert/CRL.  Period.

b) - nonRepudiation.  If you have a piece of user/application data,
  other than a cert or a CRL, which has been digitally signed then you
  can use a public key with this keyUsage bit set to cryptographically
  verify the signature.  It goes without saying that the cryptographic
  process of verifying a signature provides the security services of
  technical non-repudiation, data origin authentication, and data
  integrity.  This bit should say nothing about the user's intent to be
  bound by anything, it should say merely that the cryptographic
  mechanism was authorized to be applied to the user's data.

a) - digitalSignature.  This bit authorizes a public key to be used
  to verify a cryptographic digital signature used for some purpose
  other than *and not including* purposes b, f, and g.  As mentioned above,
  the only such purpose I am aware of is to provide the security service
  of entity authentication, where the digital signature is used during
  a protocol exchange, but not computed over application data.  I agree
  that this bit (bit 0) would be better named "authentication", or perhaps
  "otherSignature" to emphasize the fact that this bit includes all
  signature-related purposes except b, f, and g.

>
> And likewise, if I have a certificate which includes the nonRepudiation bit,
> I would be ill-advised to use that certificate to authenticate an SSL
> session, unless I was prepared to be legally bound by the contents
> transmitted over that session?

Peter likes to argue that you might have technically non-repudiable proof
that a connection was established, but the MAC and encryption used in SSL
do not provide technical non-repudiation over the user's data.  Lawyers
can argue over whether a mechanism that does not provide cryptographic
non-repudiation can legally bind anyone; if called as an expert witness,
I'd advise that there is no technical reason to believe that the purported
signer, and not the recipient, generated any data attributed to the signer.

> On the other hand, if I receive a payment order which only has the
> digitalSignature bit set, and not the NonRepudiation bit, I should assume
> that the information was provided FYI, but I shouldn't bet the ranch on it?

Under the above keyUsage rules, you aren't authorized to verify the
signature at all if the NR bit isn't set.  Of course you could use the
public key to prove that a cryptographically valid signature exists,
just as you could technically use an RSA signature key to decrypt
data.  But such usage isn't authorized by the CA.

> And what do we make of a digital signature which is verified by a
> certificate which has neither of the bits set?

If the keyUsage extension is present, assume that the certified keypair
isn't valid for either signing data or authenticating a connection.

> I think the attorneys and business practice people will follow whatever
> course we chart here, but we should be careful what we ask for.  Semantics
> are important!

That's why we should say what we know for sure, and keep silent about
the rest.  (Or at least ensure that editorializing and speculative
statements are clearly labeled as such, and not included in the
normative text of the standard.)

Date:         Mon, 24 Nov 1997 17:54:20 -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] OCSP and nonrepudiation -- a modest proposal
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob,

You wrote:

" If a certificate was still valid at the time a digital signature was
received, it was obviously valid at the time the transaction was signed,
and so the precise time at which the event occurred is irrelevant, at
least for puposes of (technical) nonrepudiation."

Yes, (unless it was on hold ) but the reverse is not true, i.e. if a
certificate was not valid at the time a digital signature was checked,
its validity cannot be determined at the time the transaction was
signed  ... unless the precise time at which the event occurred is
known.

You also wrote:

"On the other hand, having the CA (...) bind that certificate status to
a digital signature to confirm that at least the lowest certificate was
valid as of the time the digital signature in question was RECEIVED,
would be very reasonable (...)."

This is useful if you consider a real-time transaction but not useful if
you consider non-repudiation. In the case of non-repudiation, it is
important to confirm that at least the lowest certificate was valid as
of the time the digital signature in question was GENERATED.

So you cannot say that "the precise time at which the event occurred is
irrelevant".

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, 24 Nov 1997 11: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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

It seems to me that these two bits are trying to split much too fine a
hair.  The best solution would be to eliminate one or the other.  I wasn't
a participant in the discussions that led to the inclusion of both in the
Key Usage field, and have no real idea what was on the participants mind in
making this distinction, but there doesn't seem to be any real agreement
about just what non-repudiation actually means.

I would say that non-repudiation is, or ought to be, a property, rather
than a service or a usage, which any digital signature ought to be designed
to have, to as high a degree as practical, and which is greatly affected by
other circumstances of the signature (e.g., date-time stamps, or whether a
gun was pointed at the head of the signatory when he executed the signature).

The idea of an explicitly repudiable digital signature is repugnant.  So,
if setting the digitalDignature bit while not setting the nonRepudiation
bit means, in effect, "I reserve the right to deny I ever signed this," I
think I'd like to see that combination banned. If I have such a
certificate, can I use it to authenticate myself to log onto a system, do
some mischief, then repudiate that I ever logged on?

If the point of the nonRepudiation bit is just to say this is a bit
stronger kind of a key or signature, then I that may be OK, but
certificatPolicies, if you believe in them, may be a better way to express
this.  At any rate, if this is the case, setting nonRepudiation while
leaving digitalSignature unset, makes no sense.

I'm afraid that what we have here is another example of the kind of a camel
that we often get from a standards committee, which designs in the abstract
for the ages, and supplies answers for questions that haven't been and
don't need to be asked.  I'd prefer to see one of the bits eliminated
altogether. Failing that, I'd like to profile both bits as either set or
not set together, but never just one or the other.

At 04:26 PM 11/22/97 -0700, you wrote:
>I agree in setting both if the CA issuing the cert is issuing it for more
>than just I&A, as would/should most commercial CAs such as banks or
>merchants.
>
>I also believe that, because the options are in the extension, a lawyer
>could argue against non-repudiation if it is not set, even though the
>re;liant party knows who signed something and that what was signed has not
>been altered since signing.
>
>If someone were contesting (attempting to repudiate) a signed agreement
>because non-repudiation was not set, then that would probably go in front of
>a court fro final arbitration.  If they both were set, then that reason is
>at least eliminated.
>
>michael
>
>
>-----Original Message-----
>From: Simonetti David <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Monday, November 17, 1997 1:45 PM
>Subject: digitalSignature vs. nonRepudiation
>
>
>>I am attempting to implement the key usages as defined for the keyUsage
>>extension.  I am stumbling upon digitalSignature and nonRepudiation.
>>
>>I define the key usage digitalSignature as a public key which affords
>>the services of authentication and data integrity.
>>
>>Of course, nonRepudiation affords the service of non-repudiation.
>>
>>My question is, with only nonRepudiation set (and not digitalSignature),
>>is it true that my public key can be used only to provide the service of
>>non-repudiation, and NOT the services of authentication and data
>>integrity?  If this is true, I'm curious to know how this is
>>implemented.
>>
>>I claim that if the nonRepudiation bit is set, that I can use that key
>>to implement authentication and data integrity, and also claim
>>nonRepudiation of the originator.  Since authentication and data
>>integrity are services provided under digitalSignature, I believe that
>>when nonRepudiation is set, digitalSignature should also be set.
>>
>>I'd like to hear agreements or disagreements with my line of reasoning.
>>
>>Dave Simonetti
>>
>>
>
>
Regards,

Bill Burr

Date:         Mon, 24 Nov 1997 08:12: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

OFF LIST

Please remove my address from ALL mailings.

------------------
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:  November 20, 1997 9:37 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] P R E S S     R E L E A S E
>
>P R E S S    R E L E A S E         11:27 AM   11/20/97
>=====================
>
>If you want to be taken off this e-mailing list please reply with OFF LIST.
>No more email will be sent
>to you again from this address. Your email address was extracted from the WEB
>using Email
>Extractor Pro. This mailing list was targeted at a specifice audience. If you
>feel you received this
>email in error please accept our apologies. The creator of this list is
>against spamming. If you feel
>you were spammed please contact [email-masked] to be removed from all
>future mailings
>
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
>\/\/\/\/\/\/\/
>
>DirectED - The New Way to Learn!
>
>DirectED, Canada's Internet based International Correspondence School, has
>opened its doors.
>
>Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit
>the campus
>business office for complete details. What you get when you enroll in a
>DirectED program:
>
>      ACER Pentium 200 MMX Computer
>      LexMark Color Printer
>      Prepaid Internet account for 1 Year (60 hours per month)
>      Complete set of books
>      Software
>      CD Rom Tutorials
>      Toll Free Support
>      Full access to our Virtual Campus
>      An accredited diploma upon completion of the program
>
>Learn in the comfort of your own home at your own pace. It's the New Way To
>Learn!
>
>If you want to learn more please visit our web site at
>
>                  http://WWW.DIRECTED.EDU
>
>or call
>
>                  1-888-GO-4-SUCCESS
>                  1-888-464-7822
>
>or email
>
>                   [email-masked]
>
>We would really appreciate it if you would create a link to our web page so
>we can return the favor.
>If your site has an educational section please feel free to add us to your
>list.
>
>
>Any other questions or concerns can be directed to [email-masked]
>

Date:         Sun, 23 Nov 1997 23:45: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: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP Questions
To: [email-masked]
Status:

Carlisle,

Any pre-production that occurs should be directly synchronized to the OCSP
response validity interval.  Otherwise one could arrive at the situation
your example notes.  I've updated the OCSP draft accordingly.

Mike

At 01:21 PM 11/20/97 -0500, Carlisle Adams wrote:
>Hi Mike,
>
>I assume you meant this to go to the list (since you addressed it to
>"All" and referred to me and to Ambarish in third person), so I'm
>responding to the list...
>
>>----------
>>From:  [email-masked][SMTP:[email-masked]]
>>Sent:  Thursday, November 20, 1997 10:43 AM
>>To:    Carlisle Adams
>>Subject:       RE: OCSP Questions
>>
>>All,
>>
>>When an OCSP request cannot be satisfied, a signed NO_SERVICE response is
>>produced.  However, as pointed out by Carlisle and Ambarish, malicious
>>parties could replay this message against requests that might otherwise
>>generate a valid response.
>
>This is not the full extent of the replay attack.  Let's say that the CA
>generates a new batch of signed responses every half hour (i.e., the
>caching period is 30 minutes).  In order to provide up-to-the-minute
>revocation information, however, it will replace a signed "Good"
>response with a signed "Bad" response as soon as a revocation has
>occurred.
>
>Now, the update occurs at 10:30 and at 10:35 Joe's certificate is
>revoked (at Joe's request, let's say, claiming key compromise).  All Joe
>has to do to repudiate a transaction is to make an OCSP request at
>10:34, get back a valid "Good" response, make another OCSP response at
>10:36, get back a valid "Bad" response, and replay the "Good" response
>(i.e., pretending to be the OCSP responder) any time someone else makes
>an OCSP request about his certificate between 10:36 and 11:00 (when the
>next update will occur).  Susan, who checks Joe's certificate at 10:45
>and thinks it's good, accepts some transaction.  Joe later successfully
>repudiates that transaction by producing a valid OCSP response showing
>that his certificate was bad at 10:36.
>
>This is just an example, but it illustrates that caching does not allow
>the OCSP protocol to achieve what it aims to achieve (i.e., timely
>certificate status information) because it opens the door for replay
>attacks.
>
>>A common approach towards mitigating the effects of this attack is through
>>a cryptographic binding of requests to responses.  This however precludes
>>pre-signing and caching behaviors.  (I would note that any other such
>>protocol would suffer the same negative effects on their scalability).
>
>Cryptographically binding requests and responses does not "mitigate
>(i.e., lessen, decrease, ease, lighten) the effects of this attack"; it
>effectively removes the possibility of this attack (assuming strong
>cryptographic algorithms).  This is a significant difference, so it
>should be made clear.  Yes, it does preclude pre-signing and caching
>behaviors  --  proper security always costs something.
>
>As for your note ("any other such protocol would suffer the same
>negative effects on their scalability"), this is not quite true.  The
>critical difference is the model of the world embedded in the protocol.
>On the one hand, if the protocol assumes one CA (or a small number of
>CAs) and OCSP responders that represent a particular CA, then not
>allowing caching severely limits scalability.  On the other hand, if the
>protocol assumes any number of CAs and OCSP responders that are
>essentially independent of CAs (i.e., trusted verifiers), then not
>allowing caching has no effect on scalability (since each OCSP responder
>services only a portion of the community that it can actually handle).
>
>Again, there is a price (for example, requests need to include trust
>conditions, and OCSP responders need their own certificates).  But if a
>secure, scaleable protocol is desired (which seems reasonable, since
>this is the IPKI), it seems that we need to pursue the second model...
>
>>The timestamp in the OCSP response is the time at which the response was
>>signed.  Mapping one-to-one to CRLs, this corresponds to the thisUpdate
>>field in a CRL.  I propose to correspondingly include a nextUpdate field in
>>the response.  Applications SHOULD reject any response where nextUpdate is
>>earlier than their current system time.  In the limit, if thisUpdate equals
>>nextUpdate, this reduces to a dynamic refresh model.  This will give system
>>integrators the ability to tune OCSP behavior in accordance with local
>>security policy.
>
>This is certainly better.  Having thisUpdate AND nextUpdate allows users
>to know when the caching period ends (i.e., when the next update will
>occur) and so avoids replay attacks (except for the NO_SERVICE replay,
>as mentioned above).  But now the protocol seems to provide little value
>over CRLs (which, of course, can be produced with the same frequency as
>this caching period, if desired).  Perhaps the main advantage of this
>variation of OCSP over CRLs is the reduced bandwidth of the response,
>but distribution points can be used to reduce CRL bandwidth requirements
>if this is a problem.
>
>Note that if the difference between thisUpdate and nextUpdate is small
>then the scalability problem has not really been solved.  On the other
>hand, if it is larger so that the system can scale, then users are not
>really getting timely revocation information (which is what they were
>hoping to get by using OCSP).
>
>I guess I'm still of the opinion that we need to bind requests to
>responses, and use trusted verifiers, if we hope to do on-line
>certificate status checks properly.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>

Date:         Sun, 23 Nov 1997 23:24:36 -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 D. Ellner" <[email-masked]>
Subject:      [IETF-PKIX] Sorry to bother everybody...
To: [email-masked]
Status:

I am going on vacation and need to stop subscribing to this list.
Unfortunately, I lost the file with directions on how to do this.
Could some kind soul please send me directions for signing off?

Thanks,
Todd Ellner

Date:         Mon, 24 Nov 1997 17:12:51 +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:      [IETF-PKIX] More asn1 bugs in Certificate and CRL profile
To: [email-masked]
Status:

Policy Constraints is =>

PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
  requireExplicitPolicy         [0] SkipCerts OPTIONAL,
  inhibitPolicyMapping          [1] SkipCerts OPTIONAL
}

it should be =>

PolicyConstraints ::= SEQUENCE {
  requireExplicitPolicy         [0] SkipCerts OPTIONAL,
  inhibitPolicyMapping          [1] SkipCerts OPTIONAL
}

The 1994 ASN.1 is also incorrect.

Cheers.

--
+----------------------------------------+-------------------------------+
| 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:         Sat, 22 Nov 1997 19:02:52 -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: D26NM057/26/M/IBM <[email-masked]>
Subject:      [IETF-PKIX] Ivan Milman/Austin/IBM is out of the office.
To: [email-masked]
Status:

I am out of the office from 11/22/97, returning 12/01/97.  You will receive
only this notification of my absence prior to my return, at which time I will
respond.
I am out of the office from 21 November 1997, returning on 1 December 1997.

Date:         Sat, 22 Nov 1997 16:26:55 -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] digitalSignature vs. nonRepudiation
Comments: To: Simonetti David <[email-masked]>
Comments: cc: [email-masked], [email-masked]
To: [email-masked]
Status:

I agree in setting both if the CA issuing the cert is issuing it for more
than just I&A, as would/should most commercial CAs such as banks or
merchants.

I also believe that, because the options are in the extension, a lawyer
could argue against non-repudiation if it is not set, even though the
re;liant party knows who signed something and that what was signed has not
been altered since signing.

If someone were contesting (attempting to repudiate) a signed agreement
because non-repudiation was not set, then that would probably go in front of
a court fro final arbitration.  If they both were set, then that reason is
at least eliminated.

michael

-----Original Message-----
From: Simonetti David <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, November 17, 1997 1:45 PM
Subject: digitalSignature vs. nonRepudiation

>I am attempting to implement the key usages as defined for the keyUsage
>extension.  I am stumbling upon digitalSignature and nonRepudiation.
>
>I define the key usage digitalSignature as a public key which affords
>the services of authentication and data integrity.
>
>Of course, nonRepudiation affords the service of non-repudiation.
>
>My question is, with only nonRepudiation set (and not digitalSignature),
>is it true that my public key can be used only to provide the service of
>non-repudiation, and NOT the services of authentication and data
>integrity?  If this is true, I'm curious to know how this is
>implemented.
>
>I claim that if the nonRepudiation bit is set, that I can use that key
>to implement authentication and data integrity, and also claim
>nonRepudiation of the originator.  Since authentication and data
>integrity are services provided under digitalSignature, I believe that
>when nonRepudiation is set, digitalSignature should also be set.
>
>I'd like to hear agreements or disagreements with my line of reasoning.
>
>Dave Simonetti
>
>

Date:         Fri, 21 Nov 1997 18:18: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: [email-masked]
Subject:      [IETF-PKIX] 7/10 draft update
To: [email-masked]
Status:

For the information of PKIX and SMIME WG members, we have just posted the
following draft to the I-D directories: Certificate Request Syntax
<draft-ietf-smime-crs-00.txt>.  This draft represents the latest
progression of the work on PKCS#7/#10-based adaptation of PKIX-CMP, in
accordance with agreements reached at the Munich PKIX meeting.

Following the recent establishment of the SMIME WG, various people have
suggested that this work might now be better carried out in that new group,
i.e., the group responsible for the IETF standardization of PKCS#7.  While
such a move has not yet been endorsed by the Security Area Director, this
appears to the authors to be the most appropriate WG due to the use of
PKCS#7 in the CRS draft.  Accordingly, the I-D has, with the agreement of
the SMIME WG Chair, been identified as a SMIME WG draft.

We do wish to point out however that the draft could be well served by
either the PKIX or SMIME WGs.  The ultimate forum for the draft is far less
important than in carrying forward on the agreements reached at the Munich
PKIX WG meeting.

Michael Myers (on behalf of the CRS I-D authors)

Date:         Fri, 21 Nov 1997 17:36:45 -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:      [IETF-PKIX] Revised OCSP Draft
To: [email-masked]
Status:

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.

I left the abstraction of the trust model as it stands, although there's
some need for refinement to further reduce complexity in the non-CA trust
model.

Date:         Fri, 21 Nov 1997 15:58: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage Profile
Comments: To: Bob Jueneman <[email-masked]>
Comments: cc: [email-masked]
To: [email-masked]
Status:

Bob,

As you've brought forth the legal implications of claiming non-repudiation
during signature, I'd also recommend checking the integrity of each object that
is signed with non-repudiation.  Hence, I'm going to want (need)
digitalSignature to be a valid key usage as well.

Also, I wouldn't expect to limit the use of a public key certificate based
solely on the key usage bits.  Just because nonRepudiation isn't set in my
certificate doesn't mean that my system does not provide non-repudiation.  It is
possible to deal with such an issue within the certificate policy of the
community (e.g., SET).  I've seen nothing in a PKIX document that restricts me
from doing such.

Finally, the processing of the extensions is still a certificate policy issue.
There will be (and are) communities that require specific extensions, as well as
specific key usages, to appear in a certificate.

Dave Simonetti

Bob Jueneman wrote:

> David,, Steve, Denis, and others,
>
> Just to test my understanding of this, if I have a certificate which
> includes the nonRepudiation key usage, I would be ill-advised to use it to
> sign a email message containing a draft contract if I am not prepared to be
> legally bound by it, or unless I needed to be able to substantiate my good
> faith in negotiations, and the drraft was clearly labelled as such. Correct?
>
> And likewise, if I have a certificate which includes the nonRepudiation bit,
> I would be ill-advised to use that certificate to authenticate an SSL
> session, unless I was prepared to be legally bound by the contents
> transmitted over that session?
>
> On the other hand, if I receive a payment order which only has the
> digitalSignature bit set, and not the NonRepudiation bit, I should assume
> that the information was provided FYI, but I shouldn't bet the ranch on it?
>
> And what do we make of a digital signature which is verified by a
> certificate which has neither of the bits set?
>
> I think the attorneys and business practice people will follow whatever
> course we chart here, but we should be careful what we ask for.  Semantics
> are important!
>
> 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."
>
> >>> "Simonetti David" <[email-masked]> 11/21 2:22 PM >>>
> All,
>
> For those following the key usage profiling issue, I still can't say
> that I'm convinced that nonRepudiation will be exclusive of
> digitalSignature signature in practice, but I respect the opinions that
> I have received.
>
> I recommend that the key usages be profiled in some manner similar to
> the following:
>
> "CAs shall:
>
> Set digitalSignature when the security services of authentication and
> data integrity are to be applied to the validation of a signed object;
>
> Set nonRepudiation when the security service of non-repudiation is to be
> applied to the signed object;
>
> Set both digitalSignature and nonRepudiation when all of the security
> services of authentication, data integrity, and non-repudiation apply to
> the signed object."
>
> If I hear no objections, I will go forth with this.
>
> Dave S.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Date:         Fri, 21 Nov 1997 11:52: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] Key Usage Profile
Comments: To: [email-masked], [email-masked]
To: [email-masked]
Status:

David,, Steve, Denis, and others,

Just to test my understanding of this, if I have a certificate which
includes the nonRepudiation key usage, I would be ill-advised to use it to
sign a email message containing a draft contract if I am not prepared to be
legally bound by it, or unless I needed to be able to substantiate my good
faith in negotiations, and the drraft was clearly labelled as such. Correct?

And likewise, if I have a certificate which includes the nonRepudiation bit,
I would be ill-advised to use that certificate to authenticate an SSL
session, unless I was prepared to be legally bound by the contents
transmitted over that session?

On the other hand, if I receive a payment order which only has the
digitalSignature bit set, and not the NonRepudiation bit, I should assume
that the information was provided FYI, but I shouldn't bet the ranch on it?

And what do we make of a digital signature which is verified by a
certificate which has neither of the bits set?

I think the attorneys and business practice people will follow whatever
course we chart here, but we should be careful what we ask for.  Semantics
are important!

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."

>>> "Simonetti David" <[email-masked]> 11/21 2:22 PM >>>
All,

For those following the key usage profiling issue, I still can't say
that I'm convinced that nonRepudiation will be exclusive of
digitalSignature signature in practice, but I respect the opinions that
I have received.

I recommend that the key usages be profiled in some manner similar to
the following:

"CAs shall:

Set digitalSignature when the security services of authentication and
data integrity are to be applied to the validation of a signed object;

Set nonRepudiation when the security service of non-repudiation is to be
applied to the signed object;

Set both digitalSignature and nonRepudiation when all of the security
services of authentication, data integrity, and non-repudiation apply to
the signed object."

If I hear no objections, I will go forth with this.

Dave S.

Date:         Fri, 21 Nov 1997 11:37:01 -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 and nonrepudiation -- a modest proposal
Comments: To: [email-masked]
To: [email-masked]
Status:

>>> Carlisle Adams <[email-masked]> 11/20 3:33 PM >>>
>Hi Bob,
>
>One small point:
>

>>
>>If a certificate was still valid at the time a digital signature was
>>received, it was obviously valid at the time the transaction was signed,
and
>>so the precise time at which that occurred is irrelevant, at least for
>>purposes of (technical) nonrepudiation.
>
>Not quite true.  The document could conceivably have been signed prior
>to the certificate being valid (e.g., before the public key was actually
>certified, or while the certificate was "on hold" before becoming
>valid).
>
>Sometimes time is useful...
>
>Carlisle.

Very interesting point.  Let's examine what that really means in terms of
the validity of the signature, and nonrepudiation.

The ABA Digital Signature Guidelines talk about verifying a digital
signature "to determine accurately that the digital signature was created
during the operational period of a valid certificate by the private key
corresponding to the public key listed in the certificate..."

"The operational period or a certificate begins on the date and time it was
issued by a certification authority (or on a later date and time certain if
stated in the certificate), and ends on the date and time it expires or is
earlier revoked or suspended."

Let's deal with the "on hold" or "pending" issue first. In this case the
certificate and the keys are presumably valid, but the subscriber has not
yet confirmed acceptance of the certificate. Once she does so, the
certificate would be removed from the pending state, and would not appear in
a CRL.

What should that imply with respect to the bona fide use of that certificate
by the subscriber? I would claim that if the certificate is accepted and
removed from the pending state by the CA, then it is completely bona fide,
and any signatures validated within the operational period are also bona
fide.  In this respect it is exactly like a certificate that is suspended --
it certainly raises a question during the period of suspension, but after
the suspension is removed no  cloud of doubt should remain -- otherwise it
ought to be revoked.

But what happens if a digital signature was created prior to the effective
of the certificate?  And for that matter, what was the intent of having a
start date included in the certificate in the first place?

I believe that we have been through the issue of what the certificate
validity period means a number of times, but primarily focusing on the end
date.  The firm answer, I believe, is that the expiration date is the date
at which (or shortly thereafter) the CA is relieved of the obligation of
reporting certificate validity status via CRLs or other mechanisms.  It does
NOT necessarily mean that a digital signature is not legally binding if it
is used after that date, but it does mean that the relying party may have to
go to greater lengths to prove that the binding between the key and the
certificate attributes was still valid, and that the key had not been
compromised.

(We also have a private key validity period, which can be used to reflect
the subscriber's intent to zeroize his private key to protect it from
possible compromise after that date. Again, the fact that a digital
signature is created after the private key validity date has expired doesn't
ipso facto make it non-binding, but someone would have to be a fool to
accept a transaction signed after that date, at least without asking a lot
of questions.)

What does this tell us about the validity of a signature created with a
private key prior to the operational period commences?  Does it mean that
the subscriber can be completely cavalier with the security of the private
key, and only start to act responsibly once the operational period starts?
Clearly not -- the duty to protect the private key obviously begins with its
creation.

(In this case the Digital Signature Guidelines is clearly in error, for it
states in 4.3 Safeguarding the private key, "During the operational period
of a valid certificate, the subscriber shall not compromise the private key
corresponding to a public key listed in such certificate, and must also
avoid compromise during any period of suspension." Since there isn't any way
of uncompromising a private key, the subscriber clearly has the duty to
protect the key from its creation, regardless of  what dates are included in
the certificate.)

This responsibility becomes even clearer if the (generally deplorable)
practice of rolling over a key from one certificate to another is used.
Perhaps the key was originally a PGP key, and has now been endorsed by a CA.
Or perhaps someone changed their name or address, but didn't want to change
keys. Maybe the keys are embedded in a smart card, and would require issuing
a new smart card.

What does the validity period mean with respect to the CA's obligation to
post a CRL, if the operational period hasn't even begun yet?  If the
certificate has been created and issued to the user ahead of the operational
date, I would say that the CA probably has an obligation to revoke the
certificate and list it in the CRL if the key is compromised. The only
reason for issuing the certificate prior to the validity period is
presumably to facilitate uninterrupted operation when an old certificate is
about to expire.  Keys really shouldn't be rolled over, generally speaking,
and the keys listed in certificates ought not to be used prior to their
effective date, but if they are the CA is probably obligated to list them in
a CRL to avoid potential liability if some relying party is damaged. But I
suppose that the CA's contract and CPS might specify that it is only
obligated to report revocations during the operational validity period.

There are some interesting exceptions to this. Maybe a certificate
containing a role is issued to someone prior to the effective date, so that
the person can hit the ground running.  If someone uses that key/certificate
prior to the effective date, they don't yet have the authority that is
implied. From the point of view of the individual, that would be a rather
dangerous thing to do, for it would probably make him or her personally
liable for their actions, rather than the organization.  That could be a
problem for the relying party, and might be one of those instances where
synchronizing time with an external event might be meaningful. After the
certificate becomes valid, and the person does have the appropriate
authority, I think it would be hard to argue that the signature was not
binding, but that is an interesting legal issue I will raise with my
attorney friends.

Bottom line -- my opinion and belief is that a digital signature that is
validated during the operational validity period of a certificate is legally
binding and technically nonrepudiable, regardless of when the signature was
actually created, even if it was created prior to the validity period. I
believe that this may impose a duty on a CA to revoke a certificate if
circumstances change between the time that the certificate was created or
issued and its effective date.

But it certainly is an interesting point. Thanks for bringing it up.

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:         Fri, 21 Nov 1997 11:58:42 -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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Profiling Key Usage
Comments: To: Simonetti David <[email-masked]>
To: [email-masked]
Status:

Dave,

        I tend to agree with Dave Kemp and Denis, et al.  Digital Signature
is a mechanism, while non-repudiation and authentication/integrity are
services.  I can use a digital signature to support any of these services.
However, because marking a key as being used for NR purposes may suggest
some more legally binding use of the key, I would want to be able to keep
separate these distinct uses.  So, I'd rather not assume that asserting
non-repudiation implies use for authentication, even though one can argue
that the non-repudiation service is based on a combination of
authentication,  integrity and time stampimg.

STeve

Date:         Fri, 21 Nov 1997 15:58:44 +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:      Re: [IETF-PKIX] Objections to IPKI3CMP charset handling
Comments: To: [email-masked]
To: [email-masked]
Status:

[email-masked] said:
> But BMPString is immediately implementable and deployable. Type
> BMPString is unicode, which many vendors rely upon for national
> language support. It maps onto type UniversalString, a four bytes per
> character solution that has not been widely adopted.

Oops - I may have forgotten to mention this: UTF-8, which I suggest,
is *also* an encoding of 10646, and is specified in the Unicode standard
version 2.0 (appendix A.2). Unicode is a standard built upon 10646,
with certain added rules.

So UTF-8 versus BMPString is not a matter of whether or not you
dislike Unicode; either choice keeps Unicode support.

[email-masked] said:
> > I would suggest adding the following to the PKIHeader: >
> languages [9] SEQUENCE OF IA5String -- RFC 1766 language tags

> Hmmm. Wonder why they didn't use VisibleString here. It is the ASCII
> character set without the control characters. Is ESC-DEL a valid
> language tag?

It isn't "they", it's just "me"....we could go further and use
PrintableString, since it's limited to A-Z + dash. The more limited, the
merrier!
Thanks!

                       Harald A

Date:         Fri, 21 Nov 1997 08:53: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: "Dulude, Bob" <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

OFF LIST

  Bob

    Bob Dulude                                              {Note new
area code}
    GTE CyberTrust Solutions Inc.                 (781) 455-2623  Voice
    [email-masked]                        (781) 455-3105  Fax

> ----------
> From:         Brian M. Thomas[SMTP:[email-masked]]
> Sent:         Thursday, November 20, 1997 10:03 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
>
> OFF LIST
>
>
>
> > From [email-masked] Thu Nov 20 08:58 CST 1997
> > X-Authentication-Warning: swbcs003.sbc.com: uucp set sender to
> <[email-masked]> using -f
> > Date:         Thu, 20 Nov 1997 09:37:10 -0500
> > From: [email-masked]
> > Subject:      [IETF-PKIX] P R E S S     R E L E A S E
> > To: [email-masked]
> >
> > P R E S S    R E L E A S E         11:27 AM   11/20/97
> > =====================
> >
> > If you want to be taken off this e-mailing list please reply with
> OFF LIST. No more email will be sent
> > to you again from this address. Your email address was extracted
> from the WEB using Email
> > Extractor Pro. This mailing list was targeted at a specifice
> audience. If you feel you received this
> > email in error please accept our apologies. The creator of this list
> is against spamming. If you feel
> > you were spammed please contact [email-masked] to be removed
> from all future mailings
> >
> >
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> /\/\/\/\/\/\/\/\/\/\/
> >
> > DirectED - The New Way to Learn!
> >
> > DirectED, Canada's Internet based International Correspondence
> School, has opened its doors.
> >
> > Students can take courses at our virtual campus at WWW.DIRECTED.EDU.
> Visit the campus
> > business office for complete details. What you get when you enroll
> in a DirectED program:
> >
> >       ACER Pentium 200 MMX Computer
> >       LexMark Color Printer
> >       Prepaid Internet account for 1 Year (60 hours per month)
> >       Complete set of books
> >       Software
> >       CD Rom Tutorials
> >       Toll Free Support
> >       Full access to our Virtual Campus
> >       An accredited diploma upon completion of the program
> >
> > Learn in the comfort of your own home at your own pace. It's the New
> Way To Learn!
> >
> > If you want to learn more please visit our web site at
> >
> >                   http://WWW.DIRECTED.EDU
> >
> > or call
> >
> >                   1-888-GO-4-SUCCESS
> >                   1-888-464-7822
> >
> > or email
> >
> >                    [email-masked]
> >
> > We would really appreciate it if you would create a link to our web
> page so we can return the favor.
> > If your site has an educational section please feel free to add us
> to your list.
> >
> >
> > Any other questions or concerns can be directed to
> [email-masked]
>

Date:         Fri, 21 Nov 1997 07:37:19 -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] Objections to IPKI3CMP charset handling
To: [email-masked]
Status:

[email-masked] wrote:
>
> Hello,
> I see that the IPKI3CMP draft uses the following construct to send
> around text intended for human consumption:
>
>   PKIFreeText ::= CHOICE {
>       iA5String  [0] IA5String,
>       bMPString  [1] BMPString
>   } -- note that the text included here would ideally be in the
>     -- preferred language of the recipient

The tags are not necessary here, since both choice alternatives
are builtin types. So,

   PKIFreeText ::= CHOICE {
       iA5String  IA5String,
       bMPString  BMPString
   } -- note that the text included here would ideally be in the
     -- preferred language of the recipient

is all that is needed.

>
> BMPString is the UCS-2 encoding (16 bits per character) of the
> 16-bit subset of the ISO 10646 character set.
>
> This decision has some problems:
>
> 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.

But BMPString is immediately implementable and deployable. Type
BMPString is unicode, which many vendors rely upon for national
language support. It maps onto type UniversalString, a four bytes
per character solution that has not been widely adopted.

>
> 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)

But unicode is and has been the solution of choice for industry.

>
> 3) The use of CHOICE for this important construct makes "shorthand
>    implementation" handling only one branch of the CHOICE all too likely.

Hopefully this will change, but for some products marketed to
english speaking customers only, the complete ASCII set is easier
and less expensive to implement. IA5String contains all of the
ASCII characters, including the control characters. IA5String
maps to the first characters in BMPString.

>
> An alternative that I think would be better for all concerned would be
> to redefine this construct like this:
>
>    PKIString ::= OCTET STRING -- UTF-8 encoded text
>

An alternative might be to add UTF-8 to PKIFreeText

   PKIFreeText ::= CHOICE {
       ascii    IA5String,
       unicode  BMPString,
       utf-8    OCTET STRING
   } -- note that the text included here would ideally be in the
     -- preferred language of the recipient

to allow future support for additional languages. But note that
the suggestion to eliminate unicode support with an OCTET STRING
replacement has the 'advantage' of making the ASN.1 module X.208
compliant with very little effort. But is has the disadvantage
of loosing unicode support.

> (As far as I know, ASN.1 does not have an UNIVERSAL type for UTF-8;
> use of UniversalString would require inserting the appropriate escape
> sequence at the beginning of the string, not very attractive)
>
> This can even be made backwards-compatible with the previous version
> for all cases that conform to ASCII by a simple added tag:
>
>     PKIString ::= [0] OCTET STRING
>
> since all ASCII strings are, by design, valid UTF-8 strings.
>
> The IETF charset policy also strongly recommends adding language
> information where possible; I note that the document already has a
> note about this, but no support for it.
>
> I would suggest adding the following to the PKIHeader:
>
>    languages [9] SEQUENCE OF IA5String -- RFC 1766 language tags

Hmmm. Wonder why they didn't use VisibleString here. It is the
ASCII character set without the control characters. Is ESC-DEL
a valid language tag?

>
> and a Note at the end of section 3.1.1:
>
>   The language field may be used to indicate the languages used in
>   occurences of PKIString within this message. Its first element
>   indicates the desired language for replies.

Having a string of language preferences would be a great assist
feature for implementors. Right now, if you get a BMPString, you
still don't know if it contains text in Japanese or English.

>
> The reason for having > 1 fields is so that you don't have to lie when
> you send a message with "header.freeText" in Norwegian and
> "PKIStatusInfo.statusString" in English; the reason for overloading the meaning
> of the first component element is so that the normal case (I'm sending
> text in Norwegian and want replies back in Norwegian) is as simple as possible.
>
> There's a note in the charset policy document about default language;
> you may want to think about whether you want to reference that, too.
>
> NOTE: I regard the charset issue as a show-stopper that SHOULD be
> fixed before progressing the document; the language tagging function
> is more of a feature that I'd very much approve of.
>
> I hope this problem can be solved promptly, and apologize for not
> catching this at an earlier stage in your deliberations.
>
> Regards,
>
>                     Harald T. Alvestrand

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, 21 Nov 1997 06:36: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] PKIX ASN.1
To: [email-masked]
Status:

David P. Kemp wrote:
>
> > From: Bancroft Scott <[email-masked]>
> >
> > The fact that some tools are defective in their support for ASN.1 should
> > not be used as a reason for writing ASN.1 that properly conforming ASN.1
> > tools cannot support without making them defective.  This sort of thing
> > applies to all standards, not just ASN.1.  If X.208 is to be used, fine,
> > or if X.680 is to be used, fine; however, please don't write ASN.1-based
> > standards that is known to conform to neither.
>
> That is good advice.
>
> But the intent of Appendix A is to present the certificate syntax in
> a manner that is more accessible to many people than the syntax presented
> in Appendix B.
>
> Is it possible to write a conforming X.680 specification without using
> any of the features introduced in X.680 except for the two offending
> UNIVERSAL types.  I.e., if the definitions of UniversalString and BMPString
> were deleted, would Appendix A be a valid X.680 module?

David,

ANY DEFINED BYs would need to be replaced to have a valid X.680
module. But removal of the two string definitions would result in
a valid X.208 module.

The replacement for ANY DEFINED BY is illustrated on the OSS web
site, http://www.oss.com, under Resources, then Q&A, question number
six. The AlgorithmIdentifier type is discussed there, and the 1994
notation explained w.r.t. ANY DEFINED BY.

This is really the only 1994 topic that you'd need to understand in
detail to create a valid X.680 module. It's not that hard, really,
and it creates a binding between the OID and Type that is much
stronger and more specific than is possible using ANY DEFINED BY.

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, 21 Nov 1997 11:35:51 +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] Objections to IPKI3CMP charset handling
Comments: cc: [email-masked]
To: [email-masked]
Status:

Hello,
I see that the IPKI3CMP draft uses the following construct to send
around text intended for human consumption:

  PKIFreeText ::= CHOICE {
      iA5String  [0] IA5String,
      bMPString  [1] BMPString
  } -- note that the text included here would ideally be in the
    -- preferred language of the recipient

BMPString is the UCS-2 encoding (16 bits per character) of the
16-bit subset of the ISO 10646 character set.

This decision has some problems:

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.

An alternative that I think would be better for all concerned would be
to redefine this construct like this:

   PKIString ::= OCTET STRING -- UTF-8 encoded text

(As far as I know, ASN.1 does not have an UNIVERSAL type for UTF-8;
use of UniversalString would require inserting the appropriate escape
sequence at the beginning of the string, not very attractive)

This can even be made backwards-compatible with the previous version
for all cases that conform to ASCII by a simple added tag:

    PKIString ::= [0] OCTET STRING

since all ASCII strings are, by design, valid UTF-8 strings.

The IETF charset policy also strongly recommends adding language
information where possible; I note that the document already has a
note about this, but no support for it.

I would suggest adding the following to the PKIHeader:

   languages [9] SEQUENCE OF IA5String -- RFC 1766 language tags

and a Note at the end of section 3.1.1:

  The language field may be used to indicate the languages used in
  occurences of PKIString within this message. Its first element
  indicates the desired language for replies.

The reason for having > 1 fields is so that you don't have to lie when
you send a message with "header.freeText" in Norwegian and
"PKIStatusInfo.statusString" in English; the reason for overloading the meaning
of the first component element is so that the normal case (I'm sending
text in Norwegian and want replies back in Norwegian) is as simple as possible.

There's a note in the charset policy document about default language;
you may want to think about whether you want to reference that, too.

NOTE: I regard the charset issue as a show-stopper that SHOULD be
fixed before progressing the document; the language tagging function
is more of a feature that I'd very much approve of.

I hope this problem can be solved promptly, and apologize for not
catching this at an earlier stage in your deliberations.

Regards,

                    Harald T. Alvestrand

Date:         Thu, 20 Nov 1997 20:00:09 -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] OCSP Questions
To: [email-masked]
Status:

I'm sending this to you rather than the list just in case I'm ignoring
something incredibly obvious.

Wouldn't the replay attack be prevented by (a) including a trans_id
(i.e. a nonce, which I believe is still in the request) in the signature
computation and the result, and/or (b) not pre-computing responses?

Regards,
Rich
----------
> From: Carlisle Adams <[email-masked]>
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP Questions
> Date: Thursday, November 20, 1997 1:21 PM
>
> Hi Mike,
>
> I assume you meant this to go to the list (since you addressed it to
> "All" and referred to me and to Ambarish in third person), so I'm
> responding to the list...
>
> >----------
> >From:  [email-masked][SMTP:[email-masked]]
> >Sent:  Thursday, November 20, 1997 10:43 AM
> >To:    Carlisle Adams
> >Subject:       RE: OCSP Questions
> >
> >All,
> >
> >When an OCSP request cannot be satisfied, a signed NO_SERVICE response
is
> >produced.  However, as pointed out by Carlisle and Ambarish, malicious
> >parties could replay this message against requests that might otherwise
> >generate a valid response.
>
> This is not the full extent of the replay attack.  Let's say that the CA
> generates a new batch of signed responses every half hour (i.e., the
> caching period is 30 minutes).  In order to provide up-to-the-minute
> revocation information, however, it will replace a signed "Good"
> response with a signed "Bad" response as soon as a revocation has
> occurred.
>
> Now, the update occurs at 10:30 and at 10:35 Joe's certificate is
> revoked (at Joe's request, let's say, claiming key compromise).  All Joe
> has to do to repudiate a transaction is to make an OCSP request at
> 10:34, get back a valid "Good" response, make another OCSP response at
> 10:36, get back a valid "Bad" response, and replay the "Good" response
> (i.e., pretending to be the OCSP responder) any time someone else makes
> an OCSP request about his certificate between 10:36 and 11:00 (when the
> next update will occur).  Susan, who checks Joe's certificate at 10:45
> and thinks it's good, accepts some transaction.  Joe later successfully
> repudiates that transaction by producing a valid OCSP response showing
> that his certificate was bad at 10:36.
>
> This is just an example, but it illustrates that caching does not allow
> the OCSP protocol to achieve what it aims to achieve (i.e., timely
> certificate status information) because it opens the door for replay
> attacks.
>
> >A common approach towards mitigating the effects of this attack is
through
> >a cryptographic binding of requests to responses.  This however
precludes
> >pre-signing and caching behaviors.  (I would note that any other such
> >protocol would suffer the same negative effects on their scalability).
>
> Cryptographically binding requests and responses does not "mitigate
> (i.e., lessen, decrease, ease, lighten) the effects of this attack"; it
> effectively removes the possibility of this attack (assuming strong
> cryptographic algorithms).  This is a significant difference, so it
> should be made clear.  Yes, it does preclude pre-signing and caching
> behaviors  --  proper security always costs something.
>
> As for your note ("any other such protocol would suffer the same
> negative effects on their scalability"), this is not quite true.  The
> critical difference is the model of the world embedded in the protocol.
> On the one hand, if the protocol assumes one CA (or a small number of
> CAs) and OCSP responders that represent a particular CA, then not
> allowing caching severely limits scalability.  On the other hand, if the
> protocol assumes any number of CAs and OCSP responders that are
> essentially independent of CAs (i.e., trusted verifiers), then not
> allowing caching has no effect on scalability (since each OCSP responder
> services only a portion of the community that it can actually handle).
>
> Again, there is a price (for example, requests need to include trust
> conditions, and OCSP responders need their own certificates).  But if a
> secure, scaleable protocol is desired (which seems reasonable, since
> this is the IPKI), it seems that we need to pursue the second model...
>
> >The timestamp in the OCSP response is the time at which the response was
> >signed.  Mapping one-to-one to CRLs, this corresponds to the thisUpdate
> >field in a CRL.  I propose to correspondingly include a nextUpdate field
in
> >the response.  Applications SHOULD reject any response where nextUpdate
is
> >earlier than their current system time.  In the limit, if thisUpdate
equals
> >nextUpdate, this reduces to a dynamic refresh model.  This will give
system
> >integrators the ability to tune OCSP behavior in accordance with local
> >security policy.
>
> This is certainly better.  Having thisUpdate AND nextUpdate allows users
> to know when the caching period ends (i.e., when the next update will
> occur) and so avoids replay attacks (except for the NO_SERVICE replay,
> as mentioned above).  But now the protocol seems to provide little value
> over CRLs (which, of course, can be produced with the same frequency as
> this caching period, if desired).  Perhaps the main advantage of this
> variation of OCSP over CRLs is the reduced bandwidth of the response,
> but distribution points can be used to reduce CRL bandwidth requirements
> if this is a problem.
>
> Note that if the difference between thisUpdate and nextUpdate is small
> then the scalability problem has not really been solved.  On the other
> hand, if it is larger so that the system can scale, then users are not
> really getting timely revocation information (which is what they were
> hoping to get by using OCSP).
>
> I guess I'm still of the opinion that we need to bind requests to
> responses, and use trusted verifiers, if we hope to do on-line
> certificate status checks properly.
>
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------

Date:         Thu, 20 Nov 1997 17:33:53 -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 and nonrepudiation -- a modest proposal
To: [email-masked]
Status:

Hi Bob,

One small point:

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Thursday, November 20, 1997 5:18 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP and nonrepudiation -- a modest proposal
>
>If a certificate was still valid at the time a digital signature was
>received, it was obviously valid at the time the transaction was signed, and
>so the precise time at which that occurred is irrelevant, at least for
>purposes of (technical) nonrepudiation.

Not quite true.  The document could conceivably have been signed prior
to the certificate being valid (e.g., before the public key was actually
certified, or while the certificate was "on hold" before becoming
valid).

Sometimes time is useful...

Carlisle.

Date:         Thu, 20 Nov 1997 15:18:29 -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 and nonrepudiation -- a modest proposal
Comments: To: [email-masked]
To: [email-masked]
Status:

>>> Luis Valente <[email-masked]> 11/20 2:34 PM >>>
Bob,

I would like to step into this discussion briefly just to state that, as a
developer of secure protocols for small footprint devices, my company does
have a need for a simple OCSP protocol. Thus, for us, your secondary
requirement is, in fact, our primary requirement. We like the definition of
OCSP as "putting CRLs online." Please keep the protocol focussed on meeting
this essential bit of functionality. Mike Meyers said it best when he
stated:

>>Lastly, a reality check: my customers need OCSP today.  They have a simple
>>problem and are looking for a simple solution (notice I did not say "low
>>assurance" or "weakly secured").  Timestamping, Digital Notary,
>>Transaction-Based services and Attribute Management, while highly
>>desirable, are further downline. This too is a reality check, not a
>>deprecation of their fundamental value in completing the PKI picture. Not
>>only are they ripe with complexity, but the first three fundamentally
>>depend upon trusted time--a non-existent quantity.

Fair enough -- I don't expect everyone to have the same set of requirements.

But let me ask you two questions.

(1)  Are you using OCSP because the existing CRL distribution mechansims is
broken, or because you need up to the second timeliness, or what?

(2)  Would the inclusion of a nonce that could be the hash of a digital
signature (in the request and the response) inconvenience you in any way, if
at the same time it also solved the nonrepudiation problem?  If it doesn't,
and if I have an equally pressing requirement as yours to provide
nonrepudiation, then I wouldn't expect you to object.

And BTW, since you quoted Mike and I hadn't noted it before, I would like to
take specific issue with his statement that Timestamping, Digital Notary,
and Transaction-based services fundamentally depend on trusted time, which
he calls a non-existant quantity.

The particular, I would go so far as to say outstanding, benefit of my
suggestion is that it solves the nonrepudiation problem WITHOUT requiring
time to be synchronized between the TTP who validates the existence of the
digital signature and the TTP who validates the status of the certificate.
In fact, I wouldn't care if we left time out of the protocol entirely,
except that it is useful in roughly synchronizing an event with something
else in the outside world, is easy to do, and is the simplest way of
providing a nonce which is needed in any case.

If a certificate was still valid at the time a digital signature was
received, it was obviously valid at the time the transaction was signed, and
so the precise time at which that occurred is irrelevant, at least for
purposes of (technical) nonrepudiation.

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:         Thu, 20 Nov 1997 13:34:37 -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 and nonrepudiation -- a modest proposal
To: [email-masked]
Status:

At 01:40 PM 11/20/97 -0700, you wrote:
>Mike,
>
>I am not yet convinced that the OCSP protocol as it is currently defined
>would be of sufficient utility that I could recommend that it be widely
>implemented, but I believe that with some trivial tweaks it could become
>extremely useful.
>
>You say, "OCSP's top-level requirement is one of timely access to
>certificate state.
>That is, it is CRLs put online."
>
>I would disagree. I don't know that any of these requirements were chiseled
>on tablets of stone, or by whom, but that is not how I would have stated the
>requirement.  I would have said, "The top-level requirement is to facilitate
>authenticating (and providing nonrepudiation for) a given digital signature
>(including a digitally signed transaction) on a timely basis."  A secondary
>requirement is to confirm the current status of a certificate prior to using
>it for some purpose other than a digital signature, e.g., for encryption or
>session authentication.

Bob,

I would like to step into this discussion briefly just to state that, as a
developer of secure protocols for small footprint devices, my company does
have a need for a simple OCSP protocol. Thus, for us, your secondary
requirement is, in fact, our primary requirement. We like the definition of
OCSP as "putting CRLs online." Please keep the protocol focussed on meeting
this essential bit of functionality. Mike Meyers said it best when he stated:

>>Lastly, a reality check: my customers need OCSP today.  They have a simple
>>problem and are looking for a simple solution (notice I did not say "low
>>assurance" or "weakly secured").  Timestamping, Digital Notary,
>>Transaction-Based services and Attribute Management, while highly
>>desirable, are further downline. This too is a reality check, not a
>>deprecation of their fundamental value in completing the PKI picture. Not
>>only are they ripe with complexity, but the first three fundamentally
>>depend upon trusted time--a non-existent quantity.
>>
>>OCSP solves a simple problem.  True, it's not the whole problem no more
>>than CRLs are, but it's standard practice to break a complex problem into
>>manageable pieces.  Timestamping, Digital Notary, Transaction Based
>>Services and Attribute Management should have separate work items that
>>identify and define the technology, infrastructure and practices required
>>to implement them.  A layering of architectural elements, established over
>>time and in synchronicity with PKI marketplace reality, will move us all
>>towards these common objectives.
>>
>>--Mike

Just my 2 cents.
/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]

PGP key fingerprint: 4DF2 ADC5 D12B 675D E711 2F7D F23E 9CCB ACCD 5529

Date:         Thu, 20 Nov 1997 13:40:34 -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:      [IETF-PKIX] OCSP and nonrepudiation -- a modest proposal
Comments: To: [email-masked]
To: [email-masked]
Status:

Mike,

I am not yet convinced that the OCSP protocol as it is currently defined
would be of sufficient utility that I could recommend that it be widely
implemented, but I believe that with some trivial tweaks it could become
extremely useful.

You say, "OCSP's top-level requirement is one of timely access to
certificate state.
That is, it is CRLs put online."

I would disagree. I don't know that any of these requirements were chiseled
on tablets of stone, or by whom, but that is not how I would have stated the
requirement.  I would have said, "The top-level requirement is to facilitate
authenticating (and providing nonrepudiation for) a given digital signature
(including a digitally signed transaction) on a timely basis."  A secondary
requirement is to confirm the current status of a certificate prior to using
it for some purpose other than a digital signature, e.g., for encryption or
session authentication.

In particular, I do NOT view the solution as merely putting CRLs on line,
for the CRL mechanism itself is an anachronism that was intended to support
an environment (disconnected or stand-alone operation) that is increasingly
irrelevant in today's world.

I agree that coupling an insurance mechanism as I suggested might be
considered out of scope at the present time.  On the other hand, having the
CA (who speaks authoritatively about the status of certificates it has
issued) or some other trusted third party who acts as the CA's agent, bind
that certificate status to a digital signature or transaction to confirm
that at least the lowest level certificate was valid as of the time the
digital signature in question was received, would seem to be very
reasonable, and also a very minor extension, as I shall now illustrate.

Since the requestor is sending a message to the CA in any case, and since
some kind of a nonce will be required to protect against replay attacks, I
would suggest using an SHA-1 digest of a digital signature (or of a
transaction or document) as the nonce.  (It could also be just a random set
of bits, if the certificate status is being checked without a digital
signature being involved, e.g., prior to sending an encrypted message.)

On the return side, the CA or TTP is obviously going to have to digitally
sign the response. At a minimum, in order to protect against replay attacks,
it has to sign the nonce which the requestor included.  If the nonce were a
hash of a digital signature, signing that hash together with a response code
indicating that the certificate was valid (or including a CRL) would have
the effect of indicating that the certificate was valid as of the time of
receipt of the request, and hence the digital signature and the certificate
validity period were contemporaneous, which is the heart of the matter with
respect to nonrepudiation.

Although timestamping is of no great importance with respect to
nonrepudiation if the CA has confirmed that the certificate was valid at the
time that a particular digital signature was received (since we no longer
need to do all of the synchronized clock checking that would otherwise be
required), a timestamp may still be useful in terms of synchronizing the
certification of a digital signature with respect to external events.  In
addition, although it is sufficient for the originator of the request to
merely include a hash of a signature as a nonce, the responses ought to be
differentiated so that validation of a digital signature can be
distinguished from another at a different time.  Including a date/time
within the signed return message is trivial to do, satisfies the nonce
requirement, and has the added value of providing a notarized time stamp.

I am therefore proposing that a nonce be included within the OCSP request
protocol, which I believe was required in any case -- a point which I
believe Carlisle has been making.  I am proposing that the nonce optionally
be an SHA-1 message digest of some arbitrary piece of text, e.g., either a
digitally signed transaction, or just the digital signature portion of that
transaction (or the text itself, if all that is needed is a timestamp). And
I am proposing that the response include that nonce plus a date/time stamp
in addition to the certificate status and/or CRL information that is
digitally signed.

The correlation between the digitally signed nonce that is returned and the
transaction that is being "notarized" (with respect to certificate validity
only) can be determined externally.  It might be nice if the OCSP spec were
to spell out exactly how this is to be accomplished, but that piece could be
deferred if desired.

These modifications are so trivial, and in the case of the nonce would seem
to be necessary to make the protocol secure in any case, that I cannot
imagine any reason not to include them within the OCSP protocol.

There is one other problem that ought to be addressed, however, and that is
the issue of billing and/or the prevention of denial of service attacks.

If the CA is obligated to respond to every OCSP request, then a malicious
person, perhaps a competitor of the CA, could bring the CA to its knees by
simply flooding the system with OCSP requests. Even under the naive,
tooth-fairy assumption that everything on the Internet ought to be free,
that isn't reasonable or prudent.  At a minimum, some means has to be
provided to reliably indicate the source of the OCSP request, and that means
that the original request ought to be digitally signed by the originator.
And if we are going to digitally sign the request, we ought to provide some
means of optionally including some kind of billing information -- at least
the originator's account number which is to be charged for providing this
information.  If the CA requires that the billing information be present, it
can simply ignore any improper (unsigned) requests, and not even return an
error response. (After thinking about this some more, I suppose we ought to
include a date/time field in the request, and to approximately synchronize
the request time with the real time, so as to prevent some third person from
replying a valid request just to run up the requestor's bill.)

We don't have to do it right now, I suppose (although I would like to), but
if the billing information field were defined in such as way as to be
extensible, then we could easily add another field which would represent the
declared value of the transaction.  And then the response code from the CA
could indicate whether or not that particular transaction was accepted and
insured, or not.  What rationale the CA uses to decide whether or not to
insure the transaction is not our concern at this time.

I believe that this modest proposal would have a very minimal impact on the
existing OCSP protocol, but at the same time would provide enormous benefit
in the area of nonrepudiation, which to date has not been adequately
addressed. Timestamping, although of less than overwhelming importance,
would also be addressed.

This doesn't solve all of the world's problems, however. In particular, I am
not suggesting that we concern ourselves with notarizing or authenticating
the CONTENT of a particular message with respect to any other criteria other
than certificate validity.  I am also not addressing any kind of attribute
certificates, attribute validation, attribute authority, roles, etc.

Likewise, I am willing to separate out the issue of reliance limits and
other contractual privity issues.  Although it is an area I am currently
working on,  it deserves to be in a separate document and to be discussed
independently.

Bob

>
>
>>>> <[email-masked]> 11/19 2:20 PM >>>
>Bob--
>
>We need to come to terms with the OCSP drivers, from which come the
>requirements:
>
>We began this work early this year with OCSP as one variation within the
>PKIX Part 2 scope.  Mechanisms toward Timestamping, Digital Notary,
>Transaction-Based Services and Attribute Authorization are clearly beyond
>the scope of the former Part 2.  If not, then the current discussion should
>redirect other Part 2 mechanisms to equitably address reliance limits, the
>effects of contractual privity and generally the means by which liability
>is apportioned in both open and closed PKI models.  With respect to LDAP,
>for example, one may require reliance limit attribute per certificate prior
>to claiming the LDAP server (or service) is PKIX-compliant.
>
>OCSP's top-level requirement is one of timely access to certificate state.
>That is, it is CRLs put online.  Here too there exists a one-to-one
>relationship between OCSP and a well-defined scope.  OCSP is no more
>broadly scoped than CRLs.  To put it another way, OCSP should not be seen
>as a means to arrive at information that is not generally representable as
>CRL content.
>
>Attribute Certificates, attribute validation and attribute authority
>delegation is a major work area.  After years of debate and standards
>drafting, there still does not exist a broadly-based implementation nor
>usage of the concept.  I believe we have fairly well concluded however that
>the most effective working model is one that provides a reliable identity
>independant of attributes that may be associated with that identity.  Thus
>mechanisms necessary to confirm the validity of a claimed identity should
>be distinct from those which ascertain the validity of claimed attributes.
>
>Lastly, a reality check: my customers need OCSP today.  They have a simple
>problem and are looking for a simple solution (notice I did not say "low
>assurance" or "weakly secured").  Timestamping, Digital Notary,
>Transaction-Based services and Attribute Management, while highly
>desirable, are further downline. This too is a reality check, not a
>deprecation of their fundamental value in completing the PKI picture. Not
>only are they ripe with complexity, but the first three fundamentally
>depend upon trusted time--a non-existent quantity.
>
>OCSP solves a simple problem.  True, it's not the whole problem no more
>than CRLs are, but it's standard practice to break a complex problem into
>manageable pieces.  Timestamping, Digital Notary, Transaction Based
>Services and Attribute Management should have separate work items that
>identify and define the technology, infrastructure and practices required
>to implement them.  A layering of architectural elements, established over
>time and in synchronicity with PKI marketplace reality, will move us all
>towards these common objectives.
>
>--Mike
>
>

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:         Thu, 20 Nov 1997 12:39:36 -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: Peter Tapling <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

OFF LIST

> -----Original Message-----
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Thursday, November 20, 1997 8:37 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] P R E S S     R E L E A S E
>
> P R E S S    R E L E A S E         11:27 AM   11/20/97
> =====================
>
> If you want to be taken off this e-mailing list please reply with OFF
> LIST. No more email will be sent
> to you again from this address. Your email address was extracted from
> the WEB using Email
> Extractor Pro. This mailing list was targeted at a specifice audience.
> If you feel you received this
> email in error please accept our apologies. The creator of this list
> is against spamming. If you feel
> you were spammed please contact [email-masked] to be removed from
> all future mailings
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> /\/\/\/\/\/\/\/\/\/\/
>
> DirectED - The New Way to Learn!
>
> DirectED, Canada's Internet based International Correspondence School,
> has opened its doors.
>
> Students can take courses at our virtual campus at WWW.DIRECTED.EDU.
> Visit the campus
> business office for complete details. What you get when you enroll in
> a DirectED program:
>
>       ACER Pentium 200 MMX Computer
>       LexMark Color Printer
>       Prepaid Internet account for 1 Year (60 hours per month)
>       Complete set of books
>       Software
>       CD Rom Tutorials
>       Toll Free Support
>       Full access to our Virtual Campus
>       An accredited diploma upon completion of the program
>
> Learn in the comfort of your own home at your own pace. It's the New
> Way To Learn!
>
> If you want to learn more please visit our web site at
>
>                   http://WWW.DIRECTED.EDU
>
> or call
>
>                   1-888-GO-4-SUCCESS
>                   1-888-464-7822
>
> or email
>
>                    [email-masked]
>
> We would really appreciate it if you would create a link to our web
> page so we can return the favor.
> If your site has an educational section please feel free to add us to
> your list.
>
>
> Any other questions or concerns can be directed to [email-masked]

Date:         Thu, 20 Nov 1997 13:21:28 -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 Questions
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Hi Mike,

I assume you meant this to go to the list (since you addressed it to
"All" and referred to me and to Ambarish in third person), so I'm
responding to the list...

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Thursday, November 20, 1997 10:43 AM
>To:    Carlisle Adams
>Subject:       RE: OCSP Questions
>
>All,
>
>When an OCSP request cannot be satisfied, a signed NO_SERVICE response is
>produced.  However, as pointed out by Carlisle and Ambarish, malicious
>parties could replay this message against requests that might otherwise
>generate a valid response.

This is not the full extent of the replay attack.  Let's say that the CA
generates a new batch of signed responses every half hour (i.e., the
caching period is 30 minutes).  In order to provide up-to-the-minute
revocation information, however, it will replace a signed "Good"
response with a signed "Bad" response as soon as a revocation has
occurred.

Now, the update occurs at 10:30 and at 10:35 Joe's certificate is
revoked (at Joe's request, let's say, claiming key compromise).  All Joe
has to do to repudiate a transaction is to make an OCSP request at
10:34, get back a valid "Good" response, make another OCSP response at
10:36, get back a valid "Bad" response, and replay the "Good" response
(i.e., pretending to be the OCSP responder) any time someone else makes
an OCSP request about his certificate between 10:36 and 11:00 (when the
next update will occur).  Susan, who checks Joe's certificate at 10:45
and thinks it's good, accepts some transaction.  Joe later successfully
repudiates that transaction by producing a valid OCSP response showing
that his certificate was bad at 10:36.

This is just an example, but it illustrates that caching does not allow
the OCSP protocol to achieve what it aims to achieve (i.e., timely
certificate status information) because it opens the door for replay
attacks.

>A common approach towards mitigating the effects of this attack is through
>a cryptographic binding of requests to responses.  This however precludes
>pre-signing and caching behaviors.  (I would note that any other such
>protocol would suffer the same negative effects on their scalability).

Cryptographically binding requests and responses does not "mitigate
(i.e., lessen, decrease, ease, lighten) the effects of this attack"; it
effectively removes the possibility of this attack (assuming strong
cryptographic algorithms).  This is a significant difference, so it
should be made clear.  Yes, it does preclude pre-signing and caching
behaviors  --  proper security always costs something.

As for your note ("any other such protocol would suffer the same
negative effects on their scalability"), this is not quite true.  The
critical difference is the model of the world embedded in the protocol.
On the one hand, if the protocol assumes one CA (or a small number of
CAs) and OCSP responders that represent a particular CA, then not
allowing caching severely limits scalability.  On the other hand, if the
protocol assumes any number of CAs and OCSP responders that are
essentially independent of CAs (i.e., trusted verifiers), then not
allowing caching has no effect on scalability (since each OCSP responder
services only a portion of the community that it can actually handle).

Again, there is a price (for example, requests need to include trust
conditions, and OCSP responders need their own certificates).  But if a
secure, scaleable protocol is desired (which seems reasonable, since
this is the IPKI), it seems that we need to pursue the second model...

>The timestamp in the OCSP response is the time at which the response was
>signed.  Mapping one-to-one to CRLs, this corresponds to the thisUpdate
>field in a CRL.  I propose to correspondingly include a nextUpdate field in
>the response.  Applications SHOULD reject any response where nextUpdate is
>earlier than their current system time.  In the limit, if thisUpdate equals
>nextUpdate, this reduces to a dynamic refresh model.  This will give system
>integrators the ability to tune OCSP behavior in accordance with local
>security policy.

This is certainly better.  Having thisUpdate AND nextUpdate allows users
to know when the caching period ends (i.e., when the next update will
occur) and so avoids replay attacks (except for the NO_SERVICE replay,
as mentioned above).  But now the protocol seems to provide little value
over CRLs (which, of course, can be produced with the same frequency as
this caching period, if desired).  Perhaps the main advantage of this
variation of OCSP over CRLs is the reduced bandwidth of the response,
but distribution points can be used to reduce CRL bandwidth requirements
if this is a problem.

Note that if the difference between thisUpdate and nextUpdate is small
then the scalability problem has not really been solved.  On the other
hand, if it is larger so that the system can scale, then users are not
really getting timely revocation information (which is what they were
hoping to get by using OCSP).

I guess I'm still of the opinion that we need to bind requests to
responses, and use trusted verifiers, if we hope to do on-line
certificate status checks properly.

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

Date:         Thu, 20 Nov 1997 09:49:59 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dennis Glatting <[email-masked]>
Subject:      Re: [IETF-PKIX] testing new listserv software
To: [email-masked]
Status:

Something else appears to be broken with the list too. Note the "may
be forged" in the following log.

Nov 20 09:35:07 btw sendmail[14014]: JAA14014:
from=<[email-masked]>, size=1779, class=0, pri=31779,
nrcpts=1, msgid=<[email-masked]>,
proto=ESMTP, relay=talia-100.mis.tandem.com [130.252.226.155] (may be
forged)

-dpg

Date:         Thu, 20 Nov 1997 12:23:37 -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: "Dr. Dale M. Johnson" <[email-masked]>
Subject:      Re: [IETF-PKIX] OFF LIST
To: [email-masked]
Status:

Bill,

The company seems to have goofed in their instructions.  Looks like a
number of folks spammed everyone!

Dale.

At 10:11 AM 11/20/97 -0400, you wrote:
>OFF LIST
>
>

Date:         Thu, 20 Nov 1997 18:12:01 +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: Stefan Kelm <[email-masked]>
Organization: DFN-PCA (Policy Certification Authority, Germany)
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

STOP SENDING BULLSHIT!!!
>
> P R E S S    R E L E A S E         11:27 AM   11/20/97
> =====================
>
> If you want to be taken off this e-mailing list please reply with OFF LIST. No more email will be sent
> to you again from this address. Your email address was extracted from the WEB using Email
> Extractor Pro. This mailing list was targeted at a specifice audience. If you feel you received this
> email in error please accept our apologies. The creator of this list is against spamming. If you feel
> you were spammed please contact [email-masked] to be removed from all future mailings
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
>
> DirectED - The New Way to Learn!
>
> DirectED, Canada's Internet based International Correspondence School, has opened its doors.
>
> Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit the campus
> business office for complete details. What you get when you enroll in a DirectED program:
>
>       ACER Pentium 200 MMX Computer
>       LexMark Color Printer
>       Prepaid Internet account for 1 Year (60 hours per month)
>       Complete set of books
>       Software
>       CD Rom Tutorials
>       Toll Free Support
>       Full access to our Virtual Campus
>       An accredited diploma upon completion of the program
>
> Learn in the comfort of your own home at your own pace. It's the New Way To Learn!
>
> If you want to learn more please visit our web site at
>
>                   http://WWW.DIRECTED.EDU
>
> or call
>
>                   1-888-GO-4-SUCCESS
>                   1-888-464-7822
>
> or email
>
>                    [email-masked]
>
> We would really appreciate it if you would create a link to our web page so we can return the favor.
> If your site has an educational section please feel free to add us to your list.
>
>
> Any other questions or concerns can be directed to [email-masked]
>

Date:         Thu, 20 Nov 1997 16:52:28 +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: David Boyce <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S R E L E A S E - admin action please.
Comments: cc: [email-masked]
To: [email-masked]
Status:

Various folk write to the ietf-pkix list:

>OFF LIST

Sorry, but this isn't going to work.

It is the ietf-pkix list's address (i.e. [email-masked] ) which is the one that needs to be taken off his list, not the individual participants of the ietf-pkix list.

Also, pressing "reply" usually results in the response going to the ietf-pkix list (the Sender:) , not the individual originating the mail ([email-masked] in the From: line).  So everyone just gets the extra spam of the OFF LIST replies.  If you DO remember to adjust the 'To:' to the correct address, you are just giving [email-masked] another address (yours) to send to in future.

So please, don't attempt to get off [email-masked]'s list.  It just generates more traffic

It seems to me the only thing which can be done is for the ietf-pkix list owner to send a message to [email-masked] to get the ietf-list taken off this list, since only the owner has the moral authority to request his list's address to be removed.

Hoping this is the last you'll see of the PRESS RELEASE ..

David.

--
David Boyce

Tel:    +44 181 332 9091                Richmond, Surrey, ENGLAND
I'net:  [email-masked]       Isode's WWW: http://www.isode.com/
X.400:  I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date:         Thu, 20 Nov 1997 12:20: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: "Salter, Thomas A" <[email-masked]>
Subject:      Re: [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-05.txt
To: [email-masked]
Status:

I don't subscsribe to this list, so pardon me if I'm reopening an old
issue here.

Have you considered also defining the schema elements required to
support PKI?  In particular what attributes and syntaxes are required
and in what entry classes?  Some of these, such as userCerticate, are
defined in the Ldap V3 drafts, but are not explicitly mentioned in the
V2 standards, where they are presumed to be inherited from the x.500
standards.

It would also be helpful to define which attributes can be used to
search filters, since x.500 based implementations will require matching
rules for any attributes which are used for searches.

Date:         Thu, 20 Nov 1997 11:25: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: John Garner <[email-masked]>
Organization: Chromatix, Inc.
Subject:      [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
To: [email-masked]
Status:

Simonetti David wrote:
>
> David,
>
> You state that an application that is validating S/MIME signatures only
> wants to know if the cert is valid for NR (it only checks the NR bit and
> ignores the DS bit).  Do you mean a cert that is used to provide
> non-repudiation for S/MIME signatures may not be used to provide
> authentication and integrity?
>
> Again, all that I am saying is that when non-repudiation is claimed,
> authentication and integrity are by-products.  I have yet to see an
> example that contradicts this.  Of the (few) responses I have received
> (which you have also received, Dave), they all agree with this
> statement.
>
> I would very much like to hear the opinions of others.
>
> Dave Simonetti
>

David,

I am also currently attempting to implement the key usages as defined in
the X.509 KeyUsage extension, and I am also similarly  confused about
the use of the digitalSignature and nonRepudiation bits. I am also very
new to the certificate processing arena, and was glad to see the
responses generated by your message.

For me, nonRepudiation implies that at sometime in the future, one of
the parties involved in a transactions is attempting to prove that the
transaction in question took place, and the other party was involved.
Therfore providing a nonrepudiation service would require verifying that
the other parties signature was properly validated in the past. This
would require a "snapshot" of the environment at the exact time of
validation be saved somewhere. Therefore as mention in the response by
Charles Blauner the nonRepudiation bit implies much more than the
digitalSignture bit.

The digitalSignature and the nonRepudiation bits are extremely
interconnected. Part of me believes that nonRepudiation implies
digitalSignature, while the other part like the idea of the KeyUsage
bits having distinct and seperate purposes. I also agree with your
assetion that authentication and integrity are by-products on
non-repudiation, but only at a future time. So if it is authentication
and integrity you are after, digitalSignature should be set, and if you
are after some more envolved non-repudiation service (archiving of all
pertinent data, by a trusted third party for future use), set the
nonRepudiation bit.

Not much help I imagine, but hey, worst case I could be wrong.

John Garner

======================================================================
      //_/_/               John R. Garner
   _/      _/
  _/       _/              Chromatix, Inc.
 _/           _/  _/       10451 Twin Rivers Road, Suite 265
_/            _/_/         Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]

Date:         Thu, 20 Nov 1997 16:45:07 +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] P R E S S R E L E A S E
To: [email-masked]
Status:

OFF LIST

[email-masked] on 20/11/97 15.37.10

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Fabio Omenigrandi/SSB)
Subject:  [IETF-PKIX] P R E S S     R E L E A S E

P R E S S    R E L E A S E         11:27 AM   11/20/97
=====================

If you want to be taken off this e-mailing list please reply with OFF LIST.
No more email will be sent to you again from this address. Your email
address was extracted from the WEB using Email Extractor Pro. This mailing
list was targeted at a specifice audience. If you feel you received this
email in error please accept our apologies. The creator of this list is
against spamming. If you feel you were spammed please contact
[email-masked] to be removed from all future mailings

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
\/\/\/\/\/\/\/\/

DirectED - The New Way to Learn!

DirectED, Canada's Internet based International Correspondence School, has
opened its doors.

Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit
the campus business office for complete details. What you get when you
enroll in a DirectED program:

      ACER Pentium 200 MMX Computer
      LexMark Color Printer
      Prepaid Internet account for 1 Year (60 hours per month)
      Complete set of books
      Software
      CD Rom Tutorials
      Toll Free Support
      Full access to our Virtual Campus
      An accredited diploma upon completion of the program

Learn in the comfort of your own home at your own pace. It's the New Way To
 Learn!

If you want to learn more please visit our web site at

                  http://WWW.DIRECTED.EDU

or call

                  1-888-GO-4-SUCCESS
                  1-888-464-7822

or email

                   [email-masked]

We would really appreciate it if you would create a link to our web page so
we can return the favor. If your site has an educational section please
feel free to add us to your list.

Any other questions or concerns can be directed to [email-masked]

Date:         Thu, 20 Nov 1997 10:36: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: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] testing new listserv software
Comments: cc: Keith Moore <[email-masked]>, Harald T Alvestrand <[email-masked]>
To: [email-masked]
Status:

I'm not sure where the best place to discuss these issues is (on the
list?  it affects the list's audience.  on another list?  do we all read
that other list?  privately?  see point 1), so I apologize if this is
the wrong place.  Two quick comments, and I'll discuss this no more.

Wrt modifying the subject line:  I've already seen at least one message
that had [IETF-PKIX] in the subject twice, probably due to characters
other than "re:" appearing at the beginning.  IMHO, this makes the
subject lines too long and makes it difficult to follow a conversation.
I appreciate the reason, to make it easier to sift through one's Inbox,
or to enable automatic message processing, but, personally I find it to
add little or no value, and I believe that there is a better way (see
below).

Wrt to not modifying the "To:" line:  I agree that this violates 5.1 of
the I-D.  However, in this instance, I think it is the I-D that needs to
change.  Personally, I find it much easier to manage by Inbox processing
rules when I know in advance exactly what address will appear in the
headers.  I could care less what field it's in.  What I do like is the
fact that it is 100% consistent.  May I make a suggestion?  Allow
modification of the list address as follows:  "canonicalize" the list
address to some well-known value, and leave it where it was.  No other
modifications are permitted.

Again, apologies if most list readers don't appreciate this
meta-discussion, or do, but read other more appropriate lists and wish
it were there.

I'll return to lurking,

pww

Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3401

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Thursday, November 20, 1997 6:38 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] testing new listserv software
>
>Unfortunately I cannot ignore the test, as it shows a bit
>too many uncomfortable list properties for my taste.
>
>Compared to the proposed requirements for IETF listservers
>(draft-moore-maillist-req-01.txt), you have:
>
>- Added a REPLY-TO header that points to the mailing list,
>  violating section 5.1.1's SHOULD NOT.
>- Added a subject modifier [IETF-PKIX] - this is legal, but
>  not to my taste. Not least because it's long - [PKIX] would
>  have been better. Section 5.1.2
>- Added a Sender field pointing to the list, violating 5.1.4
>- From the rather consistent way the To field is written, I
>  suspect that the listserver is also munging this field,
>  in violation of the general directive of section 5.1
>
>The TIP list, hosted on the same listserver, has apparently been
>configured better, since it does not show the Reply-to and Sender
>problems; I suspect it may still have the To: problem.
>
>I hope you can reconfigure this.
>Regards,
>
>              Harald T. Alvestrand
>

Date:         Thu, 20 Nov 1997 09:19:23 -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: Randy Butler <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

OFF LIST

At 09:37 AM 11/20/97 -0500, you wrote:
>P R E S S    R E L E A S E         11:27 AM   11/20/97
>=====================
>
>If you want to be taken off this e-mailing list please reply with OFF
LIST. No more email will be sent
>to you again from this address. Your email address was extracted from the
WEB using Email
>Extractor Pro. This mailing list was targeted at a specifice audience. If
you feel you received this
>email in error please accept our apologies. The creator of this list is
against spamming. If you feel
>you were spammed please contact [email-masked] to be removed from all
future mailings
>
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
\/\/\/\/\/\/\/\/
>
>DirectED - The New Way to Learn!
>
>DirectED, Canada's Internet based International Correspondence School, has
opened its doors.
>
>Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit
the campus
>business office for complete details. What you get when you enroll in a
DirectED program:
>
>      ACER Pentium 200 MMX Computer
>      LexMark Color Printer
>      Prepaid Internet account for 1 Year (60 hours per month)
>      Complete set of books
>      Software
>      CD Rom Tutorials
>      Toll Free Support
>      Full access to our Virtual Campus
>      An accredited diploma upon completion of the program
>
>Learn in the comfort of your own home at your own pace. It's the New Way
To Learn!
>
>If you want to learn more please visit our web site at
>
>                  http://WWW.DIRECTED.EDU
>
>or call
>
>                  1-888-GO-4-SUCCESS
>                  1-888-464-7822
>
>or email
>
>                   [email-masked]
>
>We would really appreciate it if you would create a link to our web page
so we can return the favor.
>If your site has an educational section please feel free to add us to your
list.
>
>
>Any other questions or concerns can be directed to [email-masked]
>
>

Date:         Thu, 20 Nov 1997 10:19: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: "Brainard, John" <[email-masked]>
Subject:      [IETF-PKIX] OFF LIST
To: [email-masked]
Status:

OFF LIST

> ----------
> From:         [email-masked][SMTP:[email-masked]]
> Reply To:     IETF X.509-based public key infrastructure mailing list
> Sent:         Thursday, November 20, 1997 9:37 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] P R E S S     R E L E A S E
>
> P R E S S    R E L E A S E         11:27 AM   11/20/97
> =====================
>
> If you want to be taken off this e-mailing list please reply with OFF
> LIST. No more email will be sent
> to you again from this address. Your email address was extracted from
> the WEB using Email
> Extractor Pro. This mailing list was targeted at a specifice audience.
> If you feel you received this
> email in error please accept our apologies. The creator of this list
> is against spamming. If you feel
> you were spammed please contact [email-masked] to be removed from
> all future mailings
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> /\/\/\/\/\/\/\/\/\/\/
>
> DirectED - The New Way to Learn!
>
> DirectED, Canada's Internet based International Correspondence School,
> has opened its doors.
>
> Students can take courses at our virtual campus at WWW.DIRECTED.EDU.
> Visit the campus
> business office for complete details. What you get when you enroll in
> a DirectED program:
>
>       ACER Pentium 200 MMX Computer
>       LexMark Color Printer
>       Prepaid Internet account for 1 Year (60 hours per month)
>       Complete set of books
>       Software
>       CD Rom Tutorials
>       Toll Free Support
>       Full access to our Virtual Campus
>       An accredited diploma upon completion of the program
>
> Learn in the comfort of your own home at your own pace. It's the New
> Way To Learn!
>
> If you want to learn more please visit our web site at
>
>                   http://WWW.DIRECTED.EDU
>
> or call
>
>                   1-888-GO-4-SUCCESS
>                   1-888-464-7822
>
> or email
>
>                    [email-masked]
>
> We would really appreciate it if you would create a link to our web
> page so we can return the favor.
> If your site has an educational section please feel free to add us to
> your list.
>
>
> Any other questions or concerns can be directed to [email-masked]
>

Date:         Thu, 20 Nov 1997 09:03:35 -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: "Brian M. Thomas" <[email-masked]>
Subject:      Re: [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

OFF LIST

> From [email-masked] Thu Nov 20 08:58 CST 1997
> X-Authentication-Warning: swbcs003.sbc.com: uucp set sender to <[email-masked]> using -f
> Date:         Thu, 20 Nov 1997 09:37:10 -0500
> From: [email-masked]
> Subject:      [IETF-PKIX] P R E S S     R E L E A S E
> To: [email-masked]
>
> P R E S S    R E L E A S E         11:27 AM   11/20/97
> =====================
>
> If you want to be taken off this e-mailing list please reply with OFF LIST. No more email will be sent
> to you again from this address. Your email address was extracted from the WEB using Email
> Extractor Pro. This mailing list was targeted at a specifice audience. If you feel you received this
> email in error please accept our apologies. The creator of this list is against spamming. If you feel
> you were spammed please contact [email-masked] to be removed from all future mailings
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
>
> DirectED - The New Way to Learn!
>
> DirectED, Canada's Internet based International Correspondence School, has opened its doors.
>
> Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit the campus
> business office for complete details. What you get when you enroll in a DirectED program:
>
>       ACER Pentium 200 MMX Computer
>       LexMark Color Printer
>       Prepaid Internet account for 1 Year (60 hours per month)
>       Complete set of books
>       Software
>       CD Rom Tutorials
>       Toll Free Support
>       Full access to our Virtual Campus
>       An accredited diploma upon completion of the program
>
> Learn in the comfort of your own home at your own pace. It's the New Way To Learn!
>
> If you want to learn more please visit our web site at
>
>                   http://WWW.DIRECTED.EDU
>
> or call
>
>                   1-888-GO-4-SUCCESS
>                   1-888-464-7822
>
> or email
>
>                    [email-masked]
>
> We would really appreciate it if you would create a link to our web page so we can return the favor.
> If your site has an educational section please feel free to add us to your list.
>
>
> Any other questions or concerns can be directed to [email-masked]

Date:         Thu, 20 Nov 1997 10:11:05 -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: Bill Neugent <[email-masked]>
Subject:      [IETF-PKIX] OFF LIST
To: [email-masked]
Status:

OFF LIST

Date:         Thu, 20 Nov 1997 09:55:36 -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-ipki2opp-05.txt
Comments: To: [email-masked]
To: [email-masked]
Status:

A Revised 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.

Note: This revision reflects comments received during the last call period.

        Title           : Internet Public Key Infrastructure
                          Operational Protocols - LDAPv2
        Author(s)       : T. Howes, S. Boeyen, P. Richard
        Filename        : draft-ietf-pkix-ipki2opp-05.txt
        Pages           : 12
        Date            : 19-Nov-97

     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements  within  the Internet Public Key
     Infrastructure  (IPKI).   Specifically,  this  document   addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.

     The key words  ''MUST'',  ''REQUIRED'',  ''SHOULD'',  ''RECOMMENDED'',
     and ''MAY''  in  this  document are to be interpreted as described
     in RFC 2119.

     Please send comments on this document to  the  [email-masked]
     mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki2opp-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-05.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-ipki2opp-05.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-dr 1 (EuSn/CSOm) (0001CEEA)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki2opp-05.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-ipki2opp-05 (AURL/Arch) (0001CEEB)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Date:         Thu, 20 Nov 1997 09:46:35 -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-ipki3cmp-06.txt
Comments: To: [email-masked]
To: [email-masked]
Status:

A Revised 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.

Note: This revision reflects comments received during the last call period.

        Title           : Internet Public Key Infrastructure
                          Certificate Management Protocols
        Author(s)       : C. Adams, S. Farrell
        Filename        : draft-ietf-pkix-ipki3cmp-06.txt
        Pages           : 70
        Date            : 19-Nov-97

This is a draft of the Internet X.509 Public Key Infrastructure (PKI)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.  Note that
''certificate'' in this document refers to an X.509v3 Certificate as
defined in [COR95, X509-AM].

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki3cmp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-06.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-ipki3cmp-06.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) (0001CEE8)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-06.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-ipki3cmp-06 (AURL/Arch) (0001CEE9)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Date:         Thu, 20 Nov 1997 09:51:43 -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 ASN.1
To: [email-masked]
Status:

> From: Bancroft Scott <[email-masked]>
>
> The fact that some tools are defective in their support for ASN.1 should
> not be used as a reason for writing ASN.1 that properly conforming ASN.1
> tools cannot support without making them defective.  This sort of thing
> applies to all standards, not just ASN.1.  If X.208 is to be used, fine,
> or if X.680 is to be used, fine; however, please don't write ASN.1-based
> standards that is known to conform to neither.

That is good advice.

But the intent of Appendix A is to present the certificate syntax in
a manner that is more accessible to many people than the syntax presented
in Appendix B.

Is it possible to write a conforming X.680 specification without using
any of the features introduced in X.680 except for the two offending
UNIVERSAL types.  I.e., if the definitions of UniversalString and BMPString
were deleted, would Appendix A be a valid X.680 module?

Date:         Thu, 20 Nov 1997 09:37: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: [email-masked]
Subject:      [IETF-PKIX] P R E S S     R E L E A S E
To: [email-masked]
Status:

P R E S S    R E L E A S E         11:27 AM   11/20/97
=====================

If you want to be taken off this e-mailing list please reply with OFF LIST. No more email will be sent
to you again from this address. Your email address was extracted from the WEB using Email
Extractor Pro. This mailing list was targeted at a specifice audience. If you feel you received this
email in error please accept our apologies. The creator of this list is against spamming. If you feel
you were spammed please contact [email-masked] to be removed from all future mailings

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

DirectED - The New Way to Learn!

DirectED, Canada's Internet based International Correspondence School, has opened its doors.

Students can take courses at our virtual campus at WWW.DIRECTED.EDU. Visit the campus
business office for complete details. What you get when you enroll in a DirectED program:

      ACER Pentium 200 MMX Computer
      LexMark Color Printer
      Prepaid Internet account for 1 Year (60 hours per month)
      Complete set of books
      Software
      CD Rom Tutorials
      Toll Free Support
      Full access to our Virtual Campus
      An accredited diploma upon completion of the program

Learn in the comfort of your own home at your own pace. It's the New Way To Learn!

If you want to learn more please visit our web site at

                  http://WWW.DIRECTED.EDU

or call

                  1-888-GO-4-SUCCESS
                  1-888-464-7822

or email

                   [email-masked]

We would really appreciate it if you would create a link to our web page so we can return the favor.
If your site has an educational section please feel free to add us to your list.

Any other questions or concerns can be directed to [email-masked]

Date:         Thu, 20 Nov 1997 08:56:57 -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: Bancroft Scott <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX ASN.1
Comments: To: Phil Griffin <[email-masked]>
To: [email-masked]
Status:

Phil Griffin wrote:

> > >Both BMPString and UniversalString are types defined only in the
> > >current standard, ASN.1:1994. PKIX uses BMPString in code that uses
> > >the superceded ANY DEFINED BY, which is described in Annex I of the
> > >current standards, but is not an integral part of the ASN.1 standards.
> > >X.208 does not define type BMPString. Such ASN.1 usage will certainly
> > >break tools that correctly implement the ASN.1 standards.
> >
> > I think that the PKIX '88 ASN.1 gets around this adequately by declaring:
> >
> > UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
> >         -- UniversalString is defined in ASN.1:1993
> > BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
> >         -- BMPString is the subtype of
> >         -- UniversalString and models the Basic Multilingual Plane
> >         -- of ISO/IEC 10646-1
> >
> > This certainly works with my '90 based ASN.1 compiler :-)
> >
> > Dean.
>
> It is not valid to use 'UNIVERSAL' as a tag class in an ASN.1 abstract
> syntax. This class is reserved for use in the ASN.1 standards, where
> it is used as shown above to define builtin ASN.1 types. The notation
> you describe above is not valid, but attempts to redefine an ASN.1:1994
> builtin type as part of X.208.
>
> In particular, the introduction to X.680 states that "Users of this
> notation are not allowed to explicitly specify universal class tags
> in their ASN.1 specifications, for these tags are built-in and can
> be specified explicitly only in this Recommendation | International
> Standard."
>
> Phil

Forbidding use of the UNIVERSAL class in ASN.1 specs is not something
introduced by X.680.  CCITT X.208 | ISO/IEC 8824 clause 26.4 explicitly
forbids use of class UNIVERSAL other than for types defined within the
ASN.1 standard itself.

The fact that some tools are defective in their support for ASN.1 should
not be used as a reason for writing ASN.1 that properly conforming ASN.1
tools cannot support without making them defective.  This sort of thing
applies to all standards, not just ASN.1.  If X.208 is to be used, fine,
or if X.680 is to be used, fine; however, please don't write ASN.1-based
standards that is known to conform to neither.

--------------------------------------------------------------------------
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:         Thu, 20 Nov 1997 12:48:32 +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] SV: Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

[email-masked] wrote:
>
> Simonetti David wrote:
>
> > David,
> >
> > You state that an application that is validating S/MIME signatures only
> > wants to know if the cert is valid for NR (it only checks the NR bit and
> > ignores the DS bit).  Do you mean a cert that is used to provide
> > non-repudiation for S/MIME signatures may not be used to provide
> > authentication and integrity?
> >
> > Again, all that I am saying is that when non-repudiation is claimed,
> > authentication and integrity are by-products.  I have yet to see an
> > example that contradicts this.  Of the (few) responses I have received
> > (which you have also received, Dave), they all agree with this
> > statement.
>
> > I would very much like to hear the opinions of others.
>
> A key marked to be used for non repudiation should not be used to
> provide authentication or integrity unless the holder of the key does
> not care with misuse of the key. Some (bad) protocols for authentication
> may be such that the signature involves only data from someone else. In
> that case it would be possible to get "something" signed which would be
> the hash of a non repudiatable message. Unless making sure that all
> protocols being used do not have this property, a simple measure is to
> limit the use of the NR key. Examination of protocols is thus avoided.
> Key separation is "good practice".
>
> As a consequence, I do not consider authentication and integrity to be
> by-products of non-repudiation.
>
> Denis

I totally agree  with Dennis. It's a security risk if an NR key is used in
authentication protocols. Therefore it should be possible to just set
the NR bit and not the digitalSignature bit.

I think it's unfortunate that ISO didn't use the term authentication insted
of digitalSignature in the keyUsage field. It would have avoided much
confusion.

/Lars Johansson
Sweden Post

Date:         Thu, 20 Nov 1997 12:38:26 +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:      Re: [IETF-PKIX] testing new listserv software
To: [email-masked]
Status:

Unfortunately I cannot ignore the test, as it shows a bit
too many uncomfortable list properties for my taste.

Compared to the proposed requirements for IETF listservers
(draft-moore-maillist-req-01.txt), you have:

- Added a REPLY-TO header that points to the mailing list,
  violating section 5.1.1's SHOULD NOT.
- Added a subject modifier [IETF-PKIX] - this is legal, but
  not to my taste. Not least because it's long - [PKIX] would
  have been better. Section 5.1.2
- Added a Sender field pointing to the list, violating 5.1.4
- From the rather consistent way the To field is written, I
  suspect that the listserver is also munging this field,
  in violation of the general directive of section 5.1

The TIP list, hosted on the same listserver, has apparently been
configured better, since it does not show the Reply-to and Sender
problems; I suspect it may still have the To: problem.

I hope you can reconfigure this.
Regards,

              Harald T. Alvestrand

Date:         Thu, 20 Nov 1997 09:31:28 -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] digitalSignature vs. nonRepudiation
To: [email-masked]
Status:

Simonetti David wrote:

> David,
>
> You state that an application that is validating S/MIME signatures only
> wants to know if the cert is valid for NR (it only checks the NR bit and
> ignores the DS bit).  Do you mean a cert that is used to provide
> non-repudiation for S/MIME signatures may not be used to provide
> authentication and integrity?
>
> Again, all that I am saying is that when non-repudiation is claimed,
> authentication and integrity are by-products.  I have yet to see an
> example that contradicts this.  Of the (few) responses I have received
> (which you have also received, Dave), they all agree with this
> statement.

> I would very much like to hear the opinions of others.

A key marked to be used for non repudiation should not be used to
provide authentication or integrity unless the holder of the key does
not care with misuse of the key. Some (bad) protocols for authentication
may be such that the signature involves only data from someone else. In
that case it would be possible to get "something" signed which would be
the hash of a non repudiatable message. Unless making sure that all
protocols being used do not have this property, a simple measure is to
limit the use of the NR key. Examination of protocols is thus avoided.
Key separation is "good practice".

As a consequence, I do not consider authentication and integrity to be
by-products of non-repudiation.

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:         Wed, 19 Nov 1997 19:17: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: Simonetti David <[email-masked]>
Organization: BAH
Subject:      [IETF-PKIX] Profiling Key Usage
To: [email-masked]
Status:

Let me try to bring this a little closer to home for all of you.  I have
felt all along that the PKIX profile (PKIX-1) is a bit weak, but having
to respond to such a widely diverse community as the Internet, this is
certainly understandable.

The profiling of the key usages is one example.  PKIX-1 makes few if any
recommendations for this possibly (probably) critical extension.  X.509
now includes encipherOnly and decipherOnly as key usages, but based on
discussions I've had, very few understand the true meaning of these
usages as based on the U.K. system that implements them.  I recommend
against their use unless you work for Nick Pope.

The problem is that X.509 does not make it entirely clear how each key
usage should be used, and people have different interpretations.

Now back to the issue at hand.  Many people have the perception that
when a key can be used to provide non-repudiation, that that key may
also be used for other signature services such as authentication and
integrity.  So many people have that perception that I am responding by
recommending that when the nonRepudiation bit is set, that the
digitalSignature bit also be set.  This way, there will never be a
misconception.  I can think of no application that would require the
services of digitalSignature, but fail when nonRepudiation is added, or
vice-versa.  My intentions are to foster interoperatibility not restrict
it.

This is what the U.S. DoD, the U.S. Federal government, and the
international financial community certificate profiles will state.

Obviously, Dave Kemp is opposed to this approach.  I would like to hear
from others.

David Simonetti
Booz-Allen & Hamilton Inc.

Date:         Wed, 19 Nov 1997 18:43:55 -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 ASN.1
Comments: To: Dean Povey <[email-masked]>
To: [email-masked]
Status:

Dean Povey wrote:
>
> >Both BMPString and UniversalString are types defined only in the
> >current standard, ASN.1:1994. PKIX uses BMPString in code that uses
> >the superceded ANY DEFINED BY, which is described in Annex I of the
> >current standards, but is not an integral part of the ASN.1 standards.
> >X.208 does not define type BMPString. Such ASN.1 usage will certainly
> >break tools that correctly implement the ASN.1 standards.
>
> I think that the PKIX '88 ASN.1 gets around this adequately by declaring:
>
> UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
>         -- UniversalString is defined in ASN.1:1993
> BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
>         -- BMPString is the subtype of
>         -- UniversalString and models the Basic Multilingual Plane
>         -- of ISO/IEC 10646-1
>
> This certainly works with my '90 based ASN.1 compiler :-)
>
> 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
> Queensland University of Technology     |  www.dstc.edu.au/events/roadshow/

It is not valid to use 'UNIVERSAL' as a tag class in an ASN.1 abstract
syntax. This class is reserved for use in the ASN.1 standards, where
it is used as shown above to define builtin ASN.1 types. The notation
you describe above is not valid, but attempts to redefine an ASN.1:1994
builtin type as part of X.208.

In particular, the introduction to X.680 states that "Users of this
notation are not allowed to explicitly specify universal class tags
in their ASN.1 specifications, for these tags are built-in and can
be specified explicitly only in this Recommendation | International
Standard."

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:         Thu, 20 Nov 1997 08:37:52 +1000
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Dean Povey <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX ASN.1
Comments: To: [email-masked]
To: [email-masked]
Status:

>Both BMPString and UniversalString are types defined only in the
>current standard, ASN.1:1994. PKIX uses BMPString in code that uses
>the superceded ANY DEFINED BY, which is described in Annex I of the
>current standards, but is not an integral part of the ASN.1 standards.
>X.208 does not define type BMPString. Such ASN.1 usage will certainly
>break tools that correctly implement the ASN.1 standards.

I think that the PKIX '88 ASN.1 gets around this adequately by declaring:

UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
        -- UniversalString is defined in ASN.1:1993
BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
        -- BMPString is the subtype of
        -- UniversalString and models the Basic Multilingual Plane
        -- of ISO/IEC 10646-1

This certainly works with my '90 based ASN.1 compiler :-)

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
Queensland University of Technology     |  www.dstc.edu.au/events/roadshow/

Date:         Wed, 19 Nov 1997 14:20:38 -0700
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
To: [email-masked]
Status:

Bob--

We need to come to terms with the OCSP drivers, from which come the
requirements:

We began this work early this year with OCSP as one variation within the
PKIX Part 2 scope.  Mechanisms toward Timestamping, Digital Notary,
Transaction-Based Services and Attribute Authorization are clearly beyond
the scope of the former Part 2.  If not, then the current discussion should
redirect other Part 2 mechanisms to equitably address reliance limits, the
effects of contractual privity and generally the means by which liability
is apportioned in both open and closed PKI models.  With respect to LDAP,
for example, one may require reliance limit attribute per certificate prior
to claiming the LDAP server (or service) is PKIX-compliant.

OCSP's top-level requirement is one of timely access to certificate state.
That is, it is CRLs put online.  Here too there exists a one-to-one
relationship between OCSP and a well-defined scope.  OCSP is no more
broadly scoped than CRLs.  To put it another way, OCSP should not be seen
as a means to arrive at information that is not generally representable as
CRL content.

Attribute Certificates, attribute validation and attribute authority
delegation is a major work area.  After years of debate and standards
drafting, there still does not exist a broadly-based implementation nor
usage of the concept.  I believe we have fairly well concluded however that
the most effective working model is one that provides a reliable identity
independant of attributes that may be associated with that identity.  Thus
mechanisms necessary to confirm the validity of a claimed identity should
be distinct from those which ascertain the validity of claimed attributes.

Lastly, a reality check: my customers need OCSP today.  They have a simple
problem and are looking for a simple solution (notice I did not say "low
assurance" or "weakly secured").  Timestamping, Digital Notary,
Transaction-Based services and Attribute Management, while highly
desirable, are further downline. This too is a reality check, not a
deprecation of their fundamental value in completing the PKI picture. Not
only are they ripe with complexity, but the first three fundamentally
depend upon trusted time--a non-existent quantity.

OCSP solves a simple problem.  True, it's not the whole problem no more
than CRLs are, but it's standard practice to break a complex problem into
manageable pieces.  Timestamping, Digital Notary, Transaction Based
Services and Attribute Management should have separate work items that
identify and define the technology, infrastructure and practices required
to implement them.  A layering of architectural elements, established over
time and in synchronicity with PKI marketplace reality, will move us all
towards these common objectives.

--Mike

Date:         Wed, 19 Nov 1997 17:06:14 -0500
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: Dave Kemp <[email-masked]>
To: [email-masked]
Status:

David,

You state that an application that is validating S/MIME signatures only
wants to know if the cert is valid for NR (it only checks the NR bit and
ignores the DS bit).  Do you mean a cert that is used to provide
non-repudiation for S/MIME signatures may not be used to provide
authentication and integrity?

Again, all that I am saying is that when non-repudiation is claimed,
authentication and integrity are by-products.  I have yet to see an
example that contradicts this.  Of the (few) responses I have received
(which you have also received, Dave), they all agree with this
statement.

I would very much like to hear the opinions of others.

Dave Simonetti

David P. Kemp wrote:
>
> > From [email-masked] Tue Nov 18 12:48:21 1997
> > Date: Tue, 18 Nov 1997 12:51:22 -0500
> > From: "Simonetti David" <[email-masked]>
> > To: "David P. Kemp" <[email-masked]>, IETF-PKIX <[email-masked]>
> > Subject: Re: digitalSignature vs. nonRepudiation
> >
> > Dave K.,
> >
> > I agree with all of your statements except for your conclusion...
> >
> > <snip>
> >
> > > If one claims that one cannot do nonrepudiation without integrity and
> > > therefore every certificate with bit 1 set must also have bit 0 set,
> > > then it becomes impossible to specify a keyUsage which is valid for
> > > S/MIME message signing but not valid for TLS authentication.  This
> > > is the undesirable outcome of that line of reasoning.
> >
> > If I'm not mistaken, you're saying that the certificate to be used with
> > S/MIME signature validation will only include the "nonRepudiation" bit,
> > and the certificate used for TLS authentication will only include the
> > "digitalSignature" bit.
>
> No. Without the proposed restriction, a certificate may contain any
> combination of the two bits: 00, 01, 10, 11.
>
> > So, if my application is performing TLS authentication, but the public
> > key cert has "nonRepudiation" set, my application must reject the
> > certificate because the cert can't be used for authentication(?!).
>
> No, the application that is performing TLS only wants to know if the
> cert is valid for authentication, so it checks only the DS bit.  It
> ignores the NR bit.
>
> An application that is performing S/MIME signatures only wants to know
> if the cert is valid for NR, and checks only the NR bit, and ignores the
> DS bit.
>
> A CA and an associated community of users who don't care about the
> distinction would routinely issue certs with both bits set, to enable
> both purposes.  But we should retain the freedom for CAs/users who *do*
> care, to set only the bit(s) appropriate for their application(s).
>
> -----
>
> Under the proposed restriction, should an S/MIME application accept or
> reject a certificate that violates the restriction (has NR set and DS
> clear)?

Date:         Wed, 19 Nov 1997 14:30:21 -0600
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Chris Harman-P28518 <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: [email-masked], [email-masked]
To: [email-masked]
Status:

 -----Original Message-----
From: [email-masked]
Sent: Wednesday, November 19, 1997 7:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: OCSP Questions

Carlisle,

What an amazing fast response ! May be we should not go so fast, so that
the list can follow the exchanges.

Agreed!

> Hi Denis,
>
> >----------
> >From:  Denis Pinkas[SMTP:[email-masked]]
> >Sent:  Tuesday, November 18, 1997 6:30 PM
> >To:    Carlisle Adams
> >Cc:    Rob Zuccherato; [email-masked]'; [email-masked]'
> >Subject:       Re: OCSP Questions
> >
> >Carlisle,
> >
> >I have had a lenghty discussion earlier on that topic with Mike. I
> >am/was also thinking that validating a path (instead of a certificate)
> >would be a good thing. We came to the conclusion that validating a
path
> >is much more complicated than validating a single certificate. The
> >argument from Mike was that the verification of a single certificate
was
> >simple, useful and could lead to a document soon. On the contrary,
path
> >validation requires more information to be defined and passed. This
> >could be the topic of another draft or another version of the
document.
> >
> >Basically the complication comes from the fact that the trust
conditions
> >must be indicated, so that the path validation can take place.
>
> Does this argument really hold any water?  Is there really a defensible
> reason why you need trust conditions for a path but not for a single
> certificate?

There is a reason. For a single certificate you ask to a representative
of the CA. The trust conditions are not necessary: you simply ask
whether the certificate is or is not revoked. I assume that the naming
constraints are checked locally, not by the server (this is the current
approach of the OCSP). For a chain, you ask to a trusted verifier (not a
representative of a CA) and thus you need to indicate your trust
conditions, this includes trust points and naming constraints.

I think apples and oranges are being mixed here.  As Carlisle has
previously pointed out, there's a difference between checking the
revocation status of a cert and checking the validity of a cert (that is,
if it's not revoked, can we use it for some purpose?) The difference is
not nit-picking.  Can we clearly define and separate the two functions?
 The first is independent of any previous certificates in the
certification path, whereas the latter generally is not.  If OCSP
performs the latter function for an entire chain, then to be useful the
initial trust conditions must be supplied by the client (either
explicitly, or by the definition of an implicit default) and verification
must be performed by a trusted third party.

Asking an OCSP server to check the validity of (as opposed to checking
the revocation status of) a single certificate doesn't seem very useful
unless it can build a complete certification path and account for
constraints imposed by certs earlier in the path.  The current state of
the constraints could be passed with each request to verify a single cert
in a path, but that's inefficient and there's a question of whether an
OCSP server run by a CA could be trusted to honor any constraints imposed
upon it.

<stuff deleted>

To help clear up my confusion, could someone (Mike Myers?) clarify the
intent of the Oct 14 OCSP spec?  Is an OCSP server supposed to:

1. Check the revocation status of a single certificate?
2. Check the validity of a single certificate without building a cert
path (in which case, the meaning of "validity" needs to be well-defined)?
3.  Check the validity of a single certificate by bringing in other certs
as required, building a certificate path, and following the procedure
defined in section 6 of PKIX-1?

Sorry for jumping in like this.

Chris Harman
Motorola

Date:         Wed, 19 Nov 1997 11:33:56 -0700
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: [email-masked]
To: [email-masked]
Status:

>Hi Bob,
>
>As usual, you raise a number of interesting points.
>
>>(I may be about to reinvent the notary protocol that Rich Ankney has
>>discussed, I believe -- if so, great minds obviously run along the same
>>lines. :-)
>
>I would ask that you take a look at
>
>   ftp://ds.internic.net/Internet-drafts/draft-adams-notary-00.txt
>
>It seems to me that much of what you're looking for is accommodated in
>that protocol.  I'd be interested to hear any comments you might have.
>
Carlisle, I apologize for misattributed your notary protocol to Rich.

I've posted my original note and your notary draft RFC  and the comments
below to the DIGSIG list, where I hope we will get some useful reaction
regarding the legal and business model issues.  I summarize the responses I
get for you.

Bob

------

The IETF-PKIX working group has been working on a protocol called Online
Certificate Status protocol (OCSP), which (as I understand it, not having
followed the effort in detail) provides a way of getting a quick yes or no
answer to the question of whether a certificate is valid at the moment.

In the attached e-mail message, I essentially challenged the group to
consider whether this effort was worth the candle, since I believe a number
of people are in agreement that a closed loop insurance model is probably
what is really needed to provide nonrepudiation and to fix some of the
problems caused by the lack of knowledge by the CA of what is going on with
a given key pair, at least of high value transactions.

Carlisle Adams of Entrust, and Rich Ankney of CertCo, seem to be more or
less in basic agreement with that approach, but may have different opinions
about the tactics used to get there. Carlisle, in particular, has written an
IETF draft of a notary service, which would allow a trusted third party to
notarize a given transaction.

However, notarization and transaction insurance are not the same thing, and
I think would imply two rather different business models.  In addition, the
notarization model probably does not accumulate the necessary state
information about how often a key pair has been used, or how many times a
given digital signature has been validated, and therefore can't keep track
of cumulative reliance limits.  Nonetheless, Carlisle's draft, which is
available at
ftp://ds.internic.net/Internet-drafts/draft-adams-notary-00.txt and which
I have included for convenience is interesting, and worth considering.

I would appreciate any comments on the legal and business model implications
of these two different approaches, and will pass them on appropriately.

Bob

Date:         Wed, 19 Nov 1997 11:40:19 -0500
Reply-To: [email-masked]
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      [IETF-PKIX] PKIX ASN.1
To: [email-masked]
Status:

Apologies if this has already been discussed.

The current drafts of the PKIX ASN.1 contain invalid syntax.
The ASN.1 defintions mix ASN.1:1988/90 and the current standard,
ASN.1:1994. By my reading, the current standard states that the two
can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and
current ASN.1 notation":

 "Both the ASN.1-88/90 and the current ASN.1 notation specify a
 top-level syntactic construct which is an ASN.1 module. A user of
 ASN.1 writes a collection of ASN.1 modules, and may import
 definitions from other ASN.1 modules."

 [snip PHG]

 "Where a module conforms to the ASN.1-88/90 notation, type and value
 references may be imported from a module that was defined using the
 current notation. Such types and values must be associated with types
 that can be defined using only the ASN.1-88/90 notation. For example,
 a module written using the ASN.1-88/90 notation cannot import a value
 of type UniversalString, since this type is defined in the current
 notation but not in ASN.1-88/90;  it can, however, import values whose
 types are, for example, INTEGER, IA5String, etc."

Both BMPString and UniversalString are types defined only in the
current standard, ASN.1:1994. PKIX uses BMPString in code that uses
the superceded ANY DEFINED BY, which is described in Annex I of the
current standards, but is not an integral part of the ASN.1 standards.
X.208 does not define type BMPString. Such ASN.1 usage will certainly
break tools that correctly implement the ASN.1 standards.

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:         Wed, 19 Nov 1997 11:34:27 -0500
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [email-masked]
To: [email-masked]
Status:

> From [email-masked] Tue Nov 18 12:48:21 1997
> Date: Tue, 18 Nov 1997 12:51:22 -0500
> From: "Simonetti David" <[email-masked]>
> To: "David P. Kemp" <[email-masked]>, IETF-PKIX <[email-masked]>
> Subject: Re: digitalSignature vs. nonRepudiation
>
> Dave K.,
>
> I agree with all of your statements except for your conclusion...
>
> <snip>
>
> > If one claims that one cannot do nonrepudiation without integrity and
> > therefore every certificate with bit 1 set must also have bit 0 set,
> > then it becomes impossible to specify a keyUsage which is valid for
> > S/MIME message signing but not valid for TLS authentication.  This
> > is the undesirable outcome of that line of reasoning.
>
> If I'm not mistaken, you're saying that the certificate to be used with
> S/MIME signature validation will only include the "nonRepudiation" bit,
> and the certificate used for TLS authentication will only include the
> "digitalSignature" bit.

No. Without the proposed restriction, a certificate may contain any
combination of the two bits: 00, 01, 10, 11.

> So, if my application is performing TLS authentication, but the public
> key cert has "nonRepudiation" set, my application must reject the
> certificate because the cert can't be used for authentication(?!).

No, the application that is performing TLS only wants to know if the
cert is valid for authentication, so it checks only the DS bit.  It
ignores the NR bit.

An application that is performing S/MIME signatures only wants to know
if the cert is valid for NR, and checks only the NR bit, and ignores the
DS bit.

A CA and an associated community of users who don't care about the
distinction would routinely issue certs with both bits set, to enable
both purposes.  But we should retain the freedom for CAs/users who *do*
care, to set only the bit(s) appropriate for their application(s).

-----

Under the proposed restriction, should an S/MIME application accept or
reject a certificate that violates the restriction (has NR set and DS
clear)?

Date:         Wed, 19 Nov 1997 10:27:40 -0500
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Hi Bob,

As usual, you raise a number of interesting points.

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, November 18, 1997 6:35 PM
>To:    Carlisle Adams; Rob Zuccherato; [email-masked];
>[email-masked]
>Subject:       Re: RE: OCSP Questions
>
>Carlisle, et al:
>
>I haven't been following this argument, and/or the entire OCSP discussion,
>as closely as I probably should have been, but I am troubled by the overall
>design assumptions and the direction this is going.  I don't think that the
>proposed protocol meets the requirements of the business model.
>
>If I understand correctly, OCSP is designed solely to provide an online
>validation of a certificate, yes/no, rather than having to request CRLs
>(which tell you more than you need to know) every time you want to validate
>a signature. At the expense of a "pull" transaction, it at least provides an
>up to the second response.
>
>I can understand that motivation, perhaps, but it really doesn't solve the
>larger nonrepudiation problem. And since I will argue we reasonably could
>solve the nonrepudiation problem with the same amount of effort, I would
>argue that we ought to at least think about it.
>
>(I may be about to reinvent the notary protocol that Rich Ankney has
>discussed, I believe -- if so, great minds obviously run along the same
>lines. :-)

I would ask that you take a look at

   ftp://ds.internic.net/internet-drafts/draft-adams-notary-00.txt

It seems to me that much of what you're looking for is accommodated in
that protocol.  I'd be interested to hear any comments you might have.

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

Date:         Wed, 19 Nov 1997 09:53:02 -0500
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: Rich Ankney <[email-masked]>
To: [email-masked]
Status:

Hi Rich,

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Wednesday, November 19, 1997 8:26 AM
>To:    Carlisle Adams; Rob Zuccherato; Bob Jueneman; [email-masked];
>[email-masked]
>Subject:       Re: RE: OCSP Questions
>
>In response to Bob's discussion on support for certificate chain validation,
>reliance limits, etc.:
...
>I think the best approach is to get OCSP out the door as is, and start work
>on a new protocol which addresses your (actually our) concerns.  This can
>be based on the notary protocol (draft by Carlisle and Rob available at the
>usual sites).  But this is separate from the current OCSP protocol; e.g.
>reliance limits require this new server to maintain state (unlike OCSP).

I'm very reluctant to get OCSP out the door "as is" until it is fixed up
to actually be secure.

If the protocol strives to provide timely revocation status information
on a single certificate, but leaves the door wide open for replay
attacks, then it does not deliver the only service it claims to provide.
 Does it make sense to get this out the door as is?

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

Date: Tue, 18 Nov 1997 17:37:38 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: OCSP Questions
Status:

Carlisle,

What an amazing fast response ! May be we should not go so fast, so that
the list can follow the exchanges.

> Hi Denis,
> 
> >----------
> >From:  Denis Pinkas[SMTP:[email-masked]]
> >Sent:  Tuesday, November 18, 1997 6:30 PM
> >To:    Carlisle Adams
> >Cc:    Rob Zuccherato; [email-masked]'; [email-masked]'
> >Subject:       Re: OCSP Questions
> >
> >Carlisle,
> >
> >I have had a lenghty discussion earlier on that topic with Mike. I
> >am/was also thinking that validating a path (instead of a certificate)
> >would be a good thing. We came to the conclusion that validating a path
> >is much more complicated than validating a single certificate. The
> >argument from Mike was that the verification of a single certificate was
> >simple, useful and could lead to a document soon. On the contrary, path
> >validation requires more information to be defined and passed. This
> >could be the topic of another draft or another version of the document.
> >
> >Basically the complication comes from the fact that the trust conditions
> >must be indicated, so that the path validation can take place.
> 
> Does this argument really hold any water?  Is there really a defensible
> reason why you need trust conditions for a path but not for a single
> certificate?  

There is a reason. For a single certificate you ask to a representative
of the CA. The trust conditions are not necessary: you simply ask
whether the certificate is or is not revoked. I assume that the naming
constraints are checked locally, not by the server (this is the current
approach of the OCSP). For a chain, you ask to a trusted verifier (not a
representative of a CA) and thus you need to indicate your trust
conditions, this includes trust points and naming constraints.

> Let's look at this more closely.
> 
> a) Assume (as is the case) that there is no way to specify trust
> conditions in OCSP "because" OCSP was designed only for single
> certificates.  All this means is that when I have a chain of length 5 to
> validate, I will use OCSP 5 times (once for each certificate).  Guess
> what?  I've checked the chain and I didn't mention trust conditions in
> the protocol anywhere.

I make a difference between a CHAIN of five certificates issued by five
different CAs and a SET of five certificates from the same CA. 

> b) Assume, on the other hand, that OCSP is modified to allow the input
> of trust conditions "because" it is modified to allow validation of
> chains.  Guess what?  A trust condition on a chain is used in the
> following way:  the condition is applied successively to each
> certificate in the chain to see if it is satisfied.

No. See above.

> The conclusion is that trust conditions need to be there anyway
> (implicitly or explicitly, although explicitly is preferable),
> regardless of whether you're checking a single certificate or a chain of
> certificates.  

>        Furthermore, for large-scale environments (like IPKI), it
> will be fairly common that users need to check certificate chains
> (rather than isolated certificates).  

I strongly agree with you on this point.

>                              I think that whatever protocol we
> develop for on-line certificate status checking needs to accommodate
> both trust conditions and chains.  

I do not disagree with you.  :-)

> There isn't really a reason to leave both out.
> 
> >There
> >several ways to tackle the problem. For example, indicate an OID for the
> >trust conditions or explicitly define these trust conditions. Using the
> >OID is simple from a protocol point of view but hides the complexity of
> >the problem.
> 
> Agreed.  A good compromise, therefore, is to have an optional OID.  The
> protocol benefits from the simplicity of a trust condition / policy OID,
> when such things are more well-defined, better understood, more common,
> etc..  Until then, the OID can be omitted if desired, implying no trust
> conditions 

"No trust condition" does not apply for a chain.

> (or implying default trust conditions, if these are defined
> in the spec., although we probably don't want to go down this path at
> the moment).

They cannot be defined in a spec.

> This is why the Notary protocol has an optional PolicyInformation
> (defined in PKIX-1) field in the request.
> 
> >Anyway, I agree with you, i.e. it would be useful and more "scalable",
> >but this does not preclude the verification of a single certificate, as
> >it is the intent of the current specification.
> 
> My opinion is that we should not sacrifice utility and generality for
> the sake of expediency if these can easily be achieved.  Trust
> conditions and path validation should both be included in the protocol
> as options, as is done in the Notary protocol.

This does not mean that the current simple protocol should not be
supported. Looking more carefully, it will be used by the "path
validation server" to ask to the various CAs representatives whether
their certificates are valid.

However, having the OID is only the visible part of the iceberg. If the
OID is optional, most people will not give any value and (for a path)
will therefore use the default policy (i.e; trust conditions). If the
OID is present, it allows to select between different trust conditions.
In that case, having some management APIs to define the OID, i.e. the
trust conditions would be most useful, ... but not a simple task.

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:         Wed, 19 Nov 1997 06:12:56 -0800
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] testing new listserv software
To: [email-masked]
Status:

pls ignore, delete, etc.

--
____________________________________________r. j. "jeff" sanders________
_________________________________tandem computers - a compaq company____
"...let everybody get together then and we'll try to make it." - H. Wolf

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: OCSP Questions
Date: Tue, 18 Nov 1997 12:17:08 -0500
Status:

Hi Denis,

>----------
>From: 	Denis Pinkas[SMTP:[email-masked]]
>Sent: 	Tuesday, November 18, 1997 8:37 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: OCSP Questions
>
>> Hi Denis,
>> >Basically the complication comes from the fact that the trust conditions
>> >must be indicated, so that the path validation can take place.
>> 
>> Does this argument really hold any water?  Is there really a defensible
>> reason why you need trust conditions for a path but not for a single
>> certificate?  
>
>There is a reason. For a single certificate you ask to a representative
>of the CA. The trust conditions are not necessary: you simply ask
>whether the certificate is or is not revoked. I assume that the naming
>constraints are checked locally, not by the server (this is the current
>approach of the OCSP). For a chain, you ask to a trusted verifier (not a
>representative of a CA) and thus you need to indicate your trust
>conditions, this includes trust points and naming constraints.

This argument makes sense until you see the flaw:  "For a single
certificate you ask to a representative of the CA....  For a chain, you
ask to a trusted verifier (not a representative of a CA)".  This assumes
that the OCSP responder (for the single certificate case) will *always*
be the representative of a CA.  But the current draft is written so that
the OCSP responder can be an arbitrary entity with its own certificate
(i.e., a trusted verifier).  If this is the case, then you need to
specify trust conditions whether the request is for a single certificate
or for a chain.

Now Mike said recently that he thought the non-CA case was perhaps too
complicated, so maybe he will remove this possibility from the draft (so
that an OCSP responder is always a representative of a CA).  But does it
actually make sense to force every CA provider in the IPKI to also build
an OCSP responder?  (Note that if even one CA provider doesn't do this,
then you have certificates whose status can't be checked, so the whole
point of this protocol starts to fall apart).  Does it not make more
sense to allow the notion of trusted verifiers, so that somebody that
wants to build such a box can do so (independently of any particular CA)
and service a (large or small) segment of the IPKI?  But trusted
verifiers necessitates the input of trust conditions...

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

Date:         Wed, 19 Nov 1997 08:26:29 -0500
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

In response to Bob's discussion on support for certificate chain
validation,
reliance limits, etc.:

These are all very important features which some protocol needs to provide,
but OCSP as it stands is also useful for "low-value" applications.  (Mike
likes to use the example of the Exploder ActiveX control.)  Not all
certificates
are used for high-value funds transfers (just the interesting ones :-)

I think the best approach is to get OCSP out the door as is, and start work
on a new protocol which addresses your (actually our) concerns.  This can
be based on the notary protocol (draft by Carlisle and Rob available at the
usual sites).  But this is separate from the current OCSP protocol; e.g.
reliance limits require this new server to maintain state (unlike OCSP).

Regards,
Rich

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: oops... please ignore
Date: Tue, 18 Nov 1997 12:56:17 -0500
Status:

oops.. sent the subscription off to the wrong address.

Please do not fill my mailbox up with advice on
how to subscribe to mailing lists...

mea culpa.

        Phill

Date:         Wed, 19 Nov 1997 00:33:47 -0800
Reply-To: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
Sender: "IETF mailing list to discuss an X.509-based public key infrastructure (PKI)" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Questions
Comments: To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

As Mike points out, narrowly-defined OCSP fails to address the points you
highlighted, and others.  Properly designed, however, OCSP mechanisms
become useful building blocks in constructing those layers.

For instance, Xcert developed its OCSP using secure LDAP.  Although it is
being widely used in the narrow certificate validation sense, we have long
been presenting examples of its use in the broader sense (i.e., returning
values of attributes for which the inquirer has specific authority, like
the Date of Birth of the bearer of the certificate, or his/her Age, or the
amount of available credit in a server-side stored value account, or simply
a statement to the effect that there is "enough" credit available to carry
out the contemplated transaction, etc...)

I just jumped into this thread, but I trust that these issues are being
addressed and that narrow-OCSP will emerge from the standards track as
something we can all use as the starting point for agreement on higher-level
functional protocols.

Andrew

At 16:35 11/18/97 -0700, Bob Jueneman wrote:
>Carlisle, et al:
>
>I haven't been following this argument, and/or the entire OCSP discussion,
>as closely as I probably should have been, but I am troubled by the overall
>design assumptions and the direction this is going.  I don't think that the
>proposed protocol meets the requirements of the business model.
>
>If I understand correctly, OCSP is designed solely to provide an online
>validation of a certificate, yes/no, rather than having to request CRLs
>(which tell you more than you need to know) every time you want to validate
>a signature. At the expense of a "pull" transaction, it at least provides an
>up to the second response.
>
>I can understand that motivation, perhaps, but it really doesn't solve the
>larger nonrepudiation problem. And since I will argue we reasonably could
>solve the nonrepudiation problem with the same amount of effort, I would
>argue that we ought to at least think about it.
>
...
>I therefore argue that the OCSP protocol is asking (and answering) the wrong
>question.  The more relevant question is not "Is this certificate valid?"
>Instead, the real question is, "Is this transaction (which I the relying
>party value at X-kilobucks), a commercially reasonable transaction based on
>the evidence at hand?"
>
...
>I hope it's not too late to change the basic OCSP paradigm, but I don't
>think it does enough to solve the basic problem to be worth implementing.
>
>Your thoughts?
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]

--------------------------------------------------------------
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, 18 Nov 1997 16:35:40 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE: OCSP Questions
Status:

Carlisle, et al:

I haven't been following this argument, and/or the entire OCSP discussion,
as closely as I probably should have been, but I am troubled by the overall
design assumptions and the direction this is going.  I don't think that the
proposed protocol meets the requirements of the business model.

If I understand correctly, OCSP is designed solely to provide an online
validation of a certificate, yes/no, rather than having to request CRLs
(which tell you more than you need to know) every time you want to validate
a signature. At the expense of a "pull" transaction, it at least provides an
up to the second response.

I can understand that motivation, perhaps, but it really doesn't solve the
larger nonrepudiation problem. And since I will argue we reasonably could
solve the nonrepudiation problem with the same amount of effort, I would
argue that we ought to at least think about it.

(I may be about to reinvent the notary protocol that Rich Ankney has
discussed, I believe -- if so, great minds obviously run along the same
lines. :-)

>From my point of view, the problem in this area hasn't changed since Sead
Muftic and I discussed the issue two or maybe even three years ago.

Knowing whether or not a certificate is or was valid, or even an entire
certificate chain, at some particular instant does practically nothing to
provide long-term nonrepudiation, because it is still necessary to have that
response reliably timestamped by a trusted third party, and also to get the
particular digital signature involved timestamped, either by one or two
different trusted third parties, and then to archive both responses in case
a question arises.  Then, presumably, you could show that the certificate
chain was valid after the creation of the digital signature in question.,
and hence was presumably valid at the time.

But this is a lot of additional work, it involves numerous protocols that
haven't been architected, and it generally does a half-baked job of solving
the problem.

In addition, this scheme fails to solve the basic problem with reliance
limits and other measures designed to limit the potential liability of
either the CA or the subscriber/subject, or both, in the event of a key
compromise or unauthorized use, because it provides no way of tallying the
accrued dollar volume of transactions that are being validated against a
particular digital signature, nor the number of transactions and the
aggregate value that have been validated against a given certificate.

In the existing PKI model, the CA is completely clueless about the number of
times that the subscriber uses his private key to sign something, and the CA
is also incapable of controlling or limiting the number of signatures
created, even by the subscriber, much less by someone who steals the key.

In addition, even the subscriber/signer may not know how many times a
particular digital signature is validated, e.g., in the case of a software
module that is created and signed by Microsoft, but may be validated
millions of times by people all over the world. From this perspective, the
CA has potentially infinity squared liability, if someone might sue for some
error or omission in the certificate.

And finally, the subscriber might also face essentially unlimited liability
if his private key were compromised and the compromise was not discovered in
a timely fashion.  this is true even if the reliance limit were as low as
$1.00, since there are no controls over the frequency or use or the
aggregate dollar value.

The real issue, and the source of countless megabytes of legal wrangling
over who should be either the beneficiary or victim of a rebutable
presumption as to the correctness of a digital signature, is that the basic
PKI system was designed to run open loop, without the CA being involved or
even knowledgeable about the total transaction volume, nor, in some cases
even the signer.

I therefore argue that the OCSP protocol is asking (and answering) the wrong
question.  The more relevant question is not "Is this certificate valid?" 
Instead, the real question is, "Is this transaction (which I the relying
party value at X-kilobucks), a commercially reasonable transaction based on
the evidence at hand?"

Or much better yet:

Request:  "I value the enclosed digital signature (and the transaction which
it represents) as worth X-kilobucks.  Please INSURE this signature against
errors and omissions as defined in your standard policy (perhaps including a
compromise of the signer's key) against any losses that might be cause by my
relying on that signature, up to the limit of the transaction valuation I
have placed on it.  In exchange, I agree to pay Y % of the said transaction
valuation, in accordance with your standard fee schedule. Signed
(digitally), RP (relying party).

Response 1:  "The digital signature enclosed , together with its certificate
chain up to the enclosed self-signed root certificate, appears to be valid
as of this moment (date/time), and is hereby insured for X-kilobucks in
accordance with our standard terms and conditions. You will be billed
accordingly. Digitally signed, TTP."

Or, Response 2.  "The digital signature enclosed does not appear to be valid
as of (date/time), for one or more of the following reasons (excessive
frequency of usage, in excess of per-transaction reliance limit, in excess
of per certificate reliance limit, certificate suspended, certificate
revoked, or certificate expired). You will be billed our standard rate for
reporting invalid transactions. Digitally signed, TTP."

Note that in this case it matter no one whit whether the trusted third party
is one of the CA's in the certificate chain, or a completely independent
agency.  As long as they are willing to issue the necessary insurance, and
have deep enough pockets to be credible, the relying party doesn't care
whether the TTP asks the CA(s) or uses divining rods or the oracle at Delphi
in order to obtain the answer. It is still necessary for the relying party
to periodically confirm the validity of the trusted third party's digital
signature to be absolutely confident, but it should be sufficient to collect
a routine CRL for that purpose once a month or so. 

I hope it's not too late to change the basic OCSP paradigm, but I don't
think it does enough to solve the basic problem to be worth implementing.

Your thoughts?

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."

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: [email-masked]
Date: Tue, 18 Nov 1997 09:27:52 -0700
To: Carlisle Adams <[email-masked]>, [email-masked]
Subject: RE: OCSP Questions
Status:

Carlisle--

It would be beneficial to agree on the top level requirement(s) OCSP is
intended to address.  Simply stated, OCSP is a simple ping-type service
intended to address one and only one requirement:

"Provide a means to quickly and easily determine in an online fashion the
current revocation state of a certificate."

That is, Iit answers one question and only one question:  Is this
certificate valid or not?  It specifically stops short of what might be
considered an Attribute Validation and Generalized Trust Model Protocol.
This type of protocol casts a much wider net.

Mechanisms that enhance the use of digital signatures, such as the Notary
proposal or some other more generlized transaction protocol, are well
beyond the scope of the OCSP proposal.  That said, the utility of such
functions towards promoting reliance on a PKI are unquestioned.

It's very clear at this point that there is no single answer to revocation.
 Consequently, a layered approach is the best approach here.  Any processor
of a Notary transaction must I presume perform a certificate path
validation process.  This process will either involve reference to a CRL,
possibly a Certificate Revocation Tree where CRL size is an issue or an
OCSP service where timeliness is an issue.

We should enable implementors of the Notary protocol to choose their
revocation model.  The trajectory of the current dialog is headed towards
foreclosing that option.

--Mike

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: subscribe [email-masked] ietf-pkix 
Date: Tue, 18 Nov 1997 12:45:19 -0500
Status:

subscribe [email-masked] ietf-pkix 

Date: Tue, 18 Nov 1997 14:53:11 -0600
From: Chris Harman-P28518 <[email-masked]>
Subject: RE: OCSP Questions
To: [email-masked], [email-masked], [email-masked]
Status:

Carlisle Adams wrote:
>>----------
>>From:  [email-masked][SMTP:[email-masked]]
>>Sent:  Tuesday, November 18, 1997 11:27 AM
>>To:  Carlisle Adams; [email-masked]
>>Subject:  RE: OCSP Questions
>>
>>Carlisle--
>>
>>It would be beneficial to agree on the top level requirement(s) OCSP is
>>intended to address.  Simply stated, OCSP is a simple ping-type service
>>intended to address one and only one requirement:
>>
>>"Provide a means to quickly and easily determine in an online fashion   
the
>>current revocation state of a certificate."
>>
>>That is, Iit answers one question and only one question:  Is this
>>certificate valid or not?
>
>"Valid" can imply a number of things, so I might re-word this as:  "Has
>this certificate been revoked or not?", but perhaps this is nit-picking.

I don't think it is nit-picking, as this very issue confused me.  The   
OCSP spec implies it does
more than simple revocation checking (it mentions Section 6 of PKIX-1),   
yet the protocol seems inadequate for doing much more than this.  To   
perform full validation of a single certificate, the current state (the   
internal variables defined in section 6) of the certificate path   
verification process must be exchanged with the OCSP server.  If the   
current definition of OCSP is capable of anything less than full   
validation, I think its limitations should be clearly stated in the   
specification.

Chris Harman
Motorola

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP Questions
Date: Tue, 18 Nov 1997 13:34:05 -0500
Status:

Hi Mike,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Tuesday, November 18, 1997 11:27 AM
>To: 	Carlisle Adams; [email-masked]
>Subject: 	RE: OCSP Questions
>
>Carlisle--
>
>It would be beneficial to agree on the top level requirement(s) OCSP is
>intended to address.  Simply stated, OCSP is a simple ping-type service
>intended to address one and only one requirement:
>
>"Provide a means to quickly and easily determine in an online fashion the
>current revocation state of a certificate."
>
>That is, Iit answers one question and only one question:  Is this
>certificate valid or not?  

"Valid" can imply a number of things, so I might re-word this as:  "Has
this certificate been revoked or not?", but perhaps this is nit-picking.

>It specifically stops short of what might be
>considered an Attribute Validation and Generalized Trust Model Protocol.
>This type of protocol casts a much wider net.

Fair enough.  Let's be as simple as we possibly can and assume that all
the generality and complexity can be added in later (if desired) in a
layered fashion.

Do you agree, however, that if this protocol is insecure then all the
layering in the world won't help?  

Do you agree that cryptographically binding requests to responses is
necessary to make it secure (i.e., that any pre-creation and caching of
signed responses leaves the protocol open to replay attacks)?  

Do you agree that without pre-creation and caching this protocol could
have difficulty securely scaling to large environments (particularly in
the scenario you envision in which there is a small number of CAs
(possibly only one) and each OCSP responder is not an arbitrary trusted
verifier but instead represents a particular CA)?

By all means, let's keep it simple.  But let's also make sure that it
actually meets the requirements.

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

Date: Tue, 18 Nov 1997 12:51:22 -0500
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: "David P. Kemp" <[email-masked]>, IETF-PKIX <[email-masked]>
Subject: Re: digitalSignature vs. nonRepudiation
Status:

Dave K.,

I agree with all of your statements except for your conclusion...

<snip>

> If one claims that one cannot do nonrepudiation without integrity and
> therefore every certificate with bit 1 set must also have bit 0 set,
> then it becomes impossible to specify a keyUsage which is valid for
> S/MIME message signing but not valid for TLS authentication.  This
> is the undesirable outcome of that line of reasoning.  

If I'm not mistaken, you're saying that the certificate to be used with
S/MIME signature validation will only include the "nonRepudiation" bit,
and the certificate used for TLS authentication will only include the
"digitalSignature" bit.  

So, if my application is performing TLS authentication, but the public
key cert has "nonRepudiation" set, my application must reject the
certificate because the cert can't be used for authentication(?!).  I
don't think that most CAs will be as well-versed in the key usages as
you and I to be able to determine that their non-repudiation key is not
valid for authentication and integrity, and I'm not certain the
applications will make such a distinction.  

If you really want to differentiate certificates based on applications,
I'd recommend the registering of Extended Key Usage OIDs for the
respective applications, e.g., "TLS Authentication".

> An even more
> undesirable outcome is that it becomes impossible to designate a key
> solely for the purpose of issuing certificates -- that key must also
> have the DS and NR bits set.  I would prefer that a CA have the option
> of restricting one key to just signing certs, and use a different key
> for communicating.

I don't follow.  Just set the "certSign" bit in one cert, and in another
cert set the "digital signature" and "nonRepudiation" bits.  I have no
problem with this.

Dave Simonetti

From: "Charles Blauner"<[email-masked]>
To: [email-masked] ("Simonetti David")
cc: [email-masked]
Date: Tue, 18 Nov 1997 10:02:23 -0400
Subject: Re: digitalSignature vs. nonRepudiation
Status:

David;

Maybe my reply is based in ignorance, but I would tend to agree that if
your set
non-repudiation , that it implies that digital signature should also be
set.

My ignorant question is what the purpose of non-repudiation is within this
scope.

In my simple mind, I view non-repudiation as a combination of digital
signatures,
secure time, and a secure audit facility for storage of evidence. The only
possiblity
that I can see for having a non-repudiation bit set is that addional
information is provided
to the requestor to create sufficient evidence (like the full CRL list and
the complete
cert chain) above and beyond what you would get by just setting the digital
signature flag.

Charles

simonetti_david @ bah.com ("Simonetti David") on 11/17/97 03:45:27 PM

To:   ietf-pkix @ tandem.com @ SMTP
cc:
Subject:  digitalSignature vs. nonRepudiation

I am attempting to implement the key usages as defined for the keyUsage
extension.  I am stumbling upon digitalSignature and nonRepudiation.
I define the key usage digitalSignature as a public key which affords
the services of authentication and data integrity.
Of course, nonRepudiation affords the service of non-repudiation.
My question is, with only nonRepudiation set (and not digitalSignature),
is it true that my public key can be used only to provide the service of
non-repudiation, and NOT the services of authentication and data
integrity?  If this is true, I'm curious to know how this is
implemented.
I claim that if the nonRepudiation bit is set, that I can use that key
to implement authentication and data integrity, and also claim
nonRepudiation of the originator.  Since authentication and data
integrity are services provided under digitalSignature, I believe that
when nonRepudiation is set, digitalSignature should also be set.
I'd like to hear agreements or disagreements with my line of reasoning.
Dave Simonetti

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Rob Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP Questions
Date: Tue, 18 Nov 1997 10:44:53 -0500
Status:

Hi Denis,

>----------
>From: 	Denis Pinkas[SMTP:[email-masked]]
>Sent: 	Tuesday, November 18, 1997 6:30 PM
>To: 	Carlisle Adams
>Cc: 	Rob Zuccherato; [email-masked]'; [email-masked]'
>Subject: 	Re: OCSP Questions
>
>Carlisle,
>
>I have had a lenghty discussion earlier on that topic with Mike. I
>am/was also thinking that validating a path (instead of a certificate)
>would be a good thing. We came to the conclusion that validating a path
>is much more complicated than validating a single certificate. The
>argument from Mike was that the verification of a single certificate was
>simple, useful and could lead to a document soon. On the contrary, path
>validation requires more information to be defined and passed. This
>could be the topic of another draft or another version of the document.
>
>Basically the complication comes from the fact that the trust conditions
>must be indicated, so that the path validation can take place. 

Does this argument really hold any water?  Is there really a defensible
reason why you need trust conditions for a path but not for a single
certificate?  Let's look at this more closely.

a) Assume (as is the case) that there is no way to specify trust
conditions in OCSP "because" OCSP was designed only for single
certificates.  All this means is that when I have a chain of length 5 to
validate, I will use OCSP 5 times (once for each certificate).  Guess
what?  I've checked the chain and I didn't mention trust conditions in
the protocol anywhere.

b) Assume, on the other hand, that OCSP is modified to allow the input
of trust conditions "because" it is modified to allow validation of
chains.  Guess what?  A trust condition on a chain is used in the
following way:  the condition is applied successively to each
certificate in the chain to see if it is satisfied.

The conclusion is that trust conditions need to be there anyway
(implicitly or explicitly, although explicitly is preferable),
regardless of whether you're checking a single certificate or a chain of
certificates.  Furthermore, for large-scale environments (like IPKI), it
will be fairly common that users need to check certificate chains
(rather than isolated certificates).  I think that whatever protocol we
develop for on-line certificate status checking needs to accommodate
both trust conditions and chains.  There isn't really a reason to leave
both out.

>There
>several ways to tackle the problem. For example, indicate an OID for the
>trust conditions or explicitly define these trust conditions. Using the
>OID is simple from a protocol point of view but hides the complexity of
>the problem.

Agreed.  A good compromise, therefore, is to have an optional OID.  The
protocol benefits from the simplicity of a trust condition / policy OID,
when such things are more well-defined, better understood, more common,
etc..  Until then, the OID can be omitted if desired, implying no trust
conditions (or implying default trust conditions, if these are defined
in the spec., although we probably don't want to go down this path at
the moment).

This is why the Notary protocol has an optional PolicyInformation
(defined in PKIX-1) field in the request.

>Anyway, I agree with you, i.e. it would be useful and more "scalable",
>but this does not preclude the verification of a single certificate, as
>it is the intent of the current specification.

My opinion is that we should not sacrifice utility and generality for
the sake of expediency if these can easily be achieved.  Trust
conditions and path validation should both be included in the protocol
as options, as is done in the Notary protocol.

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

Date: Tue, 18 Nov 1997 15:30:21 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: Rob Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: OCSP Questions
Status:

Carlisle Adams wrote:

> If the certificate whose status I want to check is issued by a CA that I
> already trust, then this makes sense.  In other environments (such as
> the Internet PKI, for example, which is the one for which this protocol
> was presumably designed), there will be a number of CAs (either a
> hierarchical or a cross-certification model can be used; it does not
> matter).  For such environments the revocation status of a certificate
> in isolation is of relatively little value.  What will typically happen
> is that I will have a chain of certificates (from the other party's
> cert. to a CA that I trust).  I need to know if *everything* in that
> chain is good before I can trust the certificate of the other party.  If
> this chain has a length of 5, does it really make sense for me to hit
> the OCSP responder 5 times (or hit potentially 5 different OCSP
> responders)?  Doesn't it sound more useful to allow the flexibility in
> the protocol for me to say "here's a chain:  is it good or bad?"?

(...)

> But it's not clear that, for large-scale heterogeneous environments like
> the IPKI, a protocol like OCSP can be useful unless it *is* the front
> end to a remote path validation engine.  (If it only checks individual
> certs, all that happens is that you increase network traffic n-fold,
> where n is the average length of a path.  It seems much more reasonable
> not to put this burden on the end users...)

(...)

> I'd be very interested to hear other opinions on this...

Carlisle,

I have had a lenghty discussion earlier on that topic with Mike. I
am/was also thinking that validating a path (instead of a certificate)
would be a good thing. We came to the conclusion that validating a path
is much more complicated than validating a single certificate. The
argument from Mike was that the verification of a single certificate was
simple, useful and could lead to a document soon. On the contrary, path
validation requires more information to be defined and passed. This
could be the topic of another draft or another version of the document.

Basically the complication comes from the fact that the trust conditions
must be indicated, so that the path validation can take place. There
several ways to tackle the problem. For example, indicate an OID for the
trust conditions or explicitly define these trust conditions. Using the
OID is simple from a protocol point of view but hides the complexity of
the problem.

Anyway, I agree with you, i.e. it would be useful and more "scalable",
but this does not preclude the verification of a single certificate, as
it is the intent of the current specification.

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, 18 Nov 1997 11:31:12 +0000
From: Neil Hopcroft <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: Carlisle Adams <[email-masked]>
Subject: Re: OCSP Questions
Status:

Carlisle Adams wrote:

> If the certificate whose status I want to check is issued by a CA that
> I
> already trust, then this makes sense.  In other environments (such as
> the Internet PKI, for example, which is the one for which this
> protocol
> was presumably designed), there will be a number of CAs (either a
> hierarchical or a cross-certification model can be used; it does not
> matter).  For such environments the revocation status of a certificate
>
> in isolation is of relatively little value.  What will typically
> happen
> is that I will have a chain of certificates (from the other party's
> cert. to a CA that I trust).  I need to know if *everything* in that
> chain is good before I can trust the certificate of the other party.
> If
> this chain has a length of 5, does it really make sense for me to hit
> the OCSP responder 5 times (or hit potentially 5 different OCSP
> responders)?  Doesn't it sound more useful to allow the flexibility in
>
> the protocol for me to say "here's a chain:  is it good or bad?"?

Where would such a single check be made? Presumably with the CA at the
bottom of the chain? What happens if that CA is compromised and a
crooked responder replaces the genuine responses with "Yes - this chain
is fine" responses to whatever requests are given?

Neil Hopcroft

From: [email-masked]
Subject: List server upgrade news
To: [email-masked], [email-masked], [email-masked]
Date: Mon, 17 Nov 1997 15:26:07 -0800 (PST)
Status:

All,

The list server for your mailing list is being upgraded to a
full-featured platform (LSOFT's LISTSERV v1.8c).  You may 
find information on how to use at

     http:/www.lsoft.com/manuals/userindex.html

This is just "FYI" right now.  The new software has a lot
of functionality the old did not have.  I will be coordinating
a cutover time and date for each list with each list owner and
you will be notified in advance when your list will have the
new functionality.

Until then, please do not use the address "[email-masked]"
for your subscribe/unsubscribe requests.  Use rather
"[email-masked]" and we'll get them as soon as we
can.

Thanks,
-- 
____________________________________________r. j. "jeff" sanders________
_________________________________tandem computers - a compaq company____ 
"...let everybody get together then and we'll try to make it." - H. Wolf

From: Carlisle Adams <[email-masked]>
To: Rob Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP Questions
Date: Mon, 17 Nov 1997 17:58:10 -0500
Status:

Hi,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, November 17, 1997 10:09 AM
>To: 	Rob Zuccherato; [email-masked]'
>Subject: 	RE: OCSP Questions
>
>At 11:34 AM 11/13/97 -0500, Rob Zuccherato wrote:
>>I think a lot of my difficulty with this document comes from the fact
>>that I don't really understand the model from which you are working and
>>it isn't really well defined in the document.  Perhaps this will become
>>more clear as the discussion continues.
>
>CRLs are a source of revocation information. OCSP is another means of
>acquiring more timely access to that same information.  This is pretty much
>the model.

What was meant here was security-model / trust-model; I think we all
recognize that OCSP is intended to give timely access to revocation
information...

>>Either way, one must ultimately arrive at a trusted (unrevocable) public
>>key.  This is fine if your OCSP responder is a CA, but will that always
>>be the case?  For example, if my OCSP responder is not a CA (maybe my CA
>>can't or doesn't want to handle that amount of traffic), where does my
>>responder's certificate's URL point?  Is it to the CA?  If so, the CA
>>will have to verify the responder's certificate on each OCSP response,
>>so it still has the traffic.  Would it be to another non-CA OCSP
>>responder?  Then where does it's URL point?  Or is the responder's key
>>trusted and unrevocable?  When your responder is a non-CA, I believe
>>that revocation of its public key must be possible.  The current
>>document isn't clear on this point.
>
>Would the following text provide sufficient clarification?
>
>"In the instance when an OCSP responder is not the CA that issued the
>certificate in question, the responder's certificate SHALL contain a URL
>pointing to the CA that issued the certificate to the responder."

Yes, this absolutely clarifies the fact that the OCSP responder really
must be the CA that issued the certificate in question.  If it is not,
the protocol doubles network traffic without offering any real benefit
to either the CA or the end-user (since every request to the OCSP
responder for the revocation status of a certificate must immediately be
followed by a request to the CA for the revocation status of the OCSP
responder's certificate; note that omitting the second step means that
you don't really have the revocation status for the original certificate
since you don't know if the response you got is trustworthy).

O.K., so let's assume that the OCSP responder is really the CA that
issued the certificate in question.  How does this scale to large
environments?  In order to avoid overloading the CPU, it may be
necessary for the CA to fork some of this processing off to different
processes (probably on different machines).  Since responses must be
signed, however, does this mean that the CA's private key must then be
shared over several machines (all, clearly, with Internet access)?

Am I missing something vital that makes this story sound better?

>>Fair enough, but the technical specification should allow a sound trust
>>relationship to be defined.  As I stated above, I am not convinced the
>>current document does this.
>
>I do not see inclusion of intermediary or ancillary CA certificates to be
>useful in this protocol.  A certificate has one and only one issuing
>authority.  Knowledge of its most current state exists in one and only one
>place.  Any further protraction of the trust model issues into worst-case
>scenarios will invoke a web of trading partner agreements the disentangling
>of which would further substantiate the need for a law degree in order to
>practice the art of PKI.

If the certificate whose status I want to check is issued by a CA that I
already trust, then this makes sense.  In other environments (such as
the Internet PKI, for example, which is the one for which this protocol
was presumably designed), there will be a number of CAs (either a
hierarchical or a cross-certification model can be used; it does not
matter).  For such environments the revocation status of a certificate
in isolation is of relatively little value.  What will typically happen
is that I will have a chain of certificates (from the other party's
cert. to a CA that I trust).  I need to know if *everything* in that
chain is good before I can trust the certificate of the other party.  If
this chain has a length of 5, does it really make sense for me to hit
the OCSP responder 5 times (or hit potentially 5 different OCSP
responders)?  Doesn't it sound more useful to allow the flexibility in
the protocol for me to say "here's a chain:  is it good or bad?"?

>I am equally convinced that if we don't solve the simple problems first, we
>won't get to state n+1.  Our client working groups and allied application
>developers shouldn't have to implement complex protocols in order to arrive
>at a simple solutions.

Agreed.  But let's design the simplest protocol we can that actually is
useful for the environment we're targeting (which, within PKIX, is the
IPKI).

>>Maybe simplicity is a good thing, but I don't think that it buys you
>>anything here.  In order to prevent replay attacks, the current time (or
>>some other unique identifier) MUST be in the response.  Otherwise, a
>>requester never knows if he/she is getting a fresh response.  So, in any
>>case, pre-production and/or caching of responses does not seem possible.
>> If I am missing something here, please let me know.
>
>The response field "time" in Section 4.2 is the time at which the response
>was signed (I shall update the draft to more adequately define the response
>fields.)  Thus responses may be pre-produced, bearing the time at which
>they were signed.  In the limit, such pre-production approaches CRLs in
>timeliness.

Having a "time" field does not solve the problem.  The problem is that
I, as a user, cannot know when next this information will get updated
(that's why the CRL has a "next issue" date within the CRL).  As soon as
you allow any caching whatsoever (*regardless* of the caching interval),
you are open to replay attacks  --  within the caching interval someone
can always replay earlier responses since the responses are not tied to
the requests.  

Perhaps you want something simple, but a well-known principle in
cryptography is that "simple and insecure is worse than nothing at all
(because people are fooled into thinking they're getting security)".

>>Well, certainly if OCSP is concerned with timeliness, then cached
>>responses are not possible.  Even if responses were cached every 10
>>minutes and included the time that they were cached, the requester
>>doesn't know how often caching occurs.  It gets back a response with
>>some past time and does not know if an update has occurred since then.
>
>Timeliness is a relative thing.  If all you had were CRLs that were
>refreshed every week, refresh intervals measured in hours would not be
>unacceptable.
>
>I must continue here to point out the one-to-one relationship between CRLs
>and OCSP.  In the limit, OCSP approaches CRLs in utility.  It is defined
>and structured however to significantly increase the likelihood, over use
>of CRLs, that one is able to detect a revoked certificate prior to relying
>on it.

You haven't increased this likelihood *at* *all* if the protocol allows
replay attacks.  With a CRL I know exactly when to check again to get
the next CRL; with this protocol I don't know when next to check the
OCSP responder.  Do I keep checking over and over again until I get a
"fresher" response?  Will people actually do this in real life?  It
seems to me that you solve these problems by binding responses to
requests, so that users always know that they're getting a fresh
response.

>Supplying supplementary CA certificates strongly suggests OCSP is intended
>to be the front end to a remote path validation engine.  This is not what
>OCSP is or should be.

But it's not clear that, for large-scale heterogeneous environments like
the IPKI, a protocol like OCSP can be useful unless it *is* the front
end to a remote path validation engine.  (If it only checks individual
certs, all that happens is that you increase network traffic n-fold,
where n is the average length of a path.  It seems much more reasonable
not to put this burden on the end users...)

>>My second
>>comment is that the issue of policy is totally ignored by this document.
>> I may want to know "Is this certificate good for my particular
>>application?", not "Is this certificate good for any application?".
>>There is not a method to do this in the protocol as proposed.
>
>There exists the notion of an authenticable identity and the parallel
>notion of the attributes associate with that identity.  Confirming the
>former and managing its current state is a straightforward task.  The
>latter has not yet yielded a broadly implemented solution.  We need to
>focus on solving the simple problems first.

By all means, let's solve the simple problems first.  By why
intentionally rule out the future?  If something like an optional policy
OID can anticipate (and meet) at least some coming requirements, why
leave it out and limit the lifetime of this protocol?

>>>Also, it's important to note that many Responders will in all likelihood be
>>>one's CA.  The trust model in this case is well defined.  Including its
>>>specification in the request inflates the size of the request with no added
>>>value.
>>
>>While it may be true that the responder may be the requester's CA, I
>>don't think that this will always be the case.  We must allow for other
>>situations.
>
>I'm coming to the conclusion that the non-CA case overly complicates the
>specification, despite the fact that I specifically amended the draft for
>this purpose.

Yes.  Let us, within the PKIX Working Group, define a protocol that
assumes that everyone in the world has the same CA (call it "V").  Even
putting aside discussion of whether or not "V" can securely scale this
service to an environment this large, is such an underlying assumption
acceptable?  My guess is "No".

Mike, I fully agree that some sort of on-line service is a necessary
supplement to CRLs.  Within the PKIX group we should be looking for
something that is simultaneously secure, scaleable to large
environments, and forward-looking enough to meet present and future
needs (acknowledging that our vision of the future is certain to be
blurry at best).  I doubt that we've hit upon the right answer yet, but
it seems to me that the Notary protocol is a lot closer to what we're
seeking than OCSP.  

I'd be very interested to hear other opinions on this...

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

Date: Mon, 17 Nov 1997 18:15:20 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: digitalSignature vs. nonRepudiation
Status:

Dave S,

I believe the question should be

  "what purposes are to be enabled by setting bits 0 and 1 in the
   keyUsage extension?",

rather than

  "what is the True Meaning of the words digitalSignature and
   nonRepudiation?"

The digital signature cryptographic mechanism can be used for many
*purposes*, including signing certs, signing CRLs, signing contracts,
signing email messages, signing various data in ISAKMP, TLS, or other
protocol exchanges, etc.

The digital signature cryptographic mechanism can be used to provide
several *security services*: data integrity, data origin authentication,
entity authentication, and non-repudiation.

All of the bits in the KeyUsage extension, with the possible exception
of NR, refer to purposes, not security services.  keyEncipherment,
dataEncipherment, keyAgreement, keyCertSign, crlSign, encryptOnly, and
decryptOnly are purposes for which the key is authorized to be used.
To be consistent, the nonRepudiation bit must refer to certain purposes
for which the NR security service is required (such as signing email),
*not* all invocations of the NR security service itself.  For example,
issuing (signing) a certificate involves the NR security service, but
keys issued solely for the purpose of signing certs don't normally have
the nonRepudiation bit set in addition to the keyCertSign bit.  The
*usage* of the key is to sign certs, regardless of the fact that the
process of signing a cert also creates data which can be used to refute
any attempted repudiation of the signature by the CA.

Which brings us to bit 0: digitalSignature.  X.509 defines this bit
as follows:

   a) digitalSignature: for verifying digital signatures that have
      purposes other than those identified in b), f), or g) below;

PKIX defines this bit as follows:

     The digitalSignature bit is asserted when the subject public key
     is used to verifying [sic] digital signatures that have purposes
     other than non-repudiation, certificate signature, and CRL
     signature.  For example, the digitalSignature bit is asserted
     when the public key is used to provide authentication.

>From a practical perspective, it is useful to issue certs for the
purpose of allowing the subject to authenticate (as in a TLS
or IPSEC connection), to attach a signature to a message (as in S/MIME),
to do both, or to do neither.  Bits 0 and 1, as defined in X.509 and PKIX,
allow these four possibilities.

If one claims that one cannot do nonrepudiation without integrity and
therefore every certificate with bit 1 set must also have bit 0 set,
then it becomes impossible to specify a keyUsage which is valid for
S/MIME message signing but not valid for TLS authentication.  This
is the undesirable outcome of that line of reasoning.  An even more
undesirable outcome is that it becomes impossible to designate a key
solely for the purpose of issuing certificates -- that key must also
have the DS and NR bits set.  I would prefer that a CA have the option
of restricting one key to just signing certs, and use a different key
for communicating.

Dave Kemp

> From: "Simonetti David" <[email-masked]>
> 
> I am attempting to implement the key usages as defined for the keyUsage
> extension.  I am stumbling upon digitalSignature and nonRepudiation.
> 
> I define the key usage digitalSignature as a public key which affords
> the services of authentication and data integrity.
> 
> Of course, nonRepudiation affords the service of non-repudiation.
> 
> My question is, with only nonRepudiation set (and not digitalSignature),
> is it true that my public key can be used only to provide the service of
> non-repudiation, and NOT the services of authentication and data
> integrity?  If this is true, I'm curious to know how this is
> implemented.
> 
> I claim that if the nonRepudiation bit is set, that I can use that key
> to implement authentication and data integrity, and also claim
> nonRepudiation of the originator.  Since authentication and data
> integrity are services provided under digitalSignature, I believe that
> when nonRepudiation is set, digitalSignature should also be set.
> 
> I'd like to hear agreements or disagreements with my line of reasoning.
> 
> Dave Simonetti
> 

From: "Rich Ankney" <[email-masked]>
To: "Simonetti David" <[email-masked]>, "IETF-PKIX" <[email-masked]>
Subject: Re: digitalSignature vs. nonRepudiation
Date: Mon, 17 Nov 1997 19:02:05 -0500
Status:

I agree with your reasoning.  I think the non-repudiation bit is most
important when it's NOT set, i.e. I want to reserve the ability to
repudiate
a message.  (SET is a good example here.)  The only combinations
that are useful are (I think) digital signature by itself, and digital
signature
plus non-repudiation.  The latter could be represented as the NR bit by
itself or the NR+DS bits.  I prefer the latter...

/ Rich

----------
> From: Simonetti David <[email-masked]>
> To: IETF-PKIX <[email-masked]>
> Subject: digitalSignature vs. nonRepudiation
> Date: Monday, November 17, 1997 3:45 PM
> 
> I am attempting to implement the key usages as defined for the keyUsage
> extension.  I am stumbling upon digitalSignature and nonRepudiation.
> 
> I define the key usage digitalSignature as a public key which affords
> the services of authentication and data integrity.
> 
> Of course, nonRepudiation affords the service of non-repudiation.
> 
> My question is, with only nonRepudiation set (and not digitalSignature),
> is it true that my public key can be used only to provide the service of
> non-repudiation, and NOT the services of authentication and data
> integrity?  If this is true, I'm curious to know how this is
> implemented.
> 
> I claim that if the nonRepudiation bit is set, that I can use that key
> to implement authentication and data integrity, and also claim
> nonRepudiation of the originator.  Since authentication and data
> integrity are services provided under digitalSignature, I believe that
> when nonRepudiation is set, digitalSignature should also be set.
> 
> I'd like to hear agreements or disagreements with my line of reasoning.
> 
> Dave Simonetti

From: [email-masked]
Date: Mon, 17 Nov 1997 08:09:32 -0700
To: Rob Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP Questions
Status:

Rob--

Ongoing dialog below.

--Mike

At 11:34 AM 11/13/97 -0500, Rob Zuccherato wrote:
>Mike;
>
>I think a lot of my difficulty with this document comes from the fact
>that I don't really understand the model from which you are working and
>it isn't really well defined in the document.  Perhaps this will become
>more clear as the discussion continues.

CRLs are a source of revocation information. OCSP is another means of
acquiring more timely access to that same information.  This is pretty much
the model.

>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	Wednesday, November 12, 1997 11:33 AM
>>To: 	Rob Zuccherato; [email-masked]'
>>Subject: 	Re: OCSP Questions
>>
>>At 01:43 PM 11/10/97 -0500, Rob Zuccherato wrote:
>>>1. In Section 3.1 it appears that CAs must include in certificates the
>>>URI of the OCSP responder that end entities are to use for the
>>>certificate.  I guess that this means the URI must appear in the
>>>responder's certificate (in SubjectAltName?) in order for end entities
>>>to match responders with certificates.  Even so, what value would appear
>>>in the AuthorityInfoAccess field of an OCSP responders certificate?
>>>Certainly it could not be its own URI, since then revocation would be
>>>impossible.  So it must be the URI of some other responder.  But then
>>>what goes in the AuthorityInfoAccess field of that responders
>>>certificate?  Where does this chain end?  This is a nontrivial question
>>>because whenever I verify a signature on an OCSP response I will have to
>>>follow this chain.  In our Notary protocol we decided that it was not a
>>>good idea to include the information about which server to use in the
>>>certificate.  It is left up to the end entity which Notary to use. Also,
>>>the Notaries must have the extended key usage field extension in their
>>>certificates indicating that they are Notaries.  This way if things go
>>>wrong, the certificates can be revoked and placed on ARLs and end
>>>entities aren't tied to one service.  
>>
>>I agree--this is a nontrivial question.
>>
>>A CA's certificate shouldn't contain a reiteration of the OCSP URL
>>contained in its subscribers' certificates.  Conversely, the OCSP
>>specification does not preclude placing into CA certificate a URL that
>>enables access to superior CA's OCSP services.  Ultimately one arrives at a
>>trusted public key.
>>
>>The non-CA case is more interesting.
>
>Yes, it is.
>>
>>Relying parties are not technically constrained by OCSP from relying upon a
>>different URL.  However, assuming a well-defined trust model between a
>>subscriber's certificate and the CA that issued it, the apportionment of
>>liablity is less clear in the case of non-CA OCSP Responders.  Perhaps
>>liability is apportioned by contract, and the relying parties configure
>>their "OCSP Responder" URL in their applications accordingly. Perhaps it's
>>by organizational fiat--thou shalt use the corporate OCSP Responder.
>>Again, one performs a local configuration to point to the corporate OCSP
>>Responder.
>
>Either way, one must ultimately arrive at a trusted (unrevocable) public
>key.  This is fine if your OCSP responder is a CA, but will that always
>be the case?  For example, if my OCSP responder is not a CA (maybe my CA
>can't or doesn't want to handle that amount of traffic), where does my
>responder's certificate's URL point?  Is it to the CA?  If so, the CA
>will have to verify the responder's certificate on each OCSP response,
>so it still has the traffic.  Would it be to another non-CA OCSP
>responder?  Then where does it's URL point?  Or is the responder's key
>trusted and unrevocable?  When your responder is a non-CA, I believe
>that revocation of its public key must be possible.  The current
>document isn't clear on this point.

Would the following text provide sufficient clarification?

"In the instance when an OCSP responder is not the CA that issued the
certificate in question, the responder's certificate SHALL contain a URL
pointing to the CA that issued the certificate to the responder."

>>In a closed PKI, contractual or organizational containment of liability and
>>risk may be sufficient.  However, if an organization establishes an OCSP
>>Responder for its members' use and those members interoperate in an open
>>PKI fashion with external parties, are those external parties obligated to
>>refer to the same Responder, or is it permissible for them to rely on their
>>own designated Responder?  I would presume the latter.
>>
>>Further, in instances when the entity that is operating the OCSP Responder
>>did not issue the certificates,  how do such services acquire their
>>revocation information?  How is it provable timely, accurate and authentic?
>> Does there exist a "delegation certificate", "attribute certificate" or
>>other such construct from the CA (who ultimately produces this
>>information)?  I honestly do not know how this would shape up.  I do
>>strongly believe that it is well beyond the reach of a technical interface
>>specification such as OCSP to answer such questions.  The OCSP draft
>>defines the mechanisms by which such trust relationships may be
>>established.  Constraints upon the structure and enforcement of such trust
>>relationships are a local matter.
>
>Fair enough, but the technical specification should allow a sound trust
>relationship to be defined.  As I stated above, I am not convinced the
>current document does this.

I do not see inclusion of intermediary or ancillary CA certificates to be
useful in this protocol.  A certificate has one and only one issuing
authority.  Knowledge of its most current state exists in one and only one
place.  Any further protraction of the trust model issues into worst-case
scenarios will invoke a web of trading partner agreements the disentangling
of which would further substantiate the need for a law degree in order to
practice the art of PKI.

I am equally convinced that if we don't solve the simple problems first, we
won't get to state n+1.  Our client working groups and allied application
developers shouldn't have to implement complex protocols in order to arrive
at a simple solutions.

>>
>>In summary, I would agree that that an externally configured URL is useful
>>(modulo resolution of trust issues). The draft does not preclude such an
>>implementation.  It does seem to me however that including such information
>>in subscriber certificates is equivalent to CRLDistributionPoints, for
>>which there exists a generally accepted consensus.
>
>This statement isn't entirely accurate.  A CRLDistributionPoint isn't a
>separate entity whose public key may have to be revoked.

Only in the case where the OCSP responder is non-CA.  Otherwise the two are
completely equivalent.  One hits a CRLDistributionPoint to acquire a CRL.
One equivalently hits an OCSP URL for the same information.

>>
>>>
>>>2. I am not quite sure how to match up OCSP responses with requests.
>>>For example, suppose I send two requests to an OCSP responder concerning
>>>the same certificate.  On one I wish to find its revocation status today
>>>and on the other I wish to find its revocation status last month.  Now I
>>>get back two responses, one saying VALID and the other saying INVALID.
>>>According to Section 3.5, bullet 1, I am supposed to match the responses
>>>to requests using the identified certificates, but both responses and
>>>requests contain the same certificate.  It appears, in Section 4.1, that
>>>the possibility of including a trans_id in the request was considered,
>>>but it isn't clear exactly where this would appear.  Also, it doesn't
>>>appear in the response.  If one did include trans_id in the responses,
>>>then caching signed responses (as suggested in Section 2.2) is not
>>>possible.  Certainly, not being able to match up responses with requests
>>>leaves one open to replay attacks.  In the Notary document, in order to
>>>prevent such attacks, we include the time for which notarization was
>>>requested and the requester's name in the response.  This does not allow
>>>caching of responses, but it is secure.
>>
>>The trans_id concept apparently did not get fully excised.  It's leftover
>>from trying to get Certco's extensibility requirement into the service.
>>Unfortunately, the more I worked on a means to do so, the more further
>>afield the OCSP service drifted from its original intent to be a very
>>simple ping on the status of a certificate.  My understanding of the
>>requirement was provision of the means to enable other transactions.
>>Suddenly there was all this retained state laying around in order to match
>>up a service request to a service response, including potential error
>>conditions.  The simple OCSP service I started out with got buried under
>>abstraction.  Finally, when it occured to me, as you also noted, that
>>per-transaction state information breaks pre-production and/or caching of
>>status responses, I backed it out on the principle that simplicity is a
>>good thing.
>
>Maybe simplicity is a good thing, but I don't think that it buys you
>anything here.  In order to prevent replay attacks, the current time (or
>some other unique identifier) MUST be in the response.  Otherwise, a
>requester never knows if he/she is getting a fresh response.  So, in any
>case, pre-production and/or caching of responses does not seem possible.
> If I am missing something here, please let me know.

The response field "time" in Section 4.2 is the time at which the response
was signed (I shall update the draft to more adequately define the response
fields.)  Thus responses may be pre-produced, bearing the time at which
they were signed.  In the limit, such pre-production approaches CRLs in
timeliness.

Modestly latent OCSP responses derived from caches (say, on the order of
hours) may not be acceptable for those relying parties which require "most
current" responses.  At the risk of further complexity, would you consider
a Quality Of Service parameter relevant here?  I would have to add that a
QOS differentiation should also be supported by a "service unavailable"
reponse which would reflect the relying party's lack of privilege to access
the most current revocation information available.

>>
>>Now, it does seem to me that the Timestamping and Notary work in front of
>>us might present a better framework within which to consider Certco's
>>comment.
>
>Perhaps it might.  We believe that they are flexible, secure protocols.
>>
>>The same observation regarding cache breakage holds true for prior_to.  I'm
>>seriously thinking of doing away with the prior_to concept for the same
>>reason even though I'm attracted to the concept.  It's reflection appears
>>in the non-too-obvious case of a VALID response with a date_text component.
>> This would disambiguate the example you cited, (given an update to Section
>>3.5 to this effect) but I'm coming to question the utility of prior_to.  It
>>exists in reponse to the historical non-repudiation requirement, but it
>>seems to me that this requirement is less concerned with timeliness than
>>historical accuracy.  OCSP is all about timeliness; the current status of
>>the certificate.  Elimination of prior_to would also eliminate the case of
>>the example cited, since there would be no means to produce the example
case.
>
>Well, certainly if OCSP is concerned with timeliness, then cached
>responses are not possible.  Even if responses were cached every 10
>minutes and included the time that they were cached, the requester
>doesn't know how often caching occurs.  It gets back a response with
>some past time and does not know if an update has occurred since then.

Timeliness is a relative thing.  If all you had were CRLs that were
refreshed every week, refresh intervals measured in hours would not be
unacceptable.

I must continue here to point out the one-to-one relationship between CRLs
and OCSP.  In the limit, OCSP approaches CRLs in utility.  It is defined
and structured however to significantly increase the likelihood, over use
of CRLs, that one is able to detect a revoked certificate prior to relying
on it.

>>
>>>
>>>4. In Section 2.2 it is stated that "... the path validation logic
>>>implied by the VALID and INVALID indicators is that defined by PKIX Part
>>>1."  Now, issues of whether or not a certificate is valid, invalid or
>>>inactive are separate and can't really be made properly by an OCSP
>>>server since it doesn't have the information about what is acceptable to
>>>the application (e.g. acceptable policy identifiers). There seems to be
>>>a basic assumption that the OCSP server (or some process associated with
>>>it) can do the whole certificate validation process (including chain
>>>processing), but this process will need to be somewhat dependent on the
>>>application and potentially other constraints imposed by the security
>>>policy within which a relying party is operating.  To deal with this
>>>problem, we included an optional SEQUENCE OF Certificate in the request
>>>that can be used to indicate the chain of trust to be verified as well
>>>as optional PolicyInformation that can be used to include the policy
>>>under which the validation should take place.
>>
>>I discussed the point with Denis, who had essentially the same concerns
>>regarding presumptions of a fixed policy.  By clearly specifying that only
>>a single certificate is included, the selection of a Responder can be at
>>the user's discretion.  Thus the protocol as a technical specification
>>asserts no constraints on the underlying trust model.
>
>I have two comments on this.  First, while it is true that the technical
>specification asserts no constraints on the underlying trust model, this
>protocol does constrain the requester to assume the chain of trust used
>by the responder.  In fact, there is no way for a requester to know what
>chain of trust the responder has used.  Is this desirable?

A CA is authoritative for the revocation state of certificates it issues.
One asks of the CA, by way of the OCSP query, "Is this certificate you
issued revoked?".  With respect to a single query, there is no chain.  It's
a very simple check against a store of revocation information.

In the instance when the OCSP responder is not the issuer of the
certificate, in what circumstance would one be requesting OCSP services of
a responder one didn't trust?

Supplying supplementary CA certificates strongly suggests OCSP is intended
to be the front end to a remote path validation engine.  This is not what
OCSP is or should be.

>My second
>comment is that the issue of policy is totally ignored by this document.
> I may want to know "Is this certificate good for my particular
>application?", not "Is this certificate good for any application?".
>There is not a method to do this in the protocol as proposed.

There exists the notion of an authenticable identity and the parallel
notion of the attributes associate with that identity.  Confirming the
former and managing its current state is a straightforward task.  The
latter has not yet yielded a broadly implemented solution.  We need to
focus on solving the simple problems first.

>>
>>Also, it's important to note that many Responders will in all likelihood be
>>one's CA.  The trust model in this case is well defined.  Including its
>>specification in the request inflates the size of the request with no added
>>value.
>
>While it may be true that the responder may be the requester's CA, I
>don't think that this will always be the case.  We must allow for other
>situations.

I'm coming to the conclusion that the non-CA case overly complicates the
specification, despite the fact that I specifically amended the draft for
this purpose.

>>
>>>5. Why not ASN.1?  This is PKIX after all.  Everything else was done
>>>here using ASN.1, so certainly any application using this service should
>>>be capable of handling it.  This seems an odd choice.
>>
>>HTTP Servers are forming an increasingly dominant component of the Internet
>>technical infrastructure.  It seems to me that a proposal that seeks to
>>establish server-type capabilities would do the Internet well by leveraging
>>this infrastructure.  There exists commonly accepting mechanisms--and
>>widely available tools--for interfacing to HTTP servers.  And while it is
>>the case that many PKI developments are ASN.1 fluent and equipped, there
>>are a substantial (and increasing) number to whom certificate parsing is a
>>function call, not a T-L-V crawl.
>
>I think that we would be doing the PKIX community a service if we were
>able to stick to one format for doing things, instead of forcing them to
>do things in two different ways.

The current draft specifies one way of determing the revocation status of a
certificate.  Insistence on ASN.1 for ASN.1's sake creates two different
ways.  So let's not do it.  I propose that we instead move forward to
address the more complex transaction-based problems with tools appropriate
to the need.

I would argue however that a direct ASN.1 translation of OCSP serves no
need.  The transaction-based protocols should add value in a layered fashion.

>>
>>>Given the above comments, I have my doubts about the viability of this
>>>type of service when used instead of CRLs.
>>
>>Clearly there exists many uses of public key technology that are better
>>served by local storage of a CA's most recent CRL (the most esoteric case I
>>can think of involves Naval operations under radio silence where the CA is
>>ashore).  But having said that, OCSP addresses well-known and long-held
>>concerns over CRL size timeliness.
>
>In principle, I don't disagree with this.  I just think that we should
>use a sound and secure protocol that will work in different models.  I
>am not convinced that this document does this.
>
>Thank you,
>
>	Robert Zuccherato
>	Entrust Technologies
>>
>>
>
>

Date: Mon, 17 Nov 1997 14:05:26 -0800
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on the OCSP draft
Status:

I cringe from replying to the ietf-pkix group - get back a hundred
or so undeliverable messages, but... :-(

[email-masked] wrote:
> 
> At 03:08 PM 11/14/97 -0800, Ambarish Malpani wrote:
> >Hi Mike,
> >
> >    A few comments about the OCSP draft:
> >
> >
> >1. OCSP is not scalable enough to work if people check the status
> >every time they get a certificate - wouldn't it be better to define
> >a protocol that scales well, so that everybody can check a
> >certificates revocation status, rather than just a few applications?
> >(I agree: this is a shameful plug for our algorithm :-))

I have been alerted to the fact that this is a shameless plug, not a
shameful one!!!

> 
> OCSP rides over HTTP.  So in defense of OCSP's scalability I would have to
> ask--Is HTTP scalable?  Perhaps we should more crisply define what we mean
> by scalability.

For a query like this, HTTP is as scalable as you can get - this
transation just involves a single TCP connection, with a single
query and a single response - how much more (less?) can one ask for?
Not sure I would want to base something on UDP for this.

> 
> >2. In queries, wouldn't it be reasonable to include the public key
> >of the CA also (as opposed to just the CA's DN)? Just working off the
> >DN makes me feel uncomfortable - opens up potential attacks if
> >one can ever compromise a CA - where the CA creates new CAs with the
> >same
> >DN as a trusted CA etc. It is much more difficult to fake a
> >public key.
> 
> Could you further explain here?  I'm presuming you're referring to the CA
> that issued the certificate in question.  That CA (and it's public key) is
> well defined by the subject certificate content.

What I am talking about here, is that fact that it is not terribly
difficult to create a CA with any arbitrary DN (ofcourse, getting
somebody to trust that CA is more difficult). The example I stated
above, of a rogue CA creating CAs with DNs that replicate those of
well-known CAs is possible. Also, due to bad co-ordination between
different CAs, it is possible for two people to run CAs with the
same DN.

However, is is very, very difficult to fake somebodies public key.
Even if you had a rogue CA, he could not create a fake CA with the
same public key as a well known CA. So, allowing a user to specify
the public key of the CA (in addition to the name), would help
and certainly not hinder the security of this protocol.
(yes, I am talking about the public key of the issuing CA).

> 
> >3. Shouldn't the protocol support other more efficient ways of
> >providing the revocation status? Again, it would be nice if this
> >protocol
> >let one easily slip in different methods of saying/proving whether a
> >certificate was revoked or not - that way, other methods of checking
> >for revocation can, more easily fit into this protocol.
> 
> Actually, I didn't write the protocol with any specific back-end
> implementation in mind of how the actual revocation information may be
> represented.  The protocol is simply a means to gain access to that
> information in as simple a manner as possible.  This revocation information
> my be represented as pre-signed responses, direct access to a database, the
> entries on a CRL or an object which compresses CRL information.

They way this protocol is defined, for secure responses, you need to
sign the response (with a time-stamp that says when the response was
generated). This does create a trade-off between, creating pre-signed
responses for various queries that a valid for a certain amount of time
(and that can be signed off-line), OR creating a new signed response
for every query, with the signing happenning when the query is
received. This protocol does limit the efficiency/accuracy of
secure responses.

> 
> >
> >4. In section 3.3, the NO SERVICE response can be faked. If I get a
> >NO SERVICE response from a trusted server, I can send that reply to
> >future
> >people querring that server by sending them the response I had received.
> 
> Responses are time-stamped at the time of their signing to preclude this
> attack.

Once again - either you create a new signed response for every query,
or you allow the OCSP server to create a signed NO SERVICE response
which it can use for a certain amount of time - either the server
will need to perform a lot of signing operations, or once a NO SERVICE
response is created, it can be faked for as long as clients are willing
to trust cached responses. i.e. if clients are willing to trust a
response created upto 10 minutes ago (to allow for caching), then one
can use a signed NO SERVICE for up to 10 minutes from the time it
was generated.

> 
> >
> >5. In section 3.4 why not include the revocation time in the response
> >for revoked certificates (and reason for revocation) - don't need
> >to deal with the dates in the response.
> 
> The text of 4.2 is being updated to reflect the fact that the
> "status_value" element of a response contains a "date_text" option which
> would reflect the date/time of revocation.

And also the reason for revocation - as specified in a CRL?

> 
> >
> >6. In section 3.4, there is a reference to current date (is there
> >such a thing as current date given clock skews and finite transaction
> >times)?

This was really a question.

> >
> >7. Use POST instead of GET for requests - given that requests can
> >be very large (>1K in size)
> 
> Only to the extent doing so affects distributed caching behavior.

OUCH!!! Are you relying on the caching that is happening at proxies
that may reside on that path between my machine and the OCSP server?
So now, if an OCSP server has access to a database that is updated
every 10 seconds, but my company has a proxy that caches responses
for 1 hour, I can't get a new response from the server for
up to 1 hour?
If that is the idea, I suppose you should also add an Expires field
in the header, so that the cache knows when to kick out the
cached entry - and pray hard that all clocks are reasonably well
synchronized.

Mike, I am not certain that this protocol should be that closely
linked to HTTP, in that you are asking the server to sign HTTP
header fields - a proxy can and will feel free to introduce
additional headers in the response and then checking the
validity of the signature will get much more difficult. I would
rather see the query use HTTP for the headers that it makes sense
to put in HTTP - like Content-Encoding, Content-Length etc, but
leave the basic query and response in the body part of the message.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (408) 738-2040
ValiCert, Inc.				        [email-masked]
333 W. El Camino Real, Suite 270              http://www.valicert.com
Sunnyvale, CA 94087

From: [email-masked]
Date: Mon, 17 Nov 1997 08:25:18 -0700
To: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: Re: Comments on the OCSP draft
Status:

At 03:08 PM 11/14/97 -0800, Ambarish Malpani wrote:
>Hi Mike,
>
>    A few comments about the OCSP draft:
>
>
>1. OCSP is not scalable enough to work if people check the status
>every time they get a certificate - wouldn't it be better to define
>a protocol that scales well, so that everybody can check a
>certificates revocation status, rather than just a few applications?
>(I agree: this is a shameful plug for our algorithm :-))

OCSP rides over HTTP.  So in defense of OCSP's scalability I would have to
ask--Is HTTP scalable?  Perhaps we should more crisply define what we mean
by scalability.

>2. In queries, wouldn't it be reasonable to include the public key
>of the CA also (as opposed to just the CA's DN)? Just working off the
>DN makes me feel uncomfortable - opens up potential attacks if
>one can ever compromise a CA - where the CA creates new CAs with the
>same
>DN as a trusted CA etc. It is much more difficult to fake a
>public key.

Could you further explain here?  I'm presuming you're referring to the CA
that issued the certificate in question.  That CA (and it's public key) is
well defined by the subject certificate content.

>3. Shouldn't the protocol support other more efficient ways of
>providing the revocation status? Again, it would be nice if this
>protocol
>let one easily slip in different methods of saying/proving whether a
>certificate was revoked or not - that way, other methods of checking
>for revocation can, more easily fit into this protocol.

Actually, I didn't write the protocol with any specific back-end
implementation in mind of how the actual revocation information may be
represented.  The protocol is simply a means to gain access to that
information in as simple a manner as possible.  This revocation information
my be represented as pre-signed responses, direct access to a database, the
entries on a CRL or an object which compresses CRL information.

>
>4. In section 3.3, the NO SERVICE response can be faked. If I get a
>NO SERVICE response from a trusted server, I can send that reply to
>future
>people querring that server by sending them the response I had received.

Responses are time-stamped at the time of their signing to preclude this
attack.

>
>5. In section 3.4 why not include the revocation time in the response
>for revoked certificates (and reason for revocation) - don't need
>to deal with the dates in the response.

The text of 4.2 is being updated to reflect the fact that the
"status_value" element of a response contains a "date_text" option which
would reflect the date/time of revocation.

>
>6. In section 3.4, there is a reference to current date (is there
>such a thing as current date given clock skews and finite transaction
>times)?
>
>7. Use POST instead of GET for requests - given that requests can
>be very large (>1K in size)

Only to the extent doing so affects distributed caching behavior.

>
>
>A
>
>-- 
>---------------------------------------------------------------------
>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: Mon, 17 Nov 1997 15:45:27 -0500
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: IETF-PKIX <[email-masked]>
Subject: digitalSignature vs. nonRepudiation
Status:

I am attempting to implement the key usages as defined for the keyUsage
extension.  I am stumbling upon digitalSignature and nonRepudiation.

I define the key usage digitalSignature as a public key which affords
the services of authentication and data integrity.

Of course, nonRepudiation affords the service of non-repudiation.

My question is, with only nonRepudiation set (and not digitalSignature),
is it true that my public key can be used only to provide the service of
non-repudiation, and NOT the services of authentication and data
integrity?  If this is true, I'm curious to know how this is
implemented.

I claim that if the nonRepudiation bit is set, that I can use that key
to implement authentication and data integrity, and also claim
nonRepudiation of the originator.  Since authentication and data
integrity are services provided under digitalSignature, I believe that
when nonRepudiation is set, digitalSignature should also be set.

I'd like to hear agreements or disagreements with my line of reasoning.

Dave Simonetti

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-opp-ftp-http-02.txt
Date: Mon, 17 Nov 1997 10:25:27 -0500
Sender: [email-masked]
Status:

A Revised 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 
                          Operational Protocols:  FTP and HTTP
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-opp-ftp-http-02.txt
	Pages		: 5
	Date		: 14-Nov-97
	
   The protocol conventions described in this document satisfy some of
   the operational requirements of the Internet Public Key
   Infrastructure (PKI).  This document specifies the conventions for
   using the File Transfer Protocol (FTP) and the Hypertext Transfer
   Protocol (HTTP) to obtain certificates and certificate revocation
   lists (CRLs) from PKI repositories.  Additional mechanisms addressing
   PKIX operational requirements 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 wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-opp-ftp-http-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-opp-ftp-http-02.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-opp-ftp-http-02.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 I-D ACTION-draft-ietf-pk 11 (EuSn/CSOm) (0001CE06)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-opp-ftp-http-02.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-opp-ftp-h 2 (AURL/Arch) (0001CE07)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: Brian Korver <[email-masked]>
Subject: Re: Question about encoding GeneralName
To: [email-masked] (David P. Kemp)
Date: Fri, 14 Nov 1997 16:06:47 -0800 (PST)
Cc: [email-masked]
Status:

David P. Kemp writes:
> Where is this promotion described?  X.690 sections 8.13 "Encoding of a
> choice value" and 8.14 "Encoding of a tagged value" say nothing about
> promotion of tagged values in a choice, and such promotion is not
> required to distinguish which of the choice items was chosen, according
> to sentence 8.1.2.6.  The CONTEXT-class tag is present and sufficient
> without also requiring the underlying tag.
> 
> If all our examples are wrong, we've got a lot of fixing up to do!

David,

You're right.  I misread the question.  The context tag is present
and sufficient.  It's cases like Name that are EXPLICIT.  Sorry
for the confusion.

brian
[email-masked]

Date: Fri, 14 Nov 1997 16:17:17 -0800 (PST)
From: hemma prafullchandra <[email-masked]>
Reply-To: hemma prafullchandra <[email-masked]>
Subject: Re: Question about encoding GeneralName
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Status:

> > From: Brian Korver <[email-masked]>
> > 
> > Yes.  IMPLICIT tagging of CHOICE is not legal.  It's promoted to EXPLICIT
> > so that the underlying tag (which shows you what is chosen) is present
> > in the encoding.
> 
> Brian,
> 
> Where is this promotion described?  X.690 sections 8.13 "Encoding of a
> choice value" and 8.14 "Encoding of a tagged value" say nothing about
> promotion of tagged values in a choice, and such promotion is not
> required to distinguish which of the choice items was chosen, according
> to sentence 8.1.2.6.  The CONTEXT-class tag is present and sufficient
> without also requiring the underlying tag.
> 
> If all our examples are wrong, we've got a lot of fixing up to do!
> 

There's text in X.680 sub-sections 28.6 and 28.8 (i don't have it
with me right now so cannot type it in) which contributes to this
confusion. 
 
hemma

Date: Fri, 14 Nov 1997 15:08:20 -0800
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Comments on the OCSP draft
Status:

Hi Mike,

    A few comments about the OCSP draft:

1. OCSP is not scalable enough to work if people check the status
every time they get a certificate - wouldn't it be better to define
a protocol that scales well, so that everybody can check a
certificates revocation status, rather than just a few applications?
(I agree: this is a shameful plug for our algorithm :-))

2. In queries, wouldn't it be reasonable to include the public key
of the CA also (as opposed to just the CA's DN)? Just working off the
DN makes me feel uncomfortable - opens up potential attacks if
one can ever compromise a CA - where the CA creates new CAs with the
same
DN as a trusted CA etc. It is much more difficult to fake a
public key.

3. Shouldn't the protocol support other more efficient ways of
providing the revocation status? Again, it would be nice if this
protocol
let one easily slip in different methods of saying/proving whether a
certificate was revoked or not - that way, other methods of checking
for revocation can, more easily fit into this protocol.

4. In section 3.3, the NO SERVICE response can be faked. If I get a
NO SERVICE response from a trusted server, I can send that reply to
future
people querring that server by sending them the response I had received.

5. In section 3.4 why not include the revocation time in the response
for revoked certificates (and reason for revocation) - don't need
to deal with the dates in the response.

6. In section 3.4, there is a reference to current date (is there
such a thing as current date given clock skews and finite transaction
times)?

7. Use POST instead of GET for requests - given that requests can
be very large (>1K in size)

A

-- 
---------------------------------------------------------------------
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: Fri, 14 Nov 1997 13:02:01 -0800
From: Pat Richard <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

I strongly beleive it should not be MANDATORY.

Why can we not make POP a function of policy ?

Examples (not to be taken literally): A CA could elect to have a policy
that stated something like "all certs with extension X were POP certs",
or they could have a global statement in their CPS regarding the use (or
non-use) of POP in all general certs, etc. etc.).

Russ Housley wrote:
> 
> I stongly believe that Proof-of-Possession should be REQUIRED!
> 
> Russ
> 
> >>Now that we are in last call, I'd like a straw poll to measure the
> >>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
> >>CAs.  If there is general agreement, PoP can be returned to its
> >>original REQUIRED status without delaying the RFC.
> >
> >I'd like to support him in his proposal to make POP mandatory. As I've
> >already emailed, I believe that the CA should be considered to be
> >actually making a binding between the owner and the private key. The
> >certificate should be saying: "this name owns the private key corresponding
> >to the public key in this certificate". Without POP, all the certificate
> >says is: "This name wishes to be associated with the public key in the
> >certificate; the corresponding private key may however belong to someone
> >else" - very useful :-(.
> >
> >I'm also concerned that individuals might be spoofed into
> >presenting the wrong public key value to the CA when requesting a
> >certificate, or the request may be tampered with en route, so that the
> >malicious private key owner who substituted his/her own public key can
> >then masquerade as the individual.
> >
> >If you (a CA) are making a guaranteed binding between two values, both
> >need to be authenticated for the guarantee to be worth anything.
> >
> >Tom Parker
> >ICL
> >UK.
> >

-- 
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Fri, 14 Nov 1997 13:07:43 -0800
From: Pat Richard <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Doh. Sorry. I forgot to put in this disclaimer (see previous post):

Sorry for the delayed email about POP. I just thought I would send it
anyways (I know it beyond draft time, etc.). 

I wanted to put the POP comments out for discussion anyways, regardless
of the state of the documents...  this is a good place for those kinds
of discussions.

-Pat

-- 
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Fri, 14 Nov 1997 15:46:15 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Question about encoding GeneralName
Status:

> From: Brian Korver <[email-masked]>
> 
> Yes.  IMPLICIT tagging of CHOICE is not legal.  It's promoted to EXPLICIT
> so that the underlying tag (which shows you what is chosen) is present
> in the encoding.

Brian,

Where is this promotion described?  X.690 sections 8.13 "Encoding of a
choice value" and 8.14 "Encoding of a tagged value" say nothing about
promotion of tagged values in a choice, and such promotion is not
required to distinguish which of the choice items was chosen, according
to sentence 8.1.2.6.  The CONTEXT-class tag is present and sufficient
without also requiring the underlying tag.

If all our examples are wrong, we've got a lot of fixing up to do!

Date: Fri, 14 Nov 1997 14:48:08 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Question about encoding GeneralName
Cc: [email-masked]
Status:

> From [email-masked] Fri Nov 14 13:50:43 1997
> 
> Should the encoding of SubjectAlternativeName (Seq of GeneralName)
> be as:
> 
> 30 40 (seq, len=64)
>      A1 13 (context-specific 1, form=constructed, rfc822Name)
>           16 11 (ia5string, len=17)
>                64 75 6B 65 40 6A 61 76 61 73
>                6F 66 74 2E 63 6F 6D     ([email-masked])
> 
> This is similar to the encoding provided in the example in part I.
> 
> OR should it be as:
> 30 3A (seq, len=58)
>      81 11 == 17 (context-specific 1, form=primitive, implicit tagging for
> rfc822Name)
>           64 75 6B 65 40 6A 61 76 61 73
>           6F 66 74 2E 63 6F 6D
> 
> Question: should implicit tagging be ignored with CHOICE type as in
> GeneralName ?

Your second example is the correct one.  Part 1 example D.2.1 has the
correct form of the subjectAltName (shown as an unparsed OCTET STRING
beginning with 30 10 81 0e 77 70 ... ).  Part 1 example D.3  is incorrect,
since the entire module is IMPLICIT TAGS and there is no EXPLICIT in
the definition of GeneralName.   (However, note that the definition
of AnotherName includes an explicit tag for the value!)

The following is from a cert similar to example D.3, but using the
correct encoding of the subjectAltName extension.  This cert was valid
beginning July 22, 1996 instead of May 21, 1996 as in the PKIX example,
so it should be more correct :-).  Note that the AnotherName uses the
correct IMPLICIT tag at 0040 and the correct EXPLICIT tag at 0047.

-----------------------------------------------------------------
0000 30 81 80     128: SEQUENCE 
0003 81 10         16: . [1] 
                     : 6a 6f 72 64 61 6e 40 61 63 2e 75 70 63 2e 65 73
0021 86 11         17: . [6] 
                     : 68 74 74 70 3a 2f 2f 61 63 2e 75 70 63 2e 65 73
                     : 2f
0040 a0 59         89: . [0] 
0042 06 03          3: . . OID 2.5.4.16: postalAddress
0047 a0 52         82: . . [0] 
0049 30 50         80: . . . SEQUENCE 
0051 13 14         20: . . . . PrintableString 'Dr. Francisco Jordan'
0073 13 05          5: . . . . PrintableString 'U.P.C'
0080 13 19         25: . . . . PrintableString 'C/ Gran Capita sn, Mod-D6'
0107 13 16         22: . . . . PrintableString '08071-Barcelona, Spain'

From: Brian Korver <[email-masked]>
Subject: Re: Question about encoding GeneralName
To: [email-masked]
Date: Fri, 14 Nov 1997 11:37:59 -0800 (PST)
Cc: [email-masked]
Status:

hemma prafullchandra writes:
> Should the encoding of SubjectAlternativeName (Seq of GeneralName)
> be as:
> 
> 30 40 (seq, len=64)
>      A1 13 (context-specific 1, form=constructed, rfc822Name)
>           16 11 (ia5string, len=17)
>                64 75 6B 65 40 6A 61 76 61 73
>                6F 66 74 2E 63 6F 6D     ([email-masked])
>      A2 0E (context-specific 2, form=constructed, dnsName)
>           16 0C
>                6A 61 76 61 73 6F 66 74 2E 63
>                6F 6D                    (javasoft.com)
>      A6 19 (context-specific 6, form=constructed, URI)
>           16 17
>                68 74 74 70 3A 2F 2F 77 77 77
>                2E 6A 61 76 61 73 6F 66 74 2E
>                63 6F 6D                 (http://www.javasoft.com)
> 
> This is similar to the encoding provided in the example in part I.
> 
> OR should it be as:
> 30 3A (seq, len=58)
>      81 11 == 17 (context-specific 1, form=primitive, implicit tagging for
> rfc822Name)
>           64 75 6B 65 40 6A 61 76 61 73
>           6F 66 74 2E 63 6F 6D
>      82 0C == 12
>           6A 61 76 61 73 6F 66 74 2E 63
>           6F 6D
>      86 17 == 23
>           68 74 74 70 3A 2F 2F 77 77 77
>           2E 6A 61 76 61 73 6F 66 74 2E
>           63 6F 6D
> 
> Question: should implicit tagging be ignored with CHOICE type as in
> GeneralName ?
> 
> 
> Thanks, Hemma

Yes.  IMPLICIT tagging of CHOICE is not legal.  It's promoted to EXPLICIT
so that the underlying tag (which shows you what is chosen) is present
in the encoding.

brian
[email-masked]

Date: Fri, 14 Nov 1997 10:18:39 -0800 (PST)
From: hemma prafullchandra <[email-masked]>
Reply-To: hemma prafullchandra <[email-masked]>
Subject: Question about encoding GeneralName
To: [email-masked]
cc: [email-masked]
Status:

Should the encoding of SubjectAlternativeName (Seq of GeneralName)
be as:

30 40 (seq, len=64)
     A1 13 (context-specific 1, form=constructed, rfc822Name)
          16 11 (ia5string, len=17)
               64 75 6B 65 40 6A 61 76 61 73
               6F 66 74 2E 63 6F 6D     ([email-masked])
     A2 0E (context-specific 2, form=constructed, dnsName)
          16 0C
               6A 61 76 61 73 6F 66 74 2E 63
               6F 6D                    (javasoft.com)
     A6 19 (context-specific 6, form=constructed, URI)
          16 17
               68 74 74 70 3A 2F 2F 77 77 77
               2E 6A 61 76 61 73 6F 66 74 2E
               63 6F 6D                 (http://www.javasoft.com)

This is similar to the encoding provided in the example in part I.

OR should it be as:
30 3A (seq, len=58)
     81 11 == 17 (context-specific 1, form=primitive, implicit tagging for
rfc822Name)
          64 75 6B 65 40 6A 61 76 61 73
          6F 66 74 2E 63 6F 6D
     82 0C == 12
          6A 61 76 61 73 6F 66 74 2E 63
          6F 6D
     86 17 == 23
          68 74 74 70 3A 2F 2F 77 77 77
          2E 6A 61 76 61 73 6F 66 74 2E
          63 6F 6D

Question: should implicit tagging be ignored with CHOICE type as in
GeneralName ?

Thanks, Hemma

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Date: Fri, 14 Nov 1997 10:45:30 -0500
Status:

Hi,

I sent this yesterday but haven't seen it appear on the list yet.
Here's a re-send  --  apologies to anyone who receives it twice...

>----------
>From: 	Carlisle Adams
>Sent: 	Thursday, November 13, 1997 6:05 PM
>To: 	[email-masked]'; [email-masked]'; [email-masked]'; 'Jeffrey
>I. Schiller'
>Cc: 	[email-masked]'
>Subject: 	RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
>
>All,
>
>The updated document  "draft-ietf-pkix-ipki3cmp-06.txt"  (addressing all the
>comments raised by Jeff Schiller) has just been submitted to the
>Internet-Drafts address.  It should appear in the usual places soon.
>
>Thank you, Jeff, for your careful reading.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

Date: Thu, 13 Nov 1997 22:02:19 -0500 (EST)
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: last call for Part 1
Status:

Folks,

	I have been remiss in not announcing the last call for Part 1:
X.509 Certificate and CRL Profile (draft-ietf-pkix-ipki-part1-06.txt).
Please review this document at provide any comments to the author. Last
call will close on November 28.

Steve

From: Rob Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Rich Ankney'" <[email-masked]>
Subject: RE: OCSP Questions
Date: Thu, 13 Nov 1997 09:12:34 -0500
Status:

Rich;

>----------
>From: 	Rich Ankney[SMTP:[email-masked]]
>Sent: 	Wednesday, November 12, 1997 3:39 PM
>To: 	Rob Zuccherato; [email-masked]; [email-masked]'
>Subject: 	Re: OCSP Questions
>
>> >5. Why not ASN.1?  This is PKIX after all.  Everything else was done
>> >here using ASN.1, so certainly any application using this service should
>> >be capable of handling it.  This seems an odd choice.
>> 
>> HTTP Servers are forming an increasingly dominant component of the
>Internet
>> technical infrastructure.  It seems to me that a proposal that seeks to
>> establish server-type capabilities would do the Internet well by
>leveraging
>> this infrastructure.  There exists commonly accepting mechanisms--and
>> widely available tools--for interfacing to HTTP servers.  And while it is
>> the case that many PKI developments are ASN.1 fluent and equipped, there
>> are a substantial (and increasing) number to whom certificate parsing is
>a
>> function call, not a T-L-V crawl.
>
>I agree with all (well, most) of Mike's comments.  I'd be glad to work on
>an ASN.1
>version of OCSP, including extensibility as well as some of the other
>"CertCo features", with anyone who'd care to participate.

Does it make sense to start work on an ASN.1 version of OCSP when a
document exists which already has this (and also contains the other
"CertCo features" as I understand them)?  Please see
http://www.entrust.com/downloads/notary.txt which has been submitted as
an independent Internet Draft.  This draft now contains an explicit
service for notarizing certificates.  The capability was always there,
we have just made it an explicit service in the updated draft.

Thank you,

	Robert Zuccherato
	Entrust Technologies
>
>

Date: Wed, 12 Nov 1997 20:07:23 -0500 (EST)
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Meeting Slots in D.C. IETF
Status:

Folks,

	There has been a schedule change for our Wednesday, to minimize
overlaps with other WG meetings that are of interest to PKIX WG members.

	We will still meet on Monday from 9:30-11:30, as before.  Our
second slot, still on Wednesday, is now at 1530-1730 opposite ip1394, rtfm,
bmwg, mpls.

Steve

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "Rob Zuccherato" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: OCSP Questions
Date: Wed, 12 Nov 1997 15:39:35 -0500
Status:

> >5. Why not ASN.1?  This is PKIX after all.  Everything else was done
> >here using ASN.1, so certainly any application using this service should
> >be capable of handling it.  This seems an odd choice.
> 
> HTTP Servers are forming an increasingly dominant component of the
Internet
> technical infrastructure.  It seems to me that a proposal that seeks to
> establish server-type capabilities would do the Internet well by
leveraging
> this infrastructure.  There exists commonly accepting mechanisms--and
> widely available tools--for interfacing to HTTP servers.  And while it is
> the case that many PKI developments are ASN.1 fluent and equipped, there
> are a substantial (and increasing) number to whom certificate parsing is
a
> function call, not a T-L-V crawl.

I agree with all (well, most) of Mike's comments.  I'd be glad to work on
an ASN.1
version of OCSP, including extensibility as well as some of the other
"CertCo features", with anyone who'd care to participate.

Regards,
Rich
(from CertCo)

Date: Wed, 12 Nov 1997 13:02:25 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Status:

Jeffrey,

>From section 1.3 (requirements)
>
>> 10. Final authority for certification creation rests with the CA; no 
>> RA or end-entity equipment can assume that any certificate issued by a 
>> CA will contain what was requested -- a CA may alter certificate field 
>> values or may add, delete or alter extensions according to its operating 
>> policy; the only exception to this is the public key, which the CA must 
>> not modify (assuming that the CA was presented with the public key 
>> value). In other words, all PKI entities (end-entities, RAs, and CAs) 
>> must be capable of handling responses to requests for certificates in 
>> which the actual certificate issued is different from that requested  
>> (for example, a CA may shorten the validity period requested). 

Regardless of what portion of a requested certificate might be changed by
the CA, the text of the requirements should be changed to clarify the fact
that the requesting subscriber (end-user, normally)  is responsible for
reviewing and approving the modifications made, if any. If the subscriber
does not approve the certificate contents, the CA may not publish or
otherwise distibute the certificate. 

Cf. the ABA Digital Signature Guidelines, para 1.1, 3.8, and 4.2. The DSG
are available at http://www.abanet.org/scitech/ec/isc/dsgfree.html.

What rights the RA should have to review and approve the revised certificate
would be an interesting question, as the role that an RA plays that is
independent of the CA has not been adequately developed, IMHO.

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."

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: [email-masked]
Date: Wed, 12 Nov 1997 09:33:11 -0700
To: Rob Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: OCSP Questions
Status:

Robert--

Thanks for the review.  Comments below.

--Mike

At 01:43 PM 11/10/97 -0500, Rob Zuccherato wrote:
>I have been reading over the recently submitted draft for OCSP.  As some
>people mentioned in Munich, the Notary service that I talked about there
>is very similar to an OCSP service, and I see that the author of the
>OCSP draft is struggling with many of the same problems that we
>struggled with when devising our protocol.  In this light, I have a few
>questions that I would like to ask Mike about his document.
>
>1. In Section 3.1 it appears that CAs must include in certificates the
>URI of the OCSP responder that end entities are to use for the
>certificate.  I guess that this means the URI must appear in the
>responder's certificate (in SubjectAltName?) in order for end entities
>to match responders with certificates.  Even so, what value would appear
>in the AuthorityInfoAccess field of an OCSP responders certificate?
>Certainly it could not be its own URI, since then revocation would be
>impossible.  So it must be the URI of some other responder.  But then
>what goes in the AuthorityInfoAccess field of that responders
>certificate?  Where does this chain end?  This is a nontrivial question
>because whenever I verify a signature on an OCSP response I will have to
>follow this chain.  In our Notary protocol we decided that it was not a
>good idea to include the information about which server to use in the
>certificate.  It is left up to the end entity which Notary to use. Also,
>the Notaries must have the extended key usage field extension in their
>certificates indicating that they are Notaries.  This way if things go
>wrong, the certificates can be revoked and placed on ARLs and end
>entities aren't tied to one service.  

I agree--this is a nontrivial question.

A CA's certificate shouldn't contain a reiteration of the OCSP URL
contained in its subscribers' certificates.  Conversely, the OCSP
specification does not preclude placing into CA certificate a URL that
enables access to superior CA's OCSP services.  Ultimately one arrives at a
trusted public key.

The non-CA case is more interesting.

Relying parties are not technically constrained by OCSP from relying upon a
different URL.  However, assuming a well-defined trust model between a
subscriber's certificate and the CA that issued it, the apportionment of
liablity is less clear in the case of non-CA OCSP Responders.  Perhaps
liability is apportioned by contract, and the relying parties configure
their "OCSP Responder" URL in their applications accordingly. Perhaps it's
by organizational fiat--thou shalt use the corporate OCSP Responder.
Again, one performs a local configuration to point to the corporate OCSP
Responder.

In a closed PKI, contractual or organizational containment of liability and
risk may be sufficient.  However, if an organization establishes an OCSP
Responder for its members' use and those members interoperate in an open
PKI fashion with external parties, are those external parties obligated to
refer to the same Responder, or is it permissible for them to rely on their
own designated Responder?  I would presume the latter.

Further, in instances when the entity that is operating the OCSP Responder
did not issue the certificates,  how do such services acquire their
revocation information?  How is it provable timely, accurate and authentic?
 Does there exist a "delegation certificate", "attribute certificate" or
other such construct from the CA (who ultimately produces this
information)?  I honestly do not know how this would shape up.  I do
strongly believe that it is well beyond the reach of a technical interface
specification such as OCSP to answer such questions.  The OCSP draft
defines the mechanisms by which such trust relationships may be
established.  Constraints upon the structure and enforcement of such trust
relationships are a local matter.

In summary, I would agree that that an externally configured URL is useful
(modulo resolution of trust issues). The draft does not preclude such an
implementation.  It does seem to me however that including such information
in subscriber certificates is equivalent to CRLDistributionPoints, for
which there exists a generally accepted consensus.

>
>2. I am not quite sure how to match up OCSP responses with requests.
>For example, suppose I send two requests to an OCSP responder concerning
>the same certificate.  On one I wish to find its revocation status today
>and on the other I wish to find its revocation status last month.  Now I
>get back two responses, one saying VALID and the other saying INVALID.
>According to Section 3.5, bullet 1, I am supposed to match the responses
>to requests using the identified certificates, but both responses and
>requests contain the same certificate.  It appears, in Section 4.1, that
>the possibility of including a trans_id in the request was considered,
>but it isn't clear exactly where this would appear.  Also, it doesn't
>appear in the response.  If one did include trans_id in the responses,
>then caching signed responses (as suggested in Section 2.2) is not
>possible.  Certainly, not being able to match up responses with requests
>leaves one open to replay attacks.  In the Notary document, in order to
>prevent such attacks, we include the time for which notarization was
>requested and the requester's name in the response.  This does not allow
>caching of responses, but it is secure.

The trans_id concept apparently did not get fully excised.  It's leftover
from trying to get Certco's extensibility requirement into the service.
Unfortunately, the more I worked on a means to do so, the more further
afield the OCSP service drifted from its original intent to be a very
simple ping on the status of a certificate.  My understanding of the
requirement was provision of the means to enable other transactions.
Suddenly there was all this retained state laying around in order to match
up a service request to a service response, including potential error
conditions.  The simple OCSP service I started out with got buried under
abstraction.  Finally, when it occured to me, as you also noted, that
per-transaction state information breaks pre-production and/or caching of
status responses, I backed it out on the principle that simplicity is a
good thing.

Now, it does seem to me that the Timestamping and Notary work in front of
us might present a better framework within which to consider Certco's comment.

The same observation regarding cache breakage holds true for prior_to.  I'm
seriously thinking of doing away with the prior_to concept for the same
reason even though I'm attracted to the concept.  It's reflection appears
in the non-too-obvious case of a VALID response with a date_text component.
 This would disambiguate the example you cited, (given an update to Section
3.5 to this effect) but I'm coming to question the utility of prior_to.  It
exists in reponse to the historical non-repudiation requirement, but it
seems to me that this requirement is less concerned with timeliness than
historical accuracy.  OCSP is all about timeliness; the current status of
the certificate.  Elimination of prior_to would also eliminate the case of
the example cited, since there would be no means to produce the example case.

>
>3. In a request, either the full certificate or a hash of the Issuer DN
>and cert serial number is included.  Why a hash?  It would seem to me
>that the responder now has to have some database of all possible hashes
>and their corresponding Issuer DN's and serial numbers.  After that, it
>then may have to go off and find information in the certificate in order
>to determine its revocation status.  It makes more sense to me to
>include the certificate in the request.  This is what we did in the
>Notary document.

Mostly bandwidth, scalability, etc.  Hash calculations can be done at CPU
speed while data communications are i/o-bound.  I'm anticipating services
capable of handling many thousands of requests per day and would thus
quickly become sensitive to aggregate data volume.  Also, these hashes do
indeed make excellent database index values.  They can be used to
accelerate responsiveness for servers or services that choose to take
advantage of the effect.

>
>4. In Section 2.2 it is stated that "... the path validation logic
>implied by the VALID and INVALID indicators is that defined by PKIX Part
>1."  Now, issues of whether or not a certificate is valid, invalid or
>inactive are separate and can't really be made properly by an OCSP
>server since it doesn't have the information about what is acceptable to
>the application (e.g. acceptable policy identifiers). There seems to be
>a basic assumption that the OCSP server (or some process associated with
>it) can do the whole certificate validation process (including chain
>processing), but this process will need to be somewhat dependent on the
>application and potentially other constraints imposed by the security
>policy within which a relying party is operating.  To deal with this
>problem, we included an optional SEQUENCE OF Certificate in the request
>that can be used to indicate the chain of trust to be verified as well
>as optional PolicyInformation that can be used to include the policy
>under which the validation should take place.

I discussed the point with Denis, who had essentially the same concerns
regarding presumptions of a fixed policy.  By clearly specifying that only
a single certificate is included, the selection of a Responder can be at
the user's discretion.  Thus the protocol as a technical specification
asserts no constraints on the underlying trust model.

Also, it's important to note that many Responders will in all likelihood be
one's CA.  The trust model in this case is well defined.  Including its
specification in the request inflates the size of the request with no added
value.

>5. Why not ASN.1?  This is PKIX after all.  Everything else was done
>here using ASN.1, so certainly any application using this service should
>be capable of handling it.  This seems an odd choice.

HTTP Servers are forming an increasingly dominant component of the Internet
technical infrastructure.  It seems to me that a proposal that seeks to
establish server-type capabilities would do the Internet well by leveraging
this infrastructure.  There exists commonly accepting mechanisms--and
widely available tools--for interfacing to HTTP servers.  And while it is
the case that many PKI developments are ASN.1 fluent and equipped, there
are a substantial (and increasing) number to whom certificate parsing is a
function call, not a T-L-V crawl.

>Given the above comments, I have my doubts about the viability of this
>type of service when used instead of CRLs.

Clearly there exists many uses of public key technology that are better
served by local storage of a CA's most recent CRL (the most esoteric case I
can think of involves Naval operations under radio silence where the CA is
ashore).  But having said that, OCSP addresses well-known and long-held
concerns over CRL size timeliness.

>As a supplement to CRLs, for
>certain circumstances this type of service may be useful.

Agreed.  I wouldn't propose to throw out CRLs.

>This is why
>we developed our Notary proposal as we did.  It is to be used just as a
>supplement to CRLs, and it provides more services than just determining
>the revocation status of certificates.  As I stated in Munich, it can
>also validate signatures and other types of data.  
>In order to satisfy the wishes of the group as expressed in Munich (that
>the WG not consider our Time Stamp and Notary documents until Parts 1-4
>are complete), we have not submitted the updated documents to the PKIX
>group, but instead submitted them independantly.  They should be
>available from the ftp site soon.  In the meantime, they are available
>at http://www.entrust.com/downloads/time.txt and
>http://www.entrust.com/downloads/notary.txt
>
>
>Thank you,
>
>	Robert Zuccherato
>	Entrust Technologies
>
>
>
>

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Michelle Casagni'" <[email-masked]>
Subject: RE: Policy Contraints
Date: Wed, 12 Nov 1997 09:25:37 -0500
Status:

>From: 	Michelle Casagni[SMTP:[email-masked]]

>The definition of Policy Contraints in the X.509 DAM on page 31 is
>  PolicyConstraints ::= SEQUENCE { ...
>
>and on page 67 it is
>  PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { ...
>
>Could you please let me know which one is the correct definition?
>
According to the updated copy of X.509 that I obtained from

	ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x525final.doc

it is

>	  PolicyConstraints ::= SEQUENCE { ...

pww

Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3690

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Policy Contraints
Date: Wed, 12 Nov 1997 09:52:36 -0500
Status:

>Of course, that should be 
>
>	ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
>
>pww
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3690
>
>
>
>----------
>From: 	Peter Whittaker
>Sent: 	Wednesday, November 12, 1997 9:25 AM
>To: 	[email-masked]; 'Michelle Casagni'
>Subject: 	RE: Policy Contraints
>
>From: 	Michelle Casagni[SMTP:[email-masked]]
>
>The definition of Policy Contraints in the X.509 DAM on page 31 is
>  PolicyConstraints ::= SEQUENCE { ...
>
>and on page 67 it is
>  PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { ...
>
>Could you please let me know which one is the correct definition?
>
>According to the updated copy of X.509 that I obtained from
>
>	ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x525final.doc
>
>it is
>
>	  PolicyConstraints ::= SEQUENCE { ...
>
>pww
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3690
>
>
>
>

Date: Mon, 10 Nov 1997 12:55:40 -0500
To: Sharon Boeyen <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Last Call: PKIX-2 LDAPv2
Cc: [email-masked]
Status:

Sharon:

RE: Multivalued attributes

I think that the proposed text is needed.  I know of at least one widely
deployed LDAP client that does not support multivalued attributes.

RE: DN in cert different from DN of entry

There are a few cases where the DN in the certificate should be different
than the DN of the DIT entry.  While these cases are rare, the LDAP
specification must permit them to exist.

Russ

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Last Call: PKIX-2 LDAPv2
Date: Wed, 12 Nov 1997 07:57:53 -0500
Status:

I'll add the clarifying text and submitted the final text of the
document.

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

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

>----------
>From: 	Russ Housley[SMTP:[email-masked]]
>Sent: 	November 10, 1997 12:55 PM
>To: 	Sharon Boeyen
>Cc: 	[email-masked]
>Subject: 	RE: Last Call: PKIX-2 LDAPv2
>
>Sharon:
>
>RE: Multivalued attributes
>
>I think that the proposed text is needed.  I know of at least one widely
>deployed LDAP client that does not support multivalued attributes.
>
>
>RE: DN in cert different from DN of entry
>
>There are a few cases where the DN in the certificate should be different
>than the DN of the DIT entry.  While these cases are rare, the LDAP
>specification must permit them to exist.
>
>
>Russ
>

Date: Wed, 12 Nov 1997 12:50:03 +0800
To: [email-masked]
From: Incheon Paik <[email-masked]>
Subject: Mailing list of SET Implementation
Status:

Hellow,

I am looking for the mailing list about SET implementation.
It would be appreciated if help me.

Thanks,

Incheon Paik.

Date: Tue, 11 Nov 1997 00:31:44 -0400 (EDT)
From: PMDF Mail Server <[email-masked]>
Subject: Undeliverable RFC822 mail: temporarily unable to deliver
To: [email-masked]
Status:

Your message could not be delivered to: 

    [email-masked]

Your message has been enqueued and undeliverable for 4 hours.
The mail system will continue to try to deliver your message
for an additional 116 hours.

Date: Mon, 10 Nov 1997 16:33:41 -0800
From: [email-masked]
Subject: Re: utilizing UR?s in PKI?
Sender: [email-masked]
To: Public Key Infrastructure <[email-masked]>
Reply-to: [email-masked]

> I never thought about it.  What advantages does URNs offer?

I'm not way up-to-speed on URNs either. Tho, here's what RFC1737 says about 
URNs/URLs/URCs...

   o  The purpose or function of a URN is to provide a globally unique,
      persistent identifier used for recognition, for access to
      characteristics of the resource or for access to the resource
      itself.

..which seems innaresting from the PKI perspective. Quotes from a couple of 
their docs and abstracts of the current drafts are below.

Jeff
---------------
>From the intro to RFC1737...

   This document specifies a minimum set of requirements for a kind of
   Internet resource identifier known as Uniform Resource Names (URNs).
   URNs fit within a larger Internet information architecture, which in
   turn is composed of, additionally, Uniform Resource Characteristics

Date: Tue, 11 Nov 1997 09:18:08 -0800
From: "Thane E. Plambeck" <[email-masked]>
To: [email-masked]
Subject: subscribe
Status:

subscribe

Date: Tue, 11 Nov 1997 11:00:15 -0500
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Cc: "[email-masked]'" <[email-masked]>
Status:

<x-rich>>>>>

<excerpt>At 03:17 PM 11/10/97 -0500, Carlisle Adams wrote:

>Thoughts?

Having a separate glossary is probably a good idea. It shouldn't take too 

long (I hope) to put one together. I'll ask the IESG (we are at a two day 

face-to-face meeting today and tomorrow) if we can move forward without a 

glossary at this point and plan to add one before the document goes to
Draft 

Standard.

                           -Jeff

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

We discussed this at the IESG Retreat today (within the hour). The
consensus 

is that a separate glossary document would be a great ideal *and* we
don't 

need to hold up the Part III document to wait for it. The sense was that
as 

long as the terms defined were understood by "those practiced in the art" 

then we don't have to wait for the glossary document.

                             -Jeff
</x-rich>

From: [email-masked]
Date: Tue, 11 Nov 1997 08:25:13 -0500
To: [email-masked]
Original-From: "Dale.G.Blodgett" <[email-masked]>
Subject: not on vacation (was Re: utilizing UR?s in PKI? )
Status:

At 04:33 PM 11/10/97 -0800, you wrote:
>> I never thought about it.  What advantages does URNs offer?
>
>I'm not way up-to-speed on URNs either. Tho, here's what RFC1737 says about 
>URNs/URLs/URCs...
>
>   o  The purpose or function of a URN is to provide a globally unique,
>      persistent identifier used for recognition, for access to
>      characteristics of the resource or for access to the resource
>      itself.
>
>..which seems innaresting from the PKI perspective. Quotes from a couple of 
>their docs and abstracts of the current drafts are below.
>
>Jeff
>---------------
>>From the intro to RFC1737...
>
>   This document specifies a minimum set of requirements for a kind of
>   Internet resource identifier known as Uniform Resource Names (URNs).
>   URNs fit within a larger Internet information architecture, which in
>   turn is composed of, additionally, Uniform Resource Characteristics
>   (URCs), and Uniform Resource Locators (URLs).  URNs are used for
>   identification, URCs for including meta-information, and URLs for
>   locating or finding resources.
>			.
>			.
>			.
>   The requirements for Uniform Resource Names fit within the overall
>   architecture of Uniform Resource Identification.  In order to build
>   applications in the most general case, the user must be able to
>   discover and identify the information, objects, or what we will call
>   in this architecture resources, on which the application is to
>   operate.  Beyond this statement, the URI architecture does not define
>   "resource."  As the network and interconnectivity grow, the ability
>   to make use of remote, perhaps independently managed, resources will
>   become more and more important.  This activity of discovering and
>   utilizing resources can be broken down into those activities where
>   one of the primary constraints is human utility and facility and
>   those in which human involvement is small or nonexistent.  Human
>   naming must have such characteristics as being both mnemonic and
>   short.  Humans, in contrast with computers, are good at heuristic
>   disambiguation and wide variability in structure.  In order for
>   computer and network based systems to support global naming and
>   access to resources that have perhaps an indeterminate lifetime, the
>   flexibility and attendant unreliability of human-friendly names
>   should be translated into a naming infrastructure more appropriate
>   for the underlying support system.  It is this underlying support
>   system that the Internet Information Infrastructure Architecture
>   (IIIA) is addressing.
>
>   Within the IIIA, several sorts of information about resources are
>   specified and divided among different sorts of structures, along
>   functional lines.  In order to access information, one must be able
>   to discover or identify the particular information desired,
>   determined both how and where it might be used or accessed.  The
>   partitioning of the functionality in this architecture is into
>   uniform resource names (URN), uniform resource characteristics (URC),
>   and uniform resource locators (URL).  A URN identifies a resource or
>   unit of information.  It may identify, for example, intellectual
>   content, a particular presentation of intellectual content, or
>   whatever a name assignment authority determines is a distinctly
>   namable entity.  A URL identifies the location or a container for an
>   instance of a resource identified by a URN.  The resource identified
>   by a URN may reside in one or more locations at any given time, may
>   move, or may not be available at all.  Of course, not all resources
>   will move during their lifetimes, and not all resources, although
>   identifiable and identified by a URN will be instantiated at any
>   given time.  As such a URL is identifying a place where a resource
>   may reside, or a container, as distinct from the resource itself
>   identified by the URN.  A URC is a set of meta-level information
>   about a resource.  Some examples of such meta-information are: owner,
>   encoding, access restrictions (perhaps for particular instances),
>   cost.
>
>   With this in mind, we can make the following statement:
>
>   o  The purpose or function of a URN is to provide a globally unique,
>      persistent identifier used for recognition, for access to
>      characteristics of the resource or for access to the resource
>      itself.
>
>   More specifically, there are two kinds of requirements on URNs:
>   requirements on the functional capabilities of URNs, and requirements
>   on the way URNs are encoded in data streams and written
>   communications.
>
>
>>From draft-ietf-urn-syntax-05.txt....
>
>Abstract
>
>   Uniform Resource Names (URNs) are intended to serve as persistent,
>   location-independent, resource identifiers. This document sets
>   forward the canonical syntax for URNs.  A discussion of both existing
>   legacy and new namespaces and requirements for URN presentation and
>   transmission are presented.  Finally, there is a discussion of URN
>   equivalence and how to determine it.
>
>
>		-------------------------------------------------
>
>URN draft abstracts...
>
>
>http://info.internet.isi.edu:80/R820419-825216-1m/in-drafts/id-abstracts.html
>
>
>Uniform Resource Names (urn) 
>
>"Architectural Principles of Uniform Resource Name Resolution", K. Sollins,
>09/26/1997, <draft-ietf-urn-req-frame-04.txt> 
>       This document addresses the issues of the discovery of URN (Uniform
>       Resource Name) resolver services that in turn will directly
translate URNs into
>       URLs (Uniform Resource Locators) and URCs (Uniform Resource
>       Characteristics). The document falls into three major parts, the
assumptions
>       underlying the work, the guidelines in order to be a viable
Resolver Discovery
>       Service or RDS, and a framework for designing RDSs. The guidelines
fall into
>       three principle areas: evolvability, usability, and security and
privacy. An RDS
>       that is compliant with the framework will not necessarily be
compliant with the
>       guidelines. Compliance with the guidelines will need to be
validated separately.
>
>"Namespace Identifier Requirements for URN Services", Patrik Faltstrom, R.
>Iannella, 03/27/1997, <draft-ietf-urn-nid-req-01.txt> 
>       Services that offer to resolve Uniform Resource Names implicitly
require that
>       they support a persistent and reliable service for an indeterminate
length of
>       time. This draft outlines the requirements for any such service
that wishes to
>       participate as a Namespace Identifier. 
>
>"URI Resolution Services Necessary for URN Resolution", M. Mealling, R.
Daniel,
>08/09/1997, <draft-ietf-urn-resolution-services-03.txt> 
>       Retrieving the resource identified by a Uniform Resource Identifier
(URI) [3] is
>       only one of the operations that can be performed on a URI. One
might also ask
>       for and get a list of other identifiers that are aliases for the
original URI or a
>       bibliographic description of the resource the URI denotes, for
example. This
>       applies to both Uniform Resource Names (URNs) and Uniform Resource
>       Locators (URLs). Uniform Resource Characteristics (URCs) are
discussed in
>       this document but only as descriptions of resources rather than
identifiers. 
>       A service in the network providing access to a resource may provide
one or
>       some of these options, but it need not provide all of them. This
memo specifies
>       an initial set of these functions, to be used to describe the
functions provided by
>       any given access service and the requirements that must be met when
those
>       operations are encoded in a protocol. 
>       "Using Existing Bibliographic Identifiers as Uniform Resource
Names", C.
>       Lynch, C. Preston, R. Daniel, 09/26/1997,
<draft-ietf-urn-biblio-02.txt> 
>       A system for Uniform Resource Names (URNs) must be capable of
supporting
>       identifiers from existing widely-used naming systems. This document
>       discusses how three major bibliographic identifiers (the ISBN, ISSN
and SICI)
>       can be supported within the URN framework and the currently proposed
>       syntax for URNs. 
>
>"URN Syntax", R. Moats, 05/05/1997, <draft-ietf-urn-syntax-05.txt> 
>       Uniform Resource Names (URNs) are intended to serve as persistent,
>       location-independent, resource identifiers. This document sets
forward the
>       canonical syntax for URNs. A discussion of both existing legacy and
new
>       namespaces and requirements for URN presentation and transmission are
>       presented. Finally, there is a discussion of URN equivalence and
how to
>       determine it. 
>
>"A URN Namespace for IETF Documents", R. Moats, 07/14/1997,
><draft-ietf-urn-ietf-02.txt> 
>       A system for Uniform Resource Names (URNs) must be capable of
supporting
>       new naming systems. As an example of how a new namespace may be
>       proposed, this document presents a naming system based on the RFC
family of
>       documents (RFCs, STDs, and FYIs) developed by the IETF and
published by
>       the RFC editor and the minutes of working groups (WG) and birds of
a feather
>       (BOF) meetings that occur during IETF conferences. This namespace
can be
>       supported within the URN framework and the currently proposed
syntax for
>       URNs. 
>
>
>
>
>
>
>
>
>
>
This is a test.  Sorry to bug you.

Date: Mon, 10 Nov 1997 16:29:47 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Status:

A seaparate, standardized PKIX glossary would be wonderfully helpful - it gets my vote.

michael

>>> Carlisle Adams <[email-masked]> 11/10/97 01:17PM >>>
Hi Jeff,

Thanks for the comments.  I will issue a revised Internet Draft within
the next couple of days.

I have one slight counter-proposal, though.  I wonder if you can give us
your feedback on this:

>----------
>From:  Jeffrey I. Schiller[SMTP:[email-masked]] 
>Sent:  Sunday, November 09, 1997 3:37 PM
>To:  Carlisle Adams; [email-masked]; [email-masked]; [email-masked] 
>Cc:  [email-masked] 
>Subject:  Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
>
>Part III Comments <draft-ietf-pkix-ipki3cmp-05.txt>:
>
>General: A Glossary would be a good idea, or a reference early in the 
>document to an introductory document that contains a glossary.

I think that a glossary could usefully be included in this document.
However, there is much overlap in terminology over the full set of PKIX
documents, so that I'm not sure that including it in this particular
document is the best course of action.  My preference would be for the
WG to produce a separate document (targeted as an Informational RFC)
which serves as the "official" glossary for all other documents produced
by the WG.  This glossary can be updated as time goes on (if necessary),
and all other PKIX RFCs and IDs can point to this as the agreed
definition-of-terms for the Internet X.509 PKI.

One negative consequence of the above suggestion is that the current
Certificate Management Protocol spec. would have no glossary to point to
(since it doesn't exist yet).  On the positive side, there is no danger
that  PKIX-CMP would be held up for an indefinite amount of time if (for
whatever reason) "discussion" develops over the precise definitions of
some terms.

Thoughts?

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

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Date: Tue, 11 Nov 1997 02:04:50 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Ashraf Madoukh <[email-masked]>
cc: "'PKIX Mailing List'" <[email-masked]>
Subject: Re: CA Inter-operability test
Status:

Hiya

Feel free to call me to discuss interop. (919) 871 9988.  Same goes for
any other CA's out there.

Cheers,

--
Mark Shuttleworth
Thawte Consulting

Subject: Re: utilizing UR?s in PKI? 
To: Public Key Infrastructure <[email-masked]>
Reply-to: [email-masked]
From: [email-masked]
Date: Mon, 10 Nov 1997 16:33:41 -0800
Sender: [email-masked]
Status:

> I never thought about it.  What advantages does URNs offer?

I'm not way up-to-speed on URNs either. Tho, here's what RFC1737 says about 
URNs/URLs/URCs...

   o  The purpose or function of a URN is to provide a globally unique,
      persistent identifier used for recognition, for access to
      characteristics of the resource or for access to the resource
      itself.

..which seems innaresting from the PKI perspective. Quotes from a couple of 
their docs and abstracts of the current drafts are below.

Jeff
---------------
>From the intro to RFC1737...

   This document specifies a minimum set of requirements for a kind of
   Internet resource identifier known as Uniform Resource Names (URNs).
   URNs fit within a larger Internet information architecture, which in
   turn is composed of, additionally, Uniform Resource Characteristics
   (URCs), and Uniform Resource Locators (URLs).  URNs are used for
   identification, URCs for including meta-information, and URLs for
   locating or finding resources.
			.
			.
			.
   The requirements for Uniform Resource Names fit within the overall
   architecture of Uniform Resource Identification.  In order to build
   applications in the most general case, the user must be able to
   discover and identify the information, objects, or what we will call
   in this architecture resources, on which the application is to
   operate.  Beyond this statement, the URI architecture does not define
   "resource."  As the network and interconnectivity grow, the ability
   to make use of remote, perhaps independently managed, resources will
   become more and more important.  This activity of discovering and
   utilizing resources can be broken down into those activities where
   one of the primary constraints is human utility and facility and
   those in which human involvement is small or nonexistent.  Human
   naming must have such characteristics as being both mnemonic and
   short.  Humans, in contrast with computers, are good at heuristic
   disambiguation and wide variability in structure.  In order for
   computer and network based systems to support global naming and
   access to resources that have perhaps an indeterminate lifetime, the
   flexibility and attendant unreliability of human-friendly names
   should be translated into a naming infrastructure more appropriate
   for the underlying support system.  It is this underlying support
   system that the Internet Information Infrastructure Architecture
   (IIIA) is addressing.

   Within the IIIA, several sorts of information about resources are
   specified and divided among different sorts of structures, along
   functional lines.  In order to access information, one must be able
   to discover or identify the particular information desired,
   determined both how and where it might be used or accessed.  The
   partitioning of the functionality in this architecture is into
   uniform resource names (URN), uniform resource characteristics (URC),
   and uniform resource locators (URL).  A URN identifies a resource or
   unit of information.  It may identify, for example, intellectual
   content, a particular presentation of intellectual content, or
   whatever a name assignment authority determines is a distinctly
   namable entity.  A URL identifies the location or a container for an
   instance of a resource identified by a URN.  The resource identified
   by a URN may reside in one or more locations at any given time, may
   move, or may not be available at all.  Of course, not all resources
   will move during their lifetimes, and not all resources, although
   identifiable and identified by a URN will be instantiated at any
   given time.  As such a URL is identifying a place where a resource
   may reside, or a container, as distinct from the resource itself
   identified by the URN.  A URC is a set of meta-level information
   about a resource.  Some examples of such meta-information are: owner,
   encoding, access restrictions (perhaps for particular instances),
   cost.

   With this in mind, we can make the following statement:

   o  The purpose or function of a URN is to provide a globally unique,
      persistent identifier used for recognition, for access to
      characteristics of the resource or for access to the resource
      itself.

   More specifically, there are two kinds of requirements on URNs:
   requirements on the functional capabilities of URNs, and requirements
   on the way URNs are encoded in data streams and written
   communications.

>From draft-ietf-urn-syntax-05.txt....

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.

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

URN draft abstracts...

http://info.internet.isi.edu:80/R820419-825216-1m/in-drafts/id-abstracts.html

Uniform Resource Names (urn) 

"Architectural Principles of Uniform Resource Name Resolution", K. Sollins,
09/26/1997, <draft-ietf-urn-req-frame-04.txt> 
       This document addresses the issues of the discovery of URN (Uniform
       Resource Name) resolver services that in turn will directly translate URNs into
       URLs (Uniform Resource Locators) and URCs (Uniform Resource
       Characteristics). The document falls into three major parts, the assumptions
       underlying the work, the guidelines in order to be a viable Resolver Discovery
       Service or RDS, and a framework for designing RDSs. The guidelines fall into
       three principle areas: evolvability, usability, and security and privacy. An RDS
       that is compliant with the framework will not necessarily be compliant with the
       guidelines. Compliance with the guidelines will need to be validated separately.

"Namespace Identifier Requirements for URN Services", Patrik Faltstrom, R.
Iannella, 03/27/1997, <draft-ietf-urn-nid-req-01.txt> 
       Services that offer to resolve Uniform Resource Names implicitly require that
       they support a persistent and reliable service for an indeterminate length of
       time. This draft outlines the requirements for any such service that wishes to
       participate as a Namespace Identifier. 

"URI Resolution Services Necessary for URN Resolution", M. Mealling, R. Daniel,
08/09/1997, <draft-ietf-urn-resolution-services-03.txt> 
       Retrieving the resource identified by a Uniform Resource Identifier (URI) [3] is
       only one of the operations that can be performed on a URI. One might also ask
       for and get a list of other identifiers that are aliases for the original URI or a
       bibliographic description of the resource the URI denotes, for example. This
       applies to both Uniform Resource Names (URNs) and Uniform Resource
       Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in
       this document but only as descriptions of resources rather than identifiers. 
       A service in the network providing access to a resource may provide one or
       some of these options, but it need not provide all of them. This memo specifies
       an initial set of these functions, to be used to describe the functions provided by
       any given access service and the requirements that must be met when those
       operations are encoded in a protocol. 
       "Using Existing Bibliographic Identifiers as Uniform Resource Names", C.
       Lynch, C. Preston, R. Daniel, 09/26/1997, <draft-ietf-urn-biblio-02.txt> 
       A system for Uniform Resource Names (URNs) must be capable of supporting
       identifiers from existing widely-used naming systems. This document
       discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI)
       can be supported within the URN framework and the currently proposed
       syntax for URNs. 

"URN Syntax", R. Moats, 05/05/1997, <draft-ietf-urn-syntax-05.txt> 
       Uniform Resource Names (URNs) are intended to serve as persistent,
       location-independent, resource identifiers. This document sets forward the
       canonical syntax for URNs. A discussion of both existing legacy and new
       namespaces and requirements for URN presentation and transmission are
       presented. Finally, there is a discussion of URN equivalence and how to
       determine it. 

"A URN Namespace for IETF Documents", R. Moats, 07/14/1997,
<draft-ietf-urn-ietf-02.txt> 
       A system for Uniform Resource Names (URNs) must be capable of supporting
       new naming systems. As an example of how a new namespace may be
       proposed, this document presents a naming system based on the RFC family of
       documents (RFCs, STDs, and FYIs) developed by the IETF and published by
       the RFC editor and the minutes of working groups (WG) and birds of a feather
       (BOF) meetings that occur during IETF conferences. This namespace can be
       supported within the URN framework and the currently proposed syntax for
       URNs. 

Date: Mon, 10 Nov 1997 15:45:19 -0500
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Cc: "[email-masked]'" <[email-masked]>
Status:

Not to add to your workload, but... RFC2119 defines the terms MUST, MAY, 
SHOULD etc. You might want to add a reference to it and state that its 
definitions hold when the words are used in all upper-case in the PKIX 
documents (and arrange for the right words to be capitalized).

                                -Jeff

At 03:17 PM 11/10/97 -0500, Carlisle Adams wrote:
>Hi Jeff,
>
>Thanks for the comments.  I will issue a revised Internet Draft within
>the next couple of days.
>
>I have one slight counter-proposal, though.  I wonder if you can give us
>your feedback on this:
>
>>----------
>>From: 	Jeffrey I. Schiller[SMTP:[email-masked]]
>>Sent: 	Sunday, November 09, 1997 3:37 PM
>>To: 	Carlisle Adams; [email-masked]; [email-masked]; [email-masked]
>>Cc: 	[email-masked]
>>Subject: 	Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
>>
>>Part III Comments <draft-ietf-pkix-ipki3cmp-05.txt>:
>>
>>General: A Glossary would be a good idea, or a reference early in the 
>>document to an introductory document that contains a glossary.
>
>I think that a glossary could usefully be included in this document.
>However, there is much overlap in terminology over the full set of PKIX
>documents, so that I'm not sure that including it in this particular
>document is the best course of action.  My preference would be for the
>WG to produce a separate document (targeted as an Informational RFC)
>which serves as the "official" glossary for all other documents produced
>by the WG.  This glossary can be updated as time goes on (if necessary),
>and all other PKIX RFCs and IDs can point to this as the agreed
>definition-of-terms for the Internet X.509 PKI.
>
>One negative consequence of the above suggestion is that the current
>Certificate Management Protocol spec. would have no glossary to point to
>(since it doesn't exist yet).  On the positive side, there is no danger
>that  PKIX-CMP would be held up for an indefinite amount of time if (for
>whatever reason) "discussion" develops over the precise definitions of
>some terms.
>
>Thoughts?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Last Call: PKIX-2 LDAPv2
Date: Mon, 10 Nov 1997 15:47:33 -0500
Status:

Comments below

------------------
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: 	November 10, 1997 9:14 AM
>To: 	[email-masked]
>Subject: 	RE: Last Call: PKIX-2 LDAPv2
>
>> From: Sharon Boeyen <[email-masked]>
>> 
>> I don't think any change is required to the PKIX LDAP document because
>> LDAP will automatically return all values and any decision making after
>> that is outside the scope of this specification. However if people feel
>> strongly, I'm not opposed to adding some explanatory text along the
>> lines of:
>> 
>>      In the case of multivalued attributes such as userCertificate a
>>  SearchResponse containing this attribute will include all values,
>> assuming the requester had suffficient access permissions. The
>> application/relying party may need to select an appropriate value
>> to be used.
>> 
>> Do people feel this text is really necessary?
>
>I believe it is usually appropriate to include short explanatory/tutorial
>notes in standards, even if there is little need for them among the group
>writing the document.  In this case, there was apparently a need for
>clarification within the PKIX WG; one might expect those less closely
>involved to benefit from an explanatory note even more.
>
>Your suggested wording is excellent - concise and complete.  Please include
>it verbatim.

<Will do.>
>
>
>> 2 DN in cert different from DN of entry
>> 
>> An LDAP SearchResponse which is returning a certificate will include the
>> DN of the entry from which the certificate was retrieved and the
>> certificate itself. There is no LDAP requirements that a DN in the
>> certificate be the same as that of the entry. Any further analysis of
>> the certificate by the end-entity is outside the scope of this LDAP
>> profile.
>
>This is scary.  LDAP, being an access protocol, does not have jurisdiction
>over the contents of Directory (or directory, in the case of non-X.500
>back-end database) entries.  But one would hope that any LDAP-accessible
>server would maintain consistency between DNs in the query and DNs in
>the returned certificates.  Otherwise, aren't the applicable matching
>rules meaningless?

< Remember that in the case of an LDAP repository read service request,
the requester will specify the DN of the entry from which it wants to
retrieve certificate(s). The LDAP server will return this same DN in the
response along with the certificate(s) it retrieved from that entry. In
the case of an LDAP repository search service request, the requester
will specify a DN of an entry from which they wish to root the search,
some scoping information and  a attribute based filter that the entries
within the scope get tested against. The response would also contain and
relevant entry DN information from entry returned. 

If you want to search for a certificate for which you know the
associated email address only, the LDAP repository search service will
let you root your search at a particular point (e.g. a corporation) and
search below there for entries containing the email address type/value
assertion you provide and then return the certificate(s) from that
entry. The response will also include the DN of the entry where the
match occured. 

I think the protocol part is fine and will behave predictably. If people
choose not to put DNs in certificates, they won't be able to establish
the close linkage with the DN of the holding entry. That may or may not
be meaningful to the application. These issues are really directory
schema ones more than protocol and there has been some suggestions
within the PKIX WG that there might be a need to work on minimal schema
specification for PKI. If that work did proceed, these issues should be
rolled into it.  > 
> 
>In the case of a certificate with NULL or empty DNs, perhaps it would be
>possible to allow NULL to be an automatic wildcard match to any DN
>specified in the query.  But I think this is a bad idea - it would make it
>impossible to query explicitly for certificates with NULL DNs.  A better
>approach would be to fail to match NULL DNs with explicit DNs, and require
>queries for potentially email-only certs to be of the form
>"dn=xxx OR email=yyy@z".

>

Date: Mon, 10 Nov 1997 15:47:39 -0500
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Cc: "[email-masked]'" <[email-masked]>
Status:

At 03:17 PM 11/10/97 -0500, Carlisle Adams wrote:
>Thoughts?

Having a separate glossary is probably a good idea. It shouldn't take too 
long (I hope) to put one together. I'll ask the IESG (we are at a two day 
face-to-face meeting today and tomorrow) if we can move forward without a 
glossary at this point and plan to add one before the document goes to Draft 
Standard.

                           -Jeff

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Jeffrey I. Schiller'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Date: Mon, 10 Nov 1997 15:17:45 -0500
Status:

Hi Jeff,

Thanks for the comments.  I will issue a revised Internet Draft within
the next couple of days.

I have one slight counter-proposal, though.  I wonder if you can give us
your feedback on this:

>----------
>From: 	Jeffrey I. Schiller[SMTP:[email-masked]]
>Sent: 	Sunday, November 09, 1997 3:37 PM
>To: 	Carlisle Adams; [email-masked]; [email-masked]; [email-masked]
>Cc: 	[email-masked]
>Subject: 	Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
>
>Part III Comments <draft-ietf-pkix-ipki3cmp-05.txt>:
>
>General: A Glossary would be a good idea, or a reference early in the 
>document to an introductory document that contains a glossary.

I think that a glossary could usefully be included in this document.
However, there is much overlap in terminology over the full set of PKIX
documents, so that I'm not sure that including it in this particular
document is the best course of action.  My preference would be for the
WG to produce a separate document (targeted as an Informational RFC)
which serves as the "official" glossary for all other documents produced
by the WG.  This glossary can be updated as time goes on (if necessary),
and all other PKIX RFCs and IDs can point to this as the agreed
definition-of-terms for the Internet X.509 PKI.

One negative consequence of the above suggestion is that the current
Certificate Management Protocol spec. would have no glossary to point to
(since it doesn't exist yet).  On the positive side, there is no danger
that  PKIX-CMP would be held up for an indefinite amount of time if (for
whatever reason) "discussion" develops over the precise definitions of
some terms.

Thoughts?

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

From: Ashraf Madoukh <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: CA Inter-operability test
Date: Mon, 10 Nov 1997 14:19:06 -0600
Status:

Hi,

I developed a Certification Authority based on X.509 version 3. I would like to know how to do inter-operability tests between our CA and others?

Thanks,

Ashraf Madoukh
Sprint
(913) 534-6543
[email-masked]

From: Ashraf Madoukh <[email-masked]>
To: "'PKIX Mailing List'" <[email-masked]>
Subject: CA Inter-operability test
Date: Mon, 10 Nov 1997 14:04:53 -0600
Status:

Hi,

I developed a Certification Authority based on X.509 version 3. I would like to know how to do inter-operability tests between our CA and others?

Thanks,

Ashraf Madoukh
Sprint
(913) 534-6543
[email-masked]

From: Rob Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: OCSP Questions
Date: Mon, 10 Nov 1997 13:43:43 -0500
Status:

I have been reading over the recently submitted draft for OCSP.  As some
people mentioned in Munich, the Notary service that I talked about there
is very similar to an OCSP service, and I see that the author of the
OCSP draft is struggling with many of the same problems that we
struggled with when devising our protocol.  In this light, I have a few
questions that I would like to ask Mike about his document.

1. In Section 3.1 it appears that CAs must include in certificates the
URI of the OCSP responder that end entities are to use for the
certificate.  I guess that this means the URI must appear in the
responder's certificate (in SubjectAltName?) in order for end entities
to match responders with certificates.  Even so, what value would appear
in the AuthorityInfoAccess field of an OCSP responders certificate?
Certainly it could not be its own URI, since then revocation would be
impossible.  So it must be the URI of some other responder.  But then
what goes in the AuthorityInfoAccess field of that responders
certificate?  Where does this chain end?  This is a nontrivial question
because whenever I verify a signature on an OCSP response I will have to
follow this chain.  In our Notary protocol we decided that it was not a
good idea to include the information about which server to use in the
certificate.  It is left up to the end entity which Notary to use. Also,
the Notaries must have the extended key usage field extension in their
certificates indicating that they are Notaries.  This way if things go
wrong, the certificates can be revoked and placed on ARLs and end
entities aren't tied to one service.  

2. I am not quite sure how to match up OCSP responses with requests.
For example, suppose I send two requests to an OCSP responder concerning
the same certificate.  On one I wish to find its revocation status today
and on the other I wish to find its revocation status last month.  Now I
get back two responses, one saying VALID and the other saying INVALID.
According to Section 3.5, bullet 1, I am supposed to match the responses
to requests using the identified certificates, but both responses and
requests contain the same certificate.  It appears, in Section 4.1, that
the possibility of including a trans_id in the request was considered,
but it isn't clear exactly where this would appear.  Also, it doesn't
appear in the response.  If one did include trans_id in the responses,
then caching signed responses (as suggested in Section 2.2) is not
possible.  Certainly, not being able to match up responses with requests
leaves one open to replay attacks.  In the Notary document, in order to
prevent such attacks, we include the time for which notarization was
requested and the requester's name in the response.  This does not allow
caching of responses, but it is secure.

3. In a request, either the full certificate or a hash of the Issuer DN
and cert serial number is included.  Why a hash?  It would seem to me
that the responder now has to have some database of all possible hashes
and their corresponding Issuer DN's and serial numbers.  After that, it
then may have to go off and find information in the certificate in order
to determine its revocation status.  It makes more sense to me to
include the certificate in the request.  This is what we did in the
Notary document.

4. In Section 2.2 it is stated that "... the path validation logic
implied by the VALID and INVALID indicators is that defined by PKIX Part
1."  Now, issues of whether or not a certificate is valid, invalid or
inactive are separate and can't really be made properly by an OCSP
server since it doesn't have the information about what is acceptable to
the application (e.g. acceptable policy identifiers). There seems to be
a basic assumption that the OCSP server (or some process associated with
it) can do the whole certificate validation process (including chain
processing), but this process will need to be somewhat dependent on the
application and potentially other constraints imposed by the security
policy within which a relying party is operating.  To deal with this
problem, we included an optional SEQUENCE OF Certificate in the request
that can be used to indicate the chain of trust to be verified as well
as optional PolicyInformation that can be used to include the policy
under which the validation should take place.

5. Why not ASN.1?  This is PKIX after all.  Everything else was done
here using ASN.1, so certainly any application using this service should
be capable of handling it.  This seems an odd choice.

Given the above comments, I have my doubts about the viability of this
type of service when used instead of CRLs.  As a supplement to CRLs, for
certain circumstances this type of service may be useful.  This is why
we developed our Notary proposal as we did.  It is to be used just as a
supplement to CRLs, and it provides more services than just determining
the revocation status of certificates.  As I stated in Munich, it can
also validate signatures and other types of data.  

In order to satisfy the wishes of the group as expressed in Munich (that
the WG not consider our Time Stamp and Notary documents until Parts 1-4
are complete), we have not submitted the updated documents to the PKIX
group, but instead submitted them independantly.  They should be
available from the ftp site soon.  In the meantime, they are available
at http://www.entrust.com/downloads/time.txt and
http://www.entrust.com/downloads/notary.txt

Thank you,

	Robert Zuccherato
	Entrust Technologies

Date: Mon, 10 Nov 1997 09:05:14 -0500 (EST)
From: Michelle Casagni <[email-masked]>
To: [email-masked]
cc: Michelle Casagni <[email-masked]>
Subject: Policy Contraints
Status:

Hi,

The definition of Policy Contraints in the X.509 DAM on page 31 is
  PolicyConstraints ::= SEQUENCE { ...

and on page 67 it is
  PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { ...

Could you please let me know which one is the correct definition?

Thanks,
Michelle Casagni
GTE Internetworking

Date: Mon, 10 Nov 1997 09:14:40 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Last Call: PKIX-2 LDAPv2
Status:

> From: Sharon Boeyen <[email-masked]>
> 
> I don't think any change is required to the PKIX LDAP document because
> LDAP will automatically return all values and any decision making after
> that is outside the scope of this specification. However if people feel
> strongly, I'm not opposed to adding some explanatory text along the
> lines of:
> 
>      In the case of multivalued attributes such as userCertificate a
>  SearchResponse containing this attribute will include all values,
> assuming the requester had suffficient access permissions. The
> application/relying party may need to select an appropriate value
> to be used.
> 
> Do people feel this text is really necessary?

I believe it is usually appropriate to include short explanatory/tutorial
notes in standards, even if there is little need for them among the group
writing the document.  In this case, there was apparently a need for
clarification within the PKIX WG; one might expect those less closely
involved to benefit from an explanatory note even more.

Your suggested wording is excellent - concise and complete.  Please include
it verbatim.

> 2 DN in cert different from DN of entry
> 
> An LDAP SearchResponse which is returning a certificate will include the
> DN of the entry from which the certificate was retrieved and the
> certificate itself. There is no LDAP requirements that a DN in the
> certificate be the same as that of the entry. Any further analysis of
> the certificate by the end-entity is outside the scope of this LDAP
> profile.

This is scary.  LDAP, being an access protocol, does not have jurisdiction
over the contents of Directory (or directory, in the case of non-X.500
back-end database) entries.  But one would hope that any LDAP-accessible
server would maintain consistency between DNs in the query and DNs in
the returned certificates.  Otherwise, aren't the applicable matching
rules meaningless?

In the case of a certificate with NULL or empty DNs, perhaps it would be
possible to allow NULL to be an automatic wildcard match to any DN
specified in the query.  But I think this is a bad idea - it would make it
impossible to query explicitly for certificates with NULL DNs.  A better
approach would be to fail to match NULL DNs with explicit DNs, and require
queries for potentially email-only certs to be of the form
"dn=xxx OR email=yyy@z".

Date: Mon, 10 Nov 1997 09:07:31 -0500
To: Public Key Infrastructure <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: utilizing UR?s in PKI?
Status:

Jeff:

I never thought about it.  What advantages does URNs offer?

Russ

At 05:14 PM 11/9/97 -0800, you wrote:
>I notice that draft-ietf-pkix-ipki-part1-06.txt explicitly references & 
>utilizes URLs. I'm curious as to whether folks thought about also utilizing 
>URNs?
>
>thanks,
>
>Jeff
>
>
>

Subject: utilizing UR?s in PKI?
To: Public Key Infrastructure <[email-masked]>
From: [email-masked]
Reply-to: Public Key Infrastructure <[email-masked]>
Date: Sun, 09 Nov 1997 17:14:00 -0800
Sender: [email-masked]
Status:

I notice that draft-ietf-pkix-ipki-part1-06.txt explicitly references & 
utilizes URLs. I'm curious as to whether folks thought about also utilizing 
URNs?

thanks,

Jeff

Date: Sun, 09 Nov 1997 15:37:33 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: Security AD Review of draft-ietf-pkix-ipki3cmp-05.txt
Cc: [email-masked]
Status:

Good Job to all!

Here are my comments that I typed up as I read the document. The only ones 
that I believe need to be worked on prior to issuance as a Proposed Standard 
are the comments on section 5.2 the "Socket Based Management Protocol." 
However given that fixing this will require another Internet Draft, it 
probably wouldn't hurt to work on some of the other comments as well. All of 
the requested changes are editorial in nature, no change to the fundamental 
protocol is needed. Therefore it is my opinion that once these comments are 
addressed, the document can go forward immediately (i.e., no IETF Wide last 
call will need to be performed, whether or not a working group last call is 
issued is up to the chairs).

Note: I will be issuing an IESG Ballot based on this document (so that IESG 
members read the document and raise any issues that they have that I haven't 
thought of).

                                   -Jeff

Part III Comments <draft-ietf-pkix-ipki3cmp-05.txt>:

Title Change: As per previous e-mail, the title should be changed to:

"The Internet X.509 Public Key Infrastructure: Certificate Management 
Protocols"

General: A Glossary would be a good idea, or a reference early in the 
document to an introductory document that contains a glossary.

Section 1: Spell out "Certification Authority" prior to the first use of the 
acronym "CA." In the rest of the document spell out each acronym prior to 
its first use.

Section 1.2 (or an additional section): Define "Certificate," make mention 
that the use of the term Certificate in this document refers to an X.509 
(v3?) Certificate, give an appropriate reference.

>From section 1.3 (requirements)

> 10. Final authority for certification creation rests with the CA; no 
> RA or end-entity equipment can assume that any certificate issued by a 
> CA will contain what was requested -- a CA may alter certificate field 
> values or may add, delete or alter extensions according to its operating 
> policy; the only exception to this is the public key, which the CA must 
> not modify (assuming that the CA was presented with the public key 
> value). In other words, all PKI entities (end-entities, RAs, and CAs) 
> must be capable of handling responses to requests for certificates in 
> which the actual certificate issued is different from that requested  
> (for example, a CA may shorten the validity period requested). 

Hmm. There is an interesting paper that I saw a pre-publication copy of (I 
believe it is by Lily Chan). The idea in the paper is that the CA alters an 
end-entities public key and creates a factor which can be added to an 
end-users private key so that they now have the private key for the altered 
public key. This technique works straight-forwardly for DSS, but can be 
applied to RSA (if you don't mind using three-prime RSA). Their are two 
reasons for performing such a transformation:

1. To make sure that an end-entity cannot use someone else's public key 
(though the PKI management protocols should be able to address this one 
directly).

2. To add CA generated randomness to an end-user key. This is a cute 
technique for dealing with the risk that an end-user isn't using good 
randomness. If this technique is applied, and later it is discovered that 
end-user software has a problem with random number generation, the risk of 
key compromise is significantly reduced provided that the CA was using good 
randomness (which it is in a better position to produce) and the CA is 
trusted to not take advantage of the end-user random number generator weakness.

It may be a good idea to re-word this requirement to not preclude such an 
enhancement.

Section 5.2 "Socket Based Management Protocol":

Is this protocol layered on top of TCP or UDP. The term "socket" is a very 
implementation specific one. Perhaps the protocol should be called "Direct 
TCP based Management Protocol" (assuming you mean TCP here instead of UDP).

> A "socket PKI message" consists of:
> 
>       length (32-bits), flag (8-bits), value (defined below)

You should state what byte order the length field is presented in (network 
byte order?). Ah the joys of *not* using DER. Similarly all other 32 bit 
values need to have their byte order defined.

Sections 5.3 and 5.4 (Mail and HTTP transport):

Drop the "x-" from the MIME type. As in Internet Standard Protocol, the 
Certificate Management Protocol should have officially assigned and 
recognized values for the MIME type. You might want to add words that state 
that implementations may wish to recognize the "x-" style types (and respond 
in kind) in order to support backward compatibility with existing 
implementations.
-----

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "'Andreas Berger'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Last Call: PKIX-2 LDAPv2
Date: Fri, 7 Nov 1997 16:34:27 -0500
Status:

1  Multivalued attributes

The userCertificate attribute is a multivalued attribute and an LDAP
query to retrieve this attribute would retrieve all values of that
attribute in the specified entry, assuming the requester has permission
to read all the values. This is basic vanilla LDAP functionality. 

I don't think any change is required to the PKIX LDAP document because
LDAP will automatically return all values and any decision making after
that is outside the scope of this specification. However if people feel
strongly, I'm not opposed to adding some explanatory text along the
lines of:

     In the case of multivalued attributes such as userCertificate a
 SearchResponse containing this attribute will include all values,
assuming      the requester had suffficient access permissions. The
application/relying                party may need to select
anappropriate value to be used.

Do people feel this text is really necessary?

2 DN in cert different from DN of entry

An LDAP SearchResponse which is returning a certificate will include the
DN of the entry from which the certificate was retrieved and the
certificate itself. There is no LDAP requirements that a DN in the
certificate be the same as that of the entry. Any further analysis of
the certificate by the end-entity is outside the scope of this LDAP
profile.

3 User write certs into directory

There were two points being made by this paragraph. One is that an entry
may contain multiple certificates and that one CA should not be able to
modify/delete certificates issued by and put in the directory by another
CA. This other point was that only CAs have permission to
add/modify/delete certificates.

You do raise an interesting scenario though and I agree that if
employees of a corporation were obtaining certificates which are to be
used by them in their roles as employees these certificates would likely
be added to a corporate directory. If the CA is outside the corporation,
they probably will not be provided direct write permission to the
corporate directory and corporate policy would likely dictate whether
the users could add these values themselves or whether a Directory
Administrator would. In either case it wouldn't be the external CA,
although that CA might also have a public directory service which might
contain these certificates. 

My suggestion would be to take the subscriber (end-entity)entries bullet
out of the list of bullets and put it separately below that list, with
the following text:

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

For subscriber (end-entity) entries:

- The CA, or other appointed entity (e.g. Directory Administrator or
end-  entity themselves) must have add, modify and delete permission to
the   attribute userCertificate and all vaules of that attribute issued
by that CA or   under the responsibility of that appointed entity. A CA
or other appointed   entity may not have modify or delete permission for
any value unless they   also have  add permission for that same value.

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

Does that text address the issue satisfactorily?

Thanks,
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: 	November 7, 1997 5:14 AM
>To: 	Russ Housley
>Cc: 	[email-masked]
>Subject: 	Re: Last Call: PKIX-2 LDAPv2
>
><<File: smime.p7s>>
>Russ Housley wrote:
>> 
>> PKIX-2 Readers:
>> 
>> The current document does not discuss the handling of multivalued
>>attributes.
>> Yet, the certificate attribute is multivalued.  I would like to make sure
>> that LDAP clients are prepared to handle more than one certificate stored
>> in the certificate attribute.
>> 
>> How do others feel?
>> 
>> Russ
>I also agree with that. However, this does also imply that client
>software has to make a decision which certificate to use, either
>automatically or by letting the user choose.
>
>How do we react to certificates, where the entry's DN does not match the
>subject DN in the certificate? This is probably valid when certificates
>are issued, where the eMail address is the only information about the
>subject (via an alternative subject name).
>
>Another point I found in draft-ietf-pkix-ipki2opp-04.txt:
>
>...
>  The CA MUST have access control permissions allowing it to:
>
>       For CA entries:
>         - add, modify and delete all PKI attributes for its
>           own directory entry;
>         - add, modify and delete all values of these attributes.
>
>       For CRL distribution point entries (if used):
>         - create, modify and delete entries of object class
>           cRLDistributionPoint immediately subordinate to its own
>           entry;
>         - add, modify and delete all attributes, and all values of
>           these attributes for these entries.
>
>       For subscriber (end-entity) entries:
>         - add, modify and delete the attribute userCertificate and
>           all values of that attribute, issued by this CA
>           to/from these entries.
>
>      The CA is the ONLY entity with these permissions.
>...
>
>I have a problem with a CA having access to an end-entity's
>userCertificate attribute. I see the need to let a CA write an issued
>certificate into an EE's entry, but I see no reason to make this a MUST.
>Why shouldn't we allow a CA to issue certificates to EE and let the EE
>choose if and where to publish them?
>
>(e.g. I get a certificate from a commercial CA for use with my eMail.
>This CA will alomost certainly not have any access to my employer's
>directory service)
>
>Andreas
>-- 
>Love is dead in Metropolis
>  -- Anne Clark, Sleeper in Metropolis
>

Date: Fri, 07 Nov 1997 10:29:52 -0800
From: Greg Powers <[email-masked]>
Reply-To: [email-masked]
Organization: Entriade Systems
To: [email-masked]
Subject: unsubscribe 
Status:

unsubscribe [email-masked]
unsubscribe
--

<<<< Greg Powers, [email-masked], Entriade Systems, 408-438-5536 >>>>

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Question: Why LDAPv2?
Date: Fri, 7 Nov 1997 11:01:22 -0500
Status:

Harald, 

Here is some background on each of the points you raise. I hope this
helps clarify why we are presently standardizing use of LDAPv2. I
apologize for the length of the message but I'm trying to be
comprehensive to help put this work into the appropriate context for
you. 

Patrick/Tim - anything to add?

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

1 - Why did you choose to profile PKIX over LDAP version 2...?

This has been debated in the PKIX WG as well and also with some of the
leaders of the LDAPv3 work. We see LDAPv3 as a future protocol for PKIX
there are two main reasons for going with LDAPv2 at present 1) deployed
and working installed base and 2) PKIX requirements for access control
and signed operations not yet satisfied by LDAPv3.

At this time we are attempting to provide standards for the X.509 IPKI
based on what is already widely deployed and widely available,
especially in the PKI market. Several PKI products available today use
LDAPv2 and we don't expect this to be instantly replaced by LDAPv3,
especially since in its current form it doesn't provide the added
security features. Therefore we need to standardize the use of LDAPv2
for this application at this time to ensure interoperability among the
PKI LDAP clients and servers which currently exist and are being
currently developed.  

Also, separate from PKI, most of the directory vendors do not yet have
commercially available LDAPv3 products. At the EMA Solutions Summit in
Sept '97, during a directory vendor panel many including Control Data,
ICL, Lotus, Microsoft, Netscape, Novell and Nexor, (listed
alphabetically so as not to upset anyone) announced they plan to have
LDAPv3 in 1998, some earlier in the year and some later. Again, we need
to standardize on what is deployed and works today for PKI.

The other issue with respect to LDAPv3 touches on some of the other
points you raise. We do see that additional security features, when they
are provided for LDAPv3, will hopefully enhance the security of its use
in the PKI environment. We see some requirements for access control as
well as for authenticated/signed operations. This has been discussed in
the PKIX WG and a number of people who participate in PKIX WG are
involved or planning to become involved in the LDAPEXT WG activity on
access control and on signed operations and will provide some input to
those activities with a PKI requirements perspective. There may also be
some use of replication in a PKI environment and hopefully you'll also
see some PKI input in the LDUP activity. Once the security extensions
for LDAPv3 are stable and meet PKI requirements, I believe you will see
some PKIX work on standardizing its use for PKI. 

2 - Given that you subset v2, how is a client to tell that he is talking
     to a server that implements the subset only ... ?

The reason that we defined a subset, rather than just pointing to LDAPv2
is because there are really two different types of PKI implementations 

a) those that are used as part of a general purpose LDAP environment,
where fully conformant LDAP servers  would be deployed (note in each of
the LDAP profile sections of the PKIX LDAP document we say that the
other aspects of the operations MAY also be implemented and 

b) those that are ONLY used in the PKI application in which case
specialized servers and clients would be deployed and only PKIX LDAP
clients would access these specialized servers. 

The profiles outline the minimum that such systems need to support from
the LDAP protocol. In this way, any PKIX LDAP client can access any PKIX
LDAP server and obtain the PKIX LDAP services regardless of whether that
LDAP server is a "restricted" one for PKIX only or a general purpose
one. Therefore, we don't want this profile to be identified as a
separate protocol. For those PKIX LDAP servers that are fully
functioning general LDAP servers, they can also provide LDAP services to
other types of LDAP clients, but the specialized PKIX LDAP servers would
not get accessed by non PKIX LDAP clients. Would the addition of some
clarifying text along these lines help in the PKIX LDAP spec?

3 - Given that you subset v2, if a full LDAPv2 server is in the
situation
     where it would normally send something outside the profile (an
error
     outside the limits for Bind, for instance), what is the server to
do?
     Is this a real problem?

I don't believe this is a real problem because in the profiling of
errors and other responses, we include in the subset any error or
response situation that would arise as a result of a PKIX LDAP specific
request (at least that was our intent and no omissions have been
identified). 

 4 - Given that the problem above is real, how does the server tell that
      it's talking to a restricted client and not to an LDAPv2 client?

I don't believe the problem is real and therefore the LDAP server need
not know whether it is talking to an application-specific client or not.

5 - BTW, it strikes me as the complete epitome of silliness not to
require
    cryptographically strong BINDs when doing CRL updates - as given,
    the document seems to permit a CA to bind to the directory using
    simple authentication (CLEARTEXT PASSWORDS!!!!!!!!)
    It is impossible to fake certificates this way, of course, but the
    ability for an attacker to remove CRLs at will seems to me to make
    the CRL mechanism rather pointless.
    But I may have misunderstood something......

Both certificates and CRLs are signed by the issuing CA, but the ability
to remove either object from a directory entry is an issue as you point
out. CRLs also have within that signed structure two date/time fields
"thisUpdate" which is mandatory and indicates when this update was
issued and "nextUpdate" which is optional and indicates when the next is
expected. However, CRLs could also be issued inside one of these
windows, for instance if a serious compromise situation occured. The
PKIX LDAP draft (section 11) specifies the access controls that need to
be in place (in recogition that there is no standard means to do this in
LDAPv2 ) . Also at the end of section 11 it is stated that "...is not
REQUIRED to implement any additional security features other than those
described herein, however an implementation MAY do so". If, in a
particular environment stronger authentication can be supported, this
profile does not prevent that, however in reality strong authentication
to directory servers is not widely deployed. 

It is specifically these security features which we hope will get added
to LDAPv3 throught the current work in LDAPEXT and assuming that the
solutions provided there satisfy the needs of PKI and become available
in LDAPv3 products I expect you'll see a PKIX specification emerge,
however we are not there today.

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

------------------
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]
To: [email-masked]
Subject: Question: Why LDAPv2?
Date: Fri, 07 Nov 1997 14:12:14 +0100
Sender: [email-masked]
Status:

Attachment converted: Lutefisk:Question- Why LDAPv2? (TEXT/MPGP) (0001C830)

Sender: [email-masked]
Date: Fri, 07 Nov 1997 11:14:24 +0100
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call: PKIX-2 LDAPv2
Status:

Russ Housley wrote:
> 
> PKIX-2 Readers:
> 
> The current document does not discuss the handling of multivalued attributes.
> Yet, the certificate attribute is multivalued.  I would like to make sure
> that LDAP clients are prepared to handle more than one certificate stored
> in the certificate attribute.
> 
> How do others feel?
> 
> Russ
I also agree with that. However, this does also imply that client
software has to make a decision which certificate to use, either
automatically or by letting the user choose.

How do we react to certificates, where the entry's DN does not match the
subject DN in the certificate? This is probably valid when certificates
are issued, where the eMail address is the only information about the
subject (via an alternative subject name).

Another point I found in draft-ietf-pkix-ipki2opp-04.txt:

...
  The CA MUST have access control permissions allowing it to:

       For CA entries:
         - add, modify and delete all PKI attributes for its
           own directory entry;
         - add, modify and delete all values of these attributes.

       For CRL distribution point entries (if used):
         - create, modify and delete entries of object class
           cRLDistributionPoint immediately subordinate to its own
           entry;
         - add, modify and delete all attributes, and all values of
           these attributes for these entries.

       For subscriber (end-entity) entries:
         - add, modify and delete the attribute userCertificate and
           all values of that attribute, issued by this CA
           to/from these entries.

      The CA is the ONLY entity with these permissions.
...

I have a problem with a CA having access to an end-entity's
userCertificate attribute. I see the need to let a CA write an issued
certificate into an EE's entry, but I see no reason to make this a MUST.
Why shouldn't we allow a CA to issue certificates to EE and let the EE
choose if and where to publish them?

(e.g. I get a certificate from a commercial CA for use with my eMail.
This CA will alomost certainly not have any access to my employer's
directory service)

Andreas
-- 
Love is dead in Metropolis
  -- Anne Clark, Sleeper in Metropolis
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 22 (????/----) (0001C82F)

Sender: [email-masked]
Date: Fri, 07 Nov 1997 10:43:20 +0100
From: Michel BERETTA <[email-masked]>
Organization: Hewlett-Packard Company
To: [email-masked]
Subject: subscribe
Status:

  subscribe

From: "Charles Moore" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Re: Last Call: PKIX-2 LDAPv2
Date: Fri, 7 Nov 1997 18:07:08 +1000
Status:

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, 7 November 1997 8:26
Subject: Last Call: PKIX-2 LDAPv2

>PKIX-2 Readers:
>
>The current document does not discuss the handling of multivalued
attributes.
>Yet, the certificate attribute is multivalued.  I would like to make sure
>that LDAP clients are prepared to handle more than one certificate stored
>in the certificate attribute.
>
>How do others feel?
Agree.
>
>Russ

Date: Thu, 06 Nov 1997 16:10:48 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Last Call: PKIX-2 LDAPv2
Status:

PKIX-2 Readers:

The current document does not discuss the handling of multivalued attributes.
Yet, the certificate attribute is multivalued.  I would like to make sure
that LDAP clients are prepared to handle more than one certificate stored
in the certificate attribute.

How do others feel?

Russ

Date: Thu, 06 Nov 1997 12:50:41 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PKIX Part1 -- Certificate Policy Qualifiers
Status:

>Bob, the std algorithm for handling policy values does
>not require that RP accept any of the policies - only that
>if the RP indicates one or more, then the intersection
>rules are followed. IN fact, by default ,one accepts the null set.
>
>None of the ISO extensions can be used for RP enforcement!
>Criticality does not affect how the local system handles a value;
>it only mandates conformance requirements. As you instructed
>me,. one can be non-conforming as one wishes as an implementor.
>There is no IETF or ISO police force.
>
>-
Peter, I'm not sure that I follow you, perhaps because I can't recall what
RP stands for.

Applications can certainly be non-confirming -- there is no Internet police!

But there are purchasing agents, and RFPs, and I anticipate that conformance
with the standard will be regarded as a very important factor in making a
buy decision, especially with regard to something as basic as the critical
indicator.

Applications, and end users, are certainly free to specify additional
constraints as to policies or whatever. But the intent of the critical flag
is to instruct end-user applications of the CA's constraints, as well as the
originator's.  If the relying party ignores such indications, they would do
so at their own risk.  I cannot imagine anyone who would not like to be
informed about such a policy constraint.  Of course, just because a
certificate is invalid, i.e., does not pass all of the syntactic and
semantic checks, that does not mean that the user cannot override that
process and decide to trust the digital signature in any case.  Obviously,
he doesn't even have to have a digital signature -- he could trust the
unsigned document.  So I'm not trying to compel end-users to follow one
particular scenario -- I just want to be sure that they are informed.

To quote the offending paragraph again (second paragraph of 4.2.1.5),

"Applications with specific policy requirements are expected to have a list
of policies which they will accept and to compare the policy OIDs in the
certificate to that list.  If this extension is critical, the path
validation software must be able to interpret this extension, or must reject
the certificate. (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.)

I believe that the parenthetical statement is just flatly wrong.  By and
large, applications (except for special purpose applications) are completely
ignorant of policy requirements, and generally ought to be. I certainly
don't expect my e-mail processor, browser, or proxy filter to be written in
such as way as to support my particular requirements, or yours, since they
might be different.

More to the point, if I am a network administrator, I certainly do not want
to have to run around to 10,000 or more user's systems and customize them
all with whatever security policies I want them to enforce.  Instead, I want
to distribute a self-signed root certificate issued by my company which
cross-certifies one or more public CAs and includes my company's policy ID
restriction, and may do policy cross mapping to the other CA's policy OIDs. 

If some application developer chooses not to be conforming with the PKIX
standards, that's fine with me -- I just won't buy their product.  But the
parenthetical sentence implies that they are able to ignore a critical
indicator and still claim conformance, and that is intolerable, IMHO.

Do you have any comments on the rest of the material?

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: Thu, 06 Nov 1997 11:44:20 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: ABA Digital Signature Guidelines now available electronically
Status:

At long last the American Bar Association has seen the wisdom of allowing
such publications as their Digital Signature Guidelines to be access via the
Internet, and they can now be downloaded for free.  See
http://www.mbc.com/ds_sum.html.

For an interesting analysis and comparison of current states digital
signature legislation, see http://www.mbc.com/ds_rev.html and
http://www.mbc.com/ds_sum.html.

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, 05 Nov 1997 17:20:45 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: PKIX Part1 -- Certificate Policy Qualifiers
Status:

I believe that there are several minor things wrong with the Certificate
Policies section, 4.2.1.5.

The second paragraph presents a viewpoint of a particular application, which
might or might not have specific policy requirements, and the parenthetical
statement says that applications without specific policy requirements are
not required to list acceptable policies, and may accept any valid
certificate regardless of policy even if the policy is marked critical.

I believe that this is (or ought to be) incorrect, as it does not allow for
the case where a superior CA imposes a negotiated policy requirement on all
subordinate CAs. If a certificate issued by a superior CA contains a
requireExplicitPolicy field in the PolicyConstraints extension attribute
then the CA's instructions must be interpreted as trumping whatever the
particular (generic) application understands.  Allowing an application to
violate a critical marking in this case would completely invalidate the
intent of the critical indicator.

The parenthetical sentence should therefore be removed.

When we previously discussed the notion of incorporating  by reference some
form of a legal notice in a certificate, it was understood, I thought, that
a message digest of the referenced text had to be included within the
certificate, in order to prevent the CA itself from modifying the text and
resigning it after the certificate was issued.  The relying party may be
interested in what the CA's current practices are, but it is the version of
the practices that were in effect at the time the certificate was issued
that govern whether or not the certificate is acceptable.

The same requirement would also pertain to a user notice which is being
incorporated by reference.

The following changes should be made:

PolicyQualifierId ::= 
               OBJECT IDENTIFIER (id-qt-cps | id-qt-cps-md | id-qt-unotice |
id-qt-unotice-md )

Qualifier ::= CHOICE {
                cPSNotice   CPSNotice,
                userNotice    UserNotice }

CPSNotice ::= SEQUENCE {
    cPSRef  CPSuri OPTIONAL,
    cPSMd  CPSMessageDigest OPTIONAL)

CPSuri ::= IA5String

CPSMessageDigest ::= PUNT  -- It isn't clear to me exactly what form the MD
ought to take. Should it be confined to the same algorithm type as used for
the certificate itself?  Should it be a full-blown signature, instead of
just a message digest, to allow for complete felxibility?  I'll defer to
others on this point -- any ideas?

With respect to the UserNotice, the semantics are rather opaque, at least to
me.

Does "user" refer to the subscriber/subject of the certificate, or to the
CA, or to the relying party, or all of the above?  This seems unnecessarily
confusing.

The commentary on the noticeRef field seems to imply that the notice ref is
prepared by the CA, and the contents of a particular notice number is
conveyed (out of band?) to application developers, who are supposed to
remember al of the joke numbers of all of the CAs.

But one of the as yet unsolved problems is how to allow the subject of the
certificate to assert his or her own caveats on the use of a certificate,
for his/her own protection.

Maybe, just maybe, the various CAs will recognize this problem and be
amenable to negotiating a set of useful user (subject) notices to be
included, but I have my doubts.

As a user who is about to be issued a certifcate, I would much rather
include in my prototype certificate a uri to my OWN web server, where I
would display my own notices, perhaps in English, Bengali, Urdu, and
Serbo-Croatian, as I see fit.  If I include a sequence of specific uri's
pointing to the different notices in different languages, I don't need a
notice number, but it does become even more important to me, the user, and
to the relying party, that I include a message digest to bind the text of
that notice to the certificate which is being issued to me. Each different
language notice obviously requires a different message digest.

I recognize that CAs might also want to define their own notices, as the
difference between a CPS and a policy notice might be considerable.  I
really shouldn't have to wade through 80 pages of CPS, which tells me more
than I probably need to know about how the CA performs its function -- all I
really need to know is the legal statement of their limis of liability and
disclaimers, and how deep their pockets are.  (This roughly translates to a
reliance limit, which is a somewhat different issue that still needs to be
addressed..)

I'm not going to try to write ASN.1 for these new constructs until or unless
there is some agreement in principle on the basic idea.  But I think the out
of band notice/joke number  concept is impractical, especially as regards
the user's interests.

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, 05 Nov 1997 16:00:13 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: PKIX Part 1 Invalidity date
Status:

Paragraph 5.3.3 Invalidity date (of CRLs) is ambiguous and potentially
misleading. It says:

"The invalidity date is a non-critical CRL entry extension that provides the
date on which it is know or suspected that the private key was compromised
or that the certificate otherwise became invalid. This date may be earlier
than the revocation date in the CRL entry, but must be later than the issue
date of the previously issued CRL."

As written, this could be read as the date when the key was really
compromised (or was allegedly compromised).  Since the discovery of the
compromise might occur a long time after the compromise itself, if the time
between CRLs is sufficiently long this might permit retroactive repudiation.

I would suggest that the language be changed to read "...provides the date
on which a compromise BECAME KNOWN, OR CAME TO BE SUSPECTED, or that the
certificate otherwise became invalid." 

It does very little good to tell someone well after the fact that someone's
keys may have been compromised, except to try to set the stage for
repudiating a transaction which has become odious.

The fact (or claim) that someone's keys might have been compromised, even if
proved, does NOT necessarily mean that the authorized user of the keys
didn't sign the transaction, it only means that someone else might have. 
The consequences depend largely on emerging state and international law as
to who has what burden of proof in such instances, and independent of who
has the burden of proof, who bears the liability if the signature is
successfully disavowed.

What the law will eventually say is anyone's guess, but at least the
technical community can and should go on record as to what we think it ought
to say.

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, 05 Nov 1997 16:19:34 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: PKIX Part 1 -- CRL reason codes
Status:

Section 5.3.1 provides a list of CRL reason codes, which I would like to see
clarified considerably.

The affiliationChanged would seem to include someone who has changed
companies, but it would be unusual language to describe someone who no
longer had a particular role, such as a purchasing agent, or whose title had
changed.

In the case of a residential person, the affiliationChanged would seem to
come to closest to the case where someone has changed their name, either
through marriage or otherwise, or who has changed their address, or maybe
even changed their ISP and/or CA.

The specific semantics of this CRLReason need to be spelled out in
considerably more detail.

There would seem to be a potential overlap and ambiguity in the case of an
affiliationChange and a superseded certificate.  Assuming that someone stays
within a given company, but merely changes departments, or internal mailing
address, etc., which usage should apply when a new certificate is issued? 
Likewise, what should happen if someone changtes their name but keeps the
same public/private keypair?

Under what circumstances is there an obligation to revoke a certificate in
the event a new certificate is issued, and why?  What are the semantics with
regard to the new certificate including the same public key as the old one?

If the "unspecified" reason code is being deprecated in favor of simply not
including the reason code in the first place, why is it even being defined?

I thought we had discussed the inclusion of a "Pending" or "Not Yet
Validated" reason code.  Was this the missing code point 7?  What was the
rationale for not providing such a capability?

Does cessationOfOperation apply to the end user, or the the CA, or either of
the above?

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, 5 Nov 1997 15:51:43 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX 1 Example 1
Status:

Appendix D.1, the Self-Signed certificate, includes a basicConstraint
extension, which has the value "30 00" - an empty sequence. Since cA
defaults to FALSE, this example is a self-signed end-entity cert -- not
a particularly useful thing to have lying around :-).

I'll take an action item to generate a corrected example with cA = TRUE.

Date: Mon, 3 Nov 1997 11:53:25 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: PKIX 1 Comment
Status:

All:

In the 14 Oct PKIX X.509 Certificate and CRL Profile, Appendix A and B
please replace:

Attribute       ::=     SEQUENCE {
        type    AttributeValue,
        values  SET OF AttributeValue}

with:

Attribute       ::=     SEQUENCE {
        type    AttributeType,
        values  SET OF AttributeValue}

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

Date: Mon, 3 Nov 1997 12:19:04 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: PKIX 1 Examples Comments
Status:

All,

The 14 Oct PKIX X.509 Certificate and CRL Profile, Section 7.2.2 states "The
id-dsa-with-sha1 algorithm syntax has NULL parameters."  Furthermore, the
X9.57 spec (which defines the id-dsa-with-sha1 OID used in PKIX 1) states
that NULL parameters shall be used with id-dsa-with-sha1.  In summary, both
specs state that the AlgorithmIdentifier parameters shall be NULL when the
AlgorithmIdentifier algorithm field is id-dsa-with-sha1.

PKIX 1, Appendix D.1.1 includes an ASN.1 dump of a "self-signed"
Certificate.  The ASN.1 dump indicates that the id-dsa-with-sha1 OID is
present in the SIGNED Macro and signature AlgorithmIdentifier algorithm
fields, but in both locations the AlgorithmIdentifier parameters are absent.
The specs state that they shall be NULL which implies that they are present
and encoded as NULL (05 00), so the example is wrong because it indicates
that the parameters are absent.

Also, Appendices D.1.2, D.2.1, D.2.2, and D.4 do not include the NULL
parameters in conjunction with the id-dsa-with-sha1 OID.

Recommend that these examples should be corrected or that the specs should
be changed to state that the AlgorithmIdentifier parameters shall be absent
(rather than NULL) when the AlgorithmIdentifier algorithm field is
id-dsa-with-sha1.

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

Date: Mon, 03 Nov 1997 17:14:09 +0100
Reply-To: [email-masked]
Organization: Telekom
To: [email-masked]
Subject: subscribe
From: [email-masked] ([email-masked])
Status:

subscribe

From: [email-masked]
Subject: IETF-PKIX Mail List Notice
To: [email-masked]
Date: Sun, 2 Nov 1997 23:07:22 -0800 (PST)
Reply-To: [email-masked]
Status:

Attention, [email-masked] Users,

Due to operational exigencies, we at Tandem.com have
replaced the old mail system with a new one.  This
has temporarily affected the e-mail list service in
that the administrative commands no longer work.

A new list server package is on order and we expect
to install it soon.  It will provide functionality
equal to and beyond the old listserver system.

In the meantime your requests can be submitted
to "[email-masked]", which has been aliased
to postmaster and the postmaster team will
fill your requests manually as they are
received.

Thank you,
[email-masked]

Date: 2 Nov 97 15:30:00 -0800
From: [email-masked]
To: [email-masked]
Subject: Reminder: How to unsubscribe yourself from ietf-pkix
Status:

Please use the [email-masked] address !

If you ever want to remove yourself from this mailing list,
send the following command in email to "[email-masked]"
(NOT [email-masked]):

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

Example

    Your email address is [email-masked] in the body of your
    letter include the following :

    unsubcribe [email-masked] ietf-pkix

    Then mail it to [email-masked]

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Object Identifiers: Confusion now hath made his masterpiece
Date: Sun, 2 Nov 1997 19:59:19 -0500
Status:

I'm the one who registered md<x>WithRSASignature.  RSASignature is
the ANSI X9.31 version of RSA, which is the same as ISO 9796-2.
The padding rules are different from PKCS #1 although I can't see that
they provide any more security.

X9.31 got derailed several years ago during the PKP brouhaha and
is only now going out for ballot.

It was easy to register these OIDs since I chaired the OIW Security SIG
at the time.  I have NO idea where the OIW sha1WithRSAEncryption
came from; it's not in any of the OIW agreements I've seen...

Regards,
Rich

----------
> From: Peter Gutmann <[email-masked]>
> To: [email-masked]
> Subject: Re: Object Identifiers: Confusion now hath made his masterpiece
> Date: Sunday, November 02, 1997 11:19 PM
> 
> [Followups trimmed somewhat]
>  
> >>1. DSA and SHA combinations have multiple redundant definitions (X9.57,
some
> >>   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
> >It depends on what standard you choose to follow.
>  
> <rant humour=on>
> It seems to me that the designers of some of these standards are like WWI
> generals who sit 50 miles behind the front in a French chateau moving
figures
> around on a board while the poor implementors are stuck in the trenches,
up to
> their eyeballs in mud and trying to figure out which one of a dozen
different
> OIDs they need to use to provide the greatest chance that Webscape
Netvigator
> and Micronet Exploder will accept the output from their software, while
> barrages of management directives to get the product out on time go
thundering
> overhead...
> </rant>
>  
> (That was meant to be humour, for all the standards designers who are
even now
> reaching for their flamethrowers).
>  
> >[OIW OIDs in the 1 3 14 arc]
>  
> I knew where the OIDs came from, I was more concerned with what standing
they
> have in practice (thus the comment about "strange OIDs which don't make
much
> sense").  For example the usual OIDs used for RSA with a hash function
are the 
> PKCS #1 ones, however there are also OIW OIDs for mdxWithRSA, and then
also 
> md4WithRSAEncryption which changes to ...WithRSASignature by the time we
get 
> to MD5.  Does anyone use any of these OIDs?  Then there are OIDs for the 
> deprecated square-mod-N hash function, some deprecated DSA OIDs (eg the 
> dsaCommon... ones), ambiguous OIDs like rsa (1 3 14 3 2 1 1) which
doesn't 
> specify padding rules and which in any case is already specified in
X.509, 
> duplicates of existing OIDs like rsaEncryption which is already specified
in 
> (and far better known from) PKCS #1, and so on.  Is there some minimal
list of 
> OIW OIDs which should be supported to ensure a reasonable level of 
> interoperability with other real-life implementations?  From what I've
seen 
> you'd need to support the DES OIDs for S/MIME, sha1 (1 3 14 3 2 26), 
> dsaWithSHA1 (1 3 14 3 2 27), and possibly dsaWithCommonSHA1 (1 3 14 3 2
28) 
> (although the fashion seems to be to avoid common DSA parameters and use
one 
> of the dsaWithSha1's instead).  Have any of the others seen any
widespread use 
> in generally-available software?
>  
> Peter.
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Object Identifiers: Confusion now hath made his masterpiece
Sender: [email-masked]
Reply-To: [email-masked]
Date: Mon, 3 Nov 1997 04:19:58 (NZDT)
Status:

[Followups trimmed somewhat]
 
>>1. DSA and SHA combinations have multiple redundant definitions (X9.57, some
>>   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
>It depends on what standard you choose to follow.
 
<rant humour=on>
It seems to me that the designers of some of these standards are like WWI
generals who sit 50 miles behind the front in a French chateau moving figures
around on a board while the poor implementors are stuck in the trenches, up to
their eyeballs in mud and trying to figure out which one of a dozen different
OIDs they need to use to provide the greatest chance that Webscape Netvigator
and Micronet Exploder will accept the output from their software, while
barrages of management directives to get the product out on time go thundering
overhead...
</rant>
 
(That was meant to be humour, for all the standards designers who are even now
reaching for their flamethrowers).
 
>[OIW OIDs in the 1 3 14 arc]
 
I knew where the OIDs came from, I was more concerned with what standing they
have in practice (thus the comment about "strange OIDs which don't make much
sense").  For example the usual OIDs used for RSA with a hash function are the 
PKCS #1 ones, however there are also OIW OIDs for mdxWithRSA, and then also 
md4WithRSAEncryption which changes to ...WithRSASignature by the time we get 
to MD5.  Does anyone use any of these OIDs?  Then there are OIDs for the 
deprecated square-mod-N hash function, some deprecated DSA OIDs (eg the 
dsaCommon... ones), ambiguous OIDs like rsa (1 3 14 3 2 1 1) which doesn't 
specify padding rules and which in any case is already specified in X.509, 
duplicates of existing OIDs like rsaEncryption which is already specified in 
(and far better known from) PKCS #1, and so on.  Is there some minimal list of 
OIW OIDs which should be supported to ensure a reasonable level of 
interoperability with other real-life implementations?  From what I've seen 
you'd need to support the DES OIDs for S/MIME, sha1 (1 3 14 3 2 26), 
dsaWithSHA1 (1 3 14 3 2 27), and possibly dsaWithCommonSHA1 (1 3 14 3 2 28) 
(although the fashion seems to be to avoid common DSA parameters and use one 
of the dsaWithSha1's instead).  Have any of the others seen any widespread use 
in generally-available software?
 
Peter.

Date: Sat, 1 Nov 1997 00:00:02 -0800
From: Operator - SUNTAN <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)
Status:

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

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

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

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

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].